[DEA] User info access in rules

[mahalakshme]

Need:

In DEA, we don't want to allow the users to edit data belonging to a different catchment with different syncAttribute values set.

Approach:

In DEA, we don't want to bring up the restriction of users to catchment and syncAttributes set like in mobile app(at architecture/code level), because the purpose of restriction in mobile app is different and it not necessarily applies to users of DEA. Hence though users can view we can bring in the restriction for them to be able to edit alone via rules.

Out of scope:

No need to handle for cases where addresses in sync attributes might apply to catchment outside of the user's catchment as well. Eg: Sync Attribute value, 'Goonj Udaipur' set for users whose catchment is not Rajasthan.

AC:

To achieve the above, considering other cards in the linked epic will be played, as part of this card the below need to be done:

• user and myUserGroup info need to be available to all rules in DEA(executing on rule server as well as on webapp) with similar info available in mobile app rules
• Also make user and myUserGroup accessible in rule-server rules

Old: Ignore:

Questions:

• Are addresses in sync attributes always a subset of addresses in catchment unlike in APF Odisha?
• Will such users do registers? or we will restrict its permission?
• Will need to allow edit Account name/address to one of the values within sync attributes/addresses user has access to? or can make it read only?
• Should edit of everything within catchment work smoothly? Currently subject concept edit will not work same as mobile app. Same for few other form elements as well. There are ifs and buts.

---

As a DEA user, I should be able to edit the entities for which sync strategy matches only.

Approach:

Considering sync attributes are subset of catchment, add rules to prevent editing entities in DEA where users' sync attributes doesn't match with entities sync attributes. Also prevent editing the Account name to a value other than user's sync attributes.

AC:

To achieve the above,

Option 1: If account name need not be edited to even one of the values of sync attributes

• user and myUserGroup information need to be available to all rules in DEA (rules executing in rules-server and avni-webapp)
• Ability to mark a form element readonly via rule. In this case 'Account name'
• add a parameter to identify from which app rule function is called. Implementors should be able to access it from params.callContext. When called from DEA its value needs to be 'webApp'. When called from mobile app, its value need to be 'mobileApp'. ' so that rule can be executed conditionally based on the callContext. Needed since need to make readOnly only in DEA
• Add rule in all entities of 1st form element group such that, on Edit user not allowed to move to next page
  when 'Account name' is not one of the values of User sync attributes set for that subject type.

Option 2: If account name can be edited to one of the values of user's sync attributes

• user and myUserGroup information need to be available to all rules in DEA (rules executing in rules-server and avni-webapp)
• Ability to compare with old observation saved. In this case 'Account name' to make sure user can edit it to one of the values for which user has access to.
• Add rule in all entities of 1st form element group such that, on Edit user not allowed to move to next page
  when 'Account name' is not one of the values of User sync attributes set for that subject type.
• If the above will fail in DEA or mobile app:add a parameter to identify from which app rule function is called. Implementors should be able to access it from params.callContext. When called from DEA its value needs to be 'webApp'. When called from mobile app, its value need to be 'mobileApp'. ' so that rule can be executed conditionally based on the callContext. Needed since need to make readOnly only in DEA

Option 3: If registration also need to be allowed within one of the user's sync attributes also need to be allowed

• user and myUserGroup information need to be available to all rules in DEA (rules executing in rules-server and avni-webapp)
• Ability to compare with old observation saved. In this case 'Account name' to make sure user can edit it to one of the values for which user has access to.
• Being able to differentiate create or edit mode in the rule
• Add rule in all entities of 1st form element group such that, on Edit user not allowed to move to next page
  when 'Account name' is not one of the values of User sync attributes set for that subject type.
• If the above will fail in DEA or mobile app: add a parameter to identify from which app rule function is called. Implementors should be able to access it from params.callContext. When called from DEA its value needs to be 'webApp'. When called from mobile app, its value need to be 'mobileApp'. ' so that rule can be executed conditionally based on the callContext. Needed since need to make readOnly only in DEA

Option 4:

• By able to access addresses user has access to
• And by making the rule execution async
• Again by doing the above so that we dont allow edit of user addresses

If we want to support Edit below cards as well need to be played:

• [DEA] Handle Async fetch of related entities during Rule Evaluation #1205
• Not allow to set value outside sync attributes in subject concept

Out of scope:

Being able to access entityContext. This will involve additional work like being able to access the group member information. So we can do it when needed. Currently many things are not accessible from DEA like enrolment of encounter in encounter form, individual of enrolment in enrolment form etc.,

Old: Ignore

AC:

• When a user Edit of existing/does creation of registration/encounter/enrolment, I(implementor) should be able to restrict in any of the below circumstances:
  User is not provided permissions via the User groups
  - User belongs to a different catchment
  - User belongs to same catchment but assigned different sync attribute than that of the entitys' when the subject type of the entity type has 'Sync by attribute' also as a sync strategy
  - User belongs to same catchment but not assigned the entity when the subject type of the entity type has 'direct assignment' also as a sync strategy
• Add READme

Technical:

• Currently userGroups of the logged in user, its privileges, addresses belonging to user catchment are not accessible. And this should be made accessible to achieve the above.
• Option 1: And add rule manually.
  • Cons: - Not scalable - if other orgs ask the same, will we keep doing rules in DEA in all forms
    - Need to add rules at all enrolment, encounter, and registration.
    - Also need to add if conditions to not fail in mobile app
• Option 2: By default execute this check in DEA on all forms instead of the need to manually add the rule in all forms.
  - Can handle the above cons

Concerns:

• Will performance get impacted? - doesn't seem so, in the org in focus around 300 addresses and 222 group privileges fetching will be done.
• In search everything will display - I don't think the implementation in focus would be fine with this as well. As per the last conversation, they are imagining it to work like in mobile app.
• Not very clean - since we allow view, etc., though restricted.
• In subject concept selection, selection across catchments etc., not yet restricted.

Inputs:

• Void permissions
• FEG rule
• for consistency - not do option 2
• FEG rule execution - sync/async - addresses availability
• edit can restrict, entityContext, userAccountSyncAttributes
• entityContext together
• delete of everything working fine?