SORMAS-Project
SORMAS-Project copied to clipboard
SORMAS-Foundation
S2S_New Right_ S2S_Process [1]
Feature Description
A new user right is introduced for S2S because of data protection reasons.
Proposed Change
-
[ ] Implementation of right SORMAS_TO_SORMAS_Process
-
Name of right: S2S_Process
-
Description of right: Only users with this right are allowed to ~~process received shares and only this user is allowed to~~ see & use the share directory.
-
The right is linked to the following roles: none
-
[ ] Change right SORMAS_TO_SORMAS_SHARE
-
Name of right: S2S_Share
-
Description of right:
- Users with this right can initiate a share for a case/contact (is already included in the right).
- The rights from S2S_Process must be withdrawn from the right SORMAS_TO_SORMAS_SHARE (so a user with the right SORMAS_TO_SORMAS_SHARE can not see the share directory and can not process incoming share request.)
- The right is linked to the following roles: none
Acceptance Criteria
Implementation Details
Additional Information
- The right is linked to the following roles: none
@SahaLinaPrueger does the above mean that no default user role will have right to share and/or process share requests? Do we need to remove the SORMAS_TO_SORMAS_SHARE right of currently existing user roles?
Yes, that is exactly what is meant.
@SahaLinaPrueger Just to be sure: This then means that on all instances (development, test and production) there will be no more users that can use Sormas2Sormas until someone manually reassigns these rights in user role management. Is this desired? I would actually have expected that the rights would only be removed from DefaultUserRoles, but all users would be able to do everything as before.
@ChristopherRiedel thank you very much for the demand! If it is possible to only remove the rights from the DefaultUserRoles AND already existing users are able to do everything as before this would be nice.
So when a new health department gets S2S, first of all no user should be able to operate S2S with the DefaultUserRoles. If it is possible, that in health departments that already have S2S (and development and test instances), the users that already have S2S rights keep them, so SORMAS_TO_SORMAS_SHARE and SORMAS_TO_SORMAS_Process (and other rights that are needed for S2S) get automatically, that would be great. (@Jan-Boehme FYI)
@SahaLinaPrueger Yes that's possible. I will make sure it is implemented that way.
Validated ticket on the latest version of sormas 1.75.0 deployed on test-de2 environment
If it is possible to only remove the rights from the DefaultUserRoles AND already existing users are able to do everything as before this would be nice.
@AndyBakcsy-she and @ChristopherRiedel tested this on test-de1 and test-de2 (nightly). The DefaultUserRoles (like admin or national doc) still have the rights SORMAS_TO_SORMAS_SHARE and SORMAS_TO_SORMAS_PROCESS. The rights should be removed from the DefaultUserRoles.
@SahaLinaPrueger the default user roles doesn't have any S2S related user rights any more, the ones on test-de1 and test-de2 where modified by QA people to be able to test S2S in general.
NOTE: Default user roles means the ones defined in the SORMAS and created when SORMAS is started for the first time. After this first start those roles are not considered as default roles anymore.
@SahaLinaPrueger I think there was a misunderstanding here. As I have already written:
This then means that on all instances (development, test and production) there will be no more users that can use Sormas2Sormas until someone manually reassigns these rights in user role management.
What we have implemented now is that on new instances there is no user role that has S2S privileges. The corresponding rights have been removed from DefaultUserRoles. Because the DefaultUserRoles are only a definition in the code (enum), which become UserRoles in the database when the instance is set up. It is not possible in the previously suggested way to revoke S2S rights only from users on instances without S2S without doing the same for all instances with S2S.
Apart from that, test-de1 and test-de2 are both instances with S2S and should definitely contain the S2S rights.
You can see what I mean by comparing, for example, the UserRole templates "National User" and "National User (Default)".
@ChristopherRiedel and @leventegal-she
It is not possible in the previously suggested way to revoke S2S rights only from users on instances without S2S without doing the same for all instances with S2S.
Okay, then we have to revoke S2S rights from all users on all instances.
(I thought the solution you came up with would be to take the rights away from everyone, but on the instances that already use s2s, the users with the corresponding s2s rights would automatically get a new role that only includes the s2s rights, or something like that. But i was also a bit surprised that this could be made possible. Glad we cleared up that misunderstanding. Please remove the rights as described and I will notify the four S2S-piloting-health-departments, so they can prepare for the update.)
AND as described in 8.1 (Q&A about the user roles) we have to make sure, that the point
This will also affect existing user roles linked to the default user role.
will be fulfilled.
@leventegal-she @ChristopherRiedel
if you only give the rights 'S2S Process' and the right 'S2S Client' the user can see the 'share box' with the explanation 'failed to load shares'
I think the user could get confused by reading the word 'failed'. Is it possible to just show the 'share box' without the possibility to click the button 'share' ?
@leventegal-she and @ChristopherRiedel
if you only give the rights 'S2S_Share' and the right 'S2S Client' the user see the 'share box' with the explanation 'failed to load shares' but can share successfully. This is also confusing, can you please delete the text failed to load shares ?
And if the user shares data successfully after that the 'share box' does not show the comment, the status and so on. Can you please make the share box visible for the users with the right 'S2S_Share' ? This is also important because the user needs the possibility to revoke the share. Thank you.
For better understanding: This case is already shared:
Additional information: For contacts everything works as it should on test-de1. With right 'S2S_Share' (and S2S Client) the share box shows at the beginning: 'This contact ist not shared' and after sharing all the needed information, you can revoke successfully and so on. On test-de2 i have the same problems for contacts as I have for cases.
I have two more points, but then I am done with this Issue:
- If you only give a user the right 'S2S_Process' you can accept and reject a share but you cannot revoke. That is wonderful. The point is: You still see the button 'revoke' in the share directory and if you click the button an error message appears. If you do not have the right to revoke the button should not be visible or greyed out.
- 'S2S_Share' includes the right to initiate a share for a case/contact. So the button 'share' is clickable. The possibility to view the related box should be included in the right View_Case, View_Contact, View_Event participant, (View_Travel entry)
The user with S2S_Process right does not have With Ownership/View only filters.
With Ownership/View filters should be visible for all users regardless of user rights, it should only depend on the feature configuration
The user with S2S_Process right does not have With Ownership/View only filters. With Ownership/View filters should be visible for all users regardless of user rights, it should only depend on the feature configuration
@leventegal-she Can you explain what do you mean by that?
@SahaLinaPrueger I meant the filter added with https://github.com/hzi-braunschweig/SORMAS-Project/issues/9787 was not visible only for the users that had S2S_SHARE right. But it should be visible for any user as long as s2s is configured on the system similarly to the share box like you commented here: https://github.com/hzi-braunschweig/SORMAS-Project/issues/10084#issuecomment-1263238587
Validated on test-de3, Version: 1.77.0-SNAPSHOT (ba98b49) Tested all 'S2S_Process' - 'S2S_Share' rights combination on test-de-3 (with pending/accepted/revoked share requests to & from test-de1)
