OpenSPP
Restructure the spp_user_roles module to support dynamic setup of user roles by other modules
The OpenSPP User Roles module is currently set to depend on other modules for the setup of user roles. An issue is introduced by this setup considering that there is no flexibility in managing variations in access rights based on the implementation requirements. For example, the SP-MIS registrar role have a different access rights defined compared with the registrar role in the Farmer Registry. Since all modules in the spp_user_roles defined in its dependencies will be installed automatically, there is another issue of having modules not applicable for an implementation to be installed. This will result to conflicts with the modules installed.
The following are the requirements of this ticket:
- [ ] Remove the dependency of the spp_user_roles with other modules except the base and base_user_role modules.
- [ ] Remove the currently defined roles in the spp_user_roles module.
- [ ] Add spp_user_roles in the dependencies of all modules that requires the creation of new roles or adding access rights to existing roles.
- [ ] Create new roles or add access rights to existing roles in all applicable modules.
Findings: Returned to dev
Multiple issues found but created as separate tickets:
#645 - Critical (Entitlement manager role is not available/missing) https://github.com/OpenSPP/openspp-modules/issues/646 - Low (Access error that appears intermittently upon logging in as progam manager) https://github.com/OpenSPP/openspp-modules/issues/647 - Critical (blocks program manager from configuring the mulitplier for cash or in-kind entitlement type) https://github.com/OpenSPP/openspp-modules/issues/648 - Critical (blocks process of program manager from approving in entitlement level)
Meeting minutes
limit view for openspp client specific instances
- account security
- preferences
- role type
Local registrar:
- Hide configuration view in Registry for Local registrar
- import feature limit for local registrar
- Remove Add to program button in Registry>select data>Action button
- create registry data , blank areas = see all
global registrar
- Hide configuration view in Registry for Global registrar
- Remove ID distributor access rights to Global registrar
- Remove Add to program button in Registry>select data>Action button
- can create/view/update/delete group
- can create/view/update/delete individual
- can export group/individual
- can import group/individual
- can grant portal access to a group or individual
Global program manager
- Must be able to view Registry but as Read only
- can add group/individual to program
- can CRUD program
- does approver group dropdown field have to display all if only cycle approver is meant to approve cycle?
- multiplier issue fixed in 647 so ignore issue
- what is the difference of condition domain from multiplier?
- what is the difference of maximum amount and max number?
- if i don't tick auto approve entitlement, which role should i set as entitlement validator ? if you dont set anyone. when preparing entitlement, it would still work and only admin role can approve the entitlements.
- currently there is no specific role that approves entitlements, should we create entitlement manager?
- as global program manager. why can i generate money? assuming only finance manager handles the program's budget.
Finance validator
- can generate budget for programs
- can view cash entitlements
- cannot approve entitlement
- discuss use for program fund report
Global cycle approver
- Can approve cycle when selected as approver group.
- Not certain what else is tasked for this role.
Global program validator
- Can approve cycle when selected as approver group.
- Not certain what else is tasked for this role.
Global support manager
needs to be discussed
Change Request roles
needs to be discussed
@celinenilla , Since the new tickets are created that are not directly associated with the spp_user_roles module and will be fixed in the program management modules identified, can this be closed and its PR merged. The fix in the automated tests that are causing the other PRs tests to fail is in this ticket's PR. Merging the PR will fix all future PR's tests.
Another issue is that the PR of this ticket needs to be merged so that the new associated tickets will be worked on.
