Replace direct usage of user roles [2]

[MartinWahnschaffe]

Feature Description

We want to allow admins to configure user roles according to their needs #898.

Ideally do #2805 first.

Problem Description

Some user roles are still used directly, which makes it impossible to create or customize user roles. This needs to be replaced by user rights or other mechanics.

Proposed Change

• Make UserRole deprecated
• Remove AbstractAdoService.isAdmin, isSystem, hasUserRole (no longer used anyway)
• UserService.getLabUsersOfLab: Use jurisdiction instead of user role. Same in SampleGrid and TraskGridComponent (search for usages of LAB_USER)
• ADMIN: Introduce DEV_MODE user right and use it instead of ADMIN for DevModeView and assign to admin user
• ADMIN: Use specific user rights for deletion of entities, e.g. in SampleController.getSampleEditComponent (search for usages of UserRole.ADMIN)
• NATIONAL_* + REST_USER: ActionService.createUserFilter should check Jurisdiction instead.
• DashboardMapComponent: Remove check for national user roles. Just check region and fallback to centerOfAllRegions.
• Add CASE_RESPONSIBLE user right. Users with this right can be assigned as responsible user to a case and be automatically assigned to related tasks (CaseFacadeEjb.assignOfficerOrSupervisorToTask).
• Add CONTACT_RESPONSIBLE user right. Users with this right can be assigned as responsible user to a contact and be automatically assigned to related tasks
• Add EVENT_RESPONSIBLE user right. Users with this right can be assigned as responsible user to a contact and be automatically assigned to related tasks
• Related "Responsible Office"r field strings should be renamed to "Responsible User"

For user role checks related to the weekly reports we have three parts that need to be changed:

• Getting hospital and community informants (call to UserFacade.getUsersByAssociatedOfficer) needs to be replaced by retrieving users that have the right to WEEKLYREPORT_CREATE and have the associatedOfficer
• Getting surveillance officers (UserService.getallByRegionandUserRolesInJurisdiction in WeeklyReportFacade.getSummariesPerOfficer) needs to be replaced by getting all district level users of that region that have the WEEKLYREPORT_CREATE user right
• May already been touched: In UserEditForm:L168 the system gets surveillance officers as values for the associatedOfficer drop down. This should be replaced by users associated to the district that have the CASE_RESPONSIBLE or WEEKLYREPORT_CREATE user right. Also add a description for User.associatedOfficer to the description.properties "Superordiante district user responsible for case surveillance or weekly reporting".

Finally:

• For all user roles check whether they are still directly used in Java methods. Usage in annotions is ok, this will be handled by Use RolesAllowed with UserRights instead of UserRoles [5] #5056. Usage related to email/sms is handled by Refactor email/sms notification system to work with future configurable user roles [2] #2805

Additional Information

#8318 is handling the android app.

[MartinWahnschaffe]

1. UserRole.hasAssociatedOfficer -> Leave as-is. We need to define a separate issue that will make this whole thing more intuitive.
2. UserRole.hasOptionalHealthFacility -> @MateStrysewske Any idea why certain user roles (e.g. CASE_OFFICER) have an optional health facility? Is this to pre-select the health facility when creating a new case? I don't see any way of calculating this based on jurisdiction or user rights, so be probably need to leave it as-is.
3. UserRole.isPortHealthUser -> Leave as-is.
4. UserRole.isLabUser -> JursidictionLevel.LABORATORY

@MateStrysewske We will need to discuss this. I'll need your help here. It's not urgent, though.

I have also extend #4461 to keep these fields:

UserRole: Add hasOptionalHealthFacility, hasAssociatedOfficer and portHealthUser boolean fields. Those might be replaced with other mechanics in the future.

[ChristopherRiedel]

4. UserRole.isLabUser -> JursidictionLevel.LABORATORY

Will be replaced in #4461

[MartinWahnschaffe]

We had to set the jurisdiction level of the REST_USER to national. So far the REST_USER was explicetly checked in the createUserFilter methods (e.g. CaseService). This had to be removed and by using the jursidiction level only, it's much more unified now. This may have side-effects that we have overseen, though.

[cazacmarin]

Based on a lot of points which was not included on feature estimation, and on number of tasks which was increased + few days of pair programming with Christopher and a lot of Martin time involvements, this ticket has definitely an 8+ story points. And not 2 as it was originally estimated.

[HolgerReiseVSys]

The JurisdictionLevel of REST_USER has been changed from NONE to NATION.
This means it cannot be combined with DISTRICT level roles any more.
Was this intended?
The SurvNet converter initial import depends on this combination to determine the district of the health department.

[MartinWahnschaffe]

Changes related to REST_USER need to be reverted, otherwise SurvNet converter and maybe other external tools will not work anymore.