Parsec version
3.9.0
Which platform(s) you have observed the problem
Bug description
Issue
When a user is logged in but currently on the organization selection screen, the client does not display a revocation dialog if the user gets revoked from an org.
If the user later switch back to that logged-in org, the revocation event has already been processed/consumed, so no dialog is ever shown.
This also means the user data are not removed and the user is still listed in the organization list.
However this eventually corrects itself once the user logs back into that org, because at that point the client catches the revocation error and shows the dialog as expected.
Discussion
Not entirely sure how to fix this cleanly, it's a consequence of the multi-org setup.
Notifications are filtered based on the currently active handle: if multiple orgs are open at once and an event arrives for an org you're not currently viewing, you don't want it surfacing.
Same issue applies on the homepage — showing it there would get confusing fast. Storing notifications to replay them later when reconnecting also seems fragile/risky.
Given that, this is probably low priority: it shouldn't happen often, GUI shows that we are offline which is good enough, and the state re-syncs correctly on the next login.
How should the application behave
No response
Reproduction steps
Relevant output:
No response
Parsec version
3.9.0
Which platform(s) you have observed the problem
Bug description
Issue
When a user is logged in but currently on the organization selection screen, the client does not display a revocation dialog if the user gets revoked from an org.
If the user later switch back to that logged-in org, the revocation event has already been processed/consumed, so no dialog is ever shown.
This also means the user data are not removed and the user is still listed in the organization list.
However this eventually corrects itself once the user logs back into that org, because at that point the client catches the revocation error and shows the dialog as expected.
Discussion
Not entirely sure how to fix this cleanly, it's a consequence of the multi-org setup.
Notifications are filtered based on the currently active handle: if multiple orgs are open at once and an event arrives for an org you're not currently viewing, you don't want it surfacing.
Same issue applies on the homepage — showing it there would get confusing fast. Storing notifications to replay them later when reconnecting also seems fragile/risky.
Given that, this is probably low priority: it shouldn't happen often, GUI shows that we are offline which is good enough, and the state re-syncs correctly on the next login.
How should the application behave
No response
Reproduction steps
Relevant output:
No response