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
Once the Starter submits the startup-checklist, the currently running Starter shift ends and the shifter takes over. This is done be UPDATEing and entry in the new shiftcalendar table called calendarentry.
The query to find the current Starter shift might look like this:
UPDATE calendarentry c
JOIN role r ON (c.role_id = r.id)
SET c.end = NOW()
WHERE r.name="Shifter_Awake"
AND start<NOW()
AND NOW()<end
The problem comes, when a Starter tries to submit the checklist twice. Then this update will not work, since there is no Starter on shift anymore.
Also, when if just somebody submits the startup-checklist? Then the starter is not on shift anymore. From security point of view this is fine. The shifter will be callend ... then the fallback ... then the developers. ..
But restoring the state is not too easy ... I mean sure ... find the last entry in startup_checklist_filled and remove it. Note the created timestamp. Find the Starter entry with the same timestamp and set the endtime to the next "Parker" entry.
However this is all functionality that needs to be coded ... and that ... well ... is just a lot of work.
So this must not go wrong ... but it will ...
The text was updated successfully, but these errors were encountered:
Once the Starter submits the startup-checklist, the currently running Starter shift ends and the shifter takes over. This is done be UPDATEing and entry in the new shiftcalendar table called
calendarentry
.The query to find the current Starter shift might look like this:
The problem comes, when a Starter tries to submit the checklist twice. Then this update will not work, since there is no Starter on shift anymore.
Also, when if just somebody submits the startup-checklist? Then the starter is not on shift anymore. From security point of view this is fine. The shifter will be callend ... then the fallback ... then the developers. ..
But restoring the state is not too easy ... I mean sure ... find the last entry in
startup_checklist_filled
and remove it. Note thecreated
timestamp. Find the Starter entry with the same timestamp and set theend
time to the next "Parker" entry.However this is all functionality that needs to be coded ... and that ... well ... is just a lot of work.
So this must not go wrong ... but it will ...
The text was updated successfully, but these errors were encountered: