Description
Currently, there is a bug where when switching from a project where I have the Owner (or Editor) role to one where I have the Viewer role, the frontend will incorrectly load the buttons in the header with the Owner/Editor role and thus show the Members Tab.
Workaround
No response
Technical Notes
This happens due to the action that updates the current project state being executed too late: getProjectFromBackend/getProjectFromRedux must be fully ran before triggering anything else that depends on the current project id, e.g. the autosave. If the state does not yet contain the current project, the actions will use the wrong role from the old project (in the example above, the frontend would believe that the current user in the "Viewer" project still has the Owner role and thus try to trigger the autosave, which would fail due to the Backend correctly deducing the current user's role as Viewer).
For these reasons, to solve this issue it would likely be necessary to somehow order the actions such that the state update for the current project always happens as early as possible. This must be guaranteed for the frontend to always show correctly, otherwise it would remain a race condition. A global action queue could potentially be the answer.
It is not sufficient to use a middleware that runs as the first middleware and triggers the project state update; this was tried and has not made the project state update occur significantly earlier. Even the first middleware is triggered way too late.
Definition of Ready (to be filled by ThreatSea Team)
Definition of Done
Description
Currently, there is a bug where when switching from a project where I have the Owner (or Editor) role to one where I have the Viewer role, the frontend will incorrectly load the buttons in the header with the Owner/Editor role and thus show the Members Tab.
Workaround
No response
Technical Notes
This happens due to the action that updates the current project state being executed too late: getProjectFromBackend/getProjectFromRedux must be fully ran before triggering anything else that depends on the current project id, e.g. the autosave. If the state does not yet contain the current project, the actions will use the wrong role from the old project (in the example above, the frontend would believe that the current user in the "Viewer" project still has the Owner role and thus try to trigger the autosave, which would fail due to the Backend correctly deducing the current user's role as Viewer).
For these reasons, to solve this issue it would likely be necessary to somehow order the actions such that the state update for the current project always happens as early as possible. This must be guaranteed for the frontend to always show correctly, otherwise it would remain a race condition. A global action queue could potentially be the answer.
It is not sufficient to use a middleware that runs as the first middleware and triggers the project state update; this was tried and has not made the project state update occur significantly earlier. Even the first middleware is triggered way too late.
Definition of Ready (to be filled by ThreatSea Team)
Definition of Done