Add management and enforcement of protocol-specific user permissions

[ebrahimebrahim]

Once OpenwaterHealth/OpenLIFU-python#239 is done, we will have some scheme for saying which user role or which user has access to which protocols. Whatever scheme we come up with, we should add (1) a method for managing that in the SlicerOpenLIFU user management interface and (2) enforcement of that information based on who is the currently logged in user. So whether it's visibility of protocols that we decide should be enforced, or whether it's the ability to use them to initiate a session, or whether it's both of those things, we should enforce that.

There is also (3): a method for managing this in the protocol configuration module when creating or editing protocols. However that's not part of this issue here as it's to be included in a future milestone.

Depends on OpenwaterHealth/OpenLIFU-python#239

---

Traceability Information:

• Issue: SlicerOpenLIFU#262
• SOFTREQ: SlicerOpenLIFU#8
• Comment: This issue is related to the requirements defined in SlicerOpenLIFU#8.

This information was populated automatically by a script on 2025-06-09T18:05:23Z.

[arhowe00]

Adding (3) will be trivial (a few lines of code) due to the existing infrastructure. I can knock it all out in one PR unless you prefer using a separate issue.

[arhowe00]

To implement (2), it may make sense to unload all data when changing users. Since the login comes before loading data, I think it is reasonable to wipe the scene and all loaded data. However, it will make (2) easier because we can just prevent loading of protocols that are not allowed by the user. If we were not to wipe all the data, it would add application state that need special consideration, such as:

1. A protocol loaded by one allowed user cannot be loaded by another, but it was already loaded (reason for wiping protocols)
2. A protocol loaded by one allowed user was used to compute session data, but another user logs in who is not allowed on that protocol but effectively has used it due to the saved computations (reason for wiping all data).

We could explore only wiping data dependent on protocols, but since login comes before loading data, it may be preferable to wipe all data.

[ebrahimebrahim]

Agree that triggering a scene close (using the existing functions that do that) on change of user makes sense. But there should be a warning asking for confirmation, when someone tries to switch user while there are loaded openlifu objects around, so they don't unknowingly lose their work

Adding (3) here or later are both okay. I think it's in milestone 3 maybe

[arhowe00]

Agree that triggering a scene close (using the existing functions that do that) on change of user makes sense. But there should be a warning asking for confirmation, when someone tries to switch user while there are loaded openlifu objects around, so they don't unknowingly lose their work

Great! @sadhana-r @ebrahimebrahim , I will look myself to find those existing routines. But just because you guys may be more familiar, do you mind pointing me to any utilities you know of at the top of your head? Are there any comprehensive "unload all data" functions? (I was thinking of calling the same stuff as "close without saving" in the guided workflow)

[ebrahimebrahim]

Yes, excatly the close without saving stuff -- it's clear_session