You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current behaviour of Scheduled Changes that use "when" is:
You cannot schedule them in the past when you create or update them
Scheduled Changes are not enacted until the "when" time has arrived and the required signoffs have been met.
This means that an already scheduled change may end up being scheduled "in the past" if signoffs do not arrive in time. It's confusing and inconsistent that you can't schedule a change in the past, but it can drift there.
A couple of ideas about how to fix this:
Allow changes to be scheduled in the past. The original reason for this safeguard was that we didn't want them enacted immediately. Now that we use Signoffs for most channels, this generally won't happen.
Support a value like "immediately" or "ASAP" as a "when". Changes could be initially scheduled with this, and they would be automatically changed to this if they are not enacted prior to the original "when". This would effectively have the same behaviour as a "when" in the past, but it would be more obvious.
The current behaviour of Scheduled Changes that use "when" is:
This means that an already scheduled change may end up being scheduled "in the past" if signoffs do not arrive in time. It's confusing and inconsistent that you can't schedule a change in the past, but it can drift there.
A couple of ideas about how to fix this:
(Imported from https://bugzilla.mozilla.org/show_bug.cgi?id=1392720)
The text was updated successfully, but these errors were encountered: