Adjust right checks for multiple suppliers

I checked this ticket and everything works according to the acceptance criteria.

Background to this issue: when implemented in eLMIS, the workaround to this permissions issue was to create a new Program for the supply partner (screenshot located in the requirements page listed as Source Program and Destination Program - https://openlmis.atlassian.net/wiki/spaces/OP/pages/114915083/Configuring+of+products+list+for+supply+Partners)

I created a topic: https://forum.openlmis.org/t/multiple-suppliers-issue-with-correct-displaying-requisitions-for-certain-users/4912

I think since this is an important design topic that will affect a good portion of the system, we should post this on the Dev forum to discuss. Can you do that? In that post, lay out:

• The problem we are trying to solve (people seeing requisitions they should not be able to see)

• Your proposal on how we can address this problem and things that will be affected

Then the tech community can see this change in design and we can discuss. I can respond to your post about my concerns and if there are alternative approaches we can explore. We can try to come to a decision about the best way forward either through the forum, or if we need to resolve faster, we can schedule a call.

Thanks Łukasz for creating this ticket. It's good that you have encountered this issue, thought about it, and came up with a design proposal.

There is a statement in the description of the ticket that is inaccurate; supervision rights are not exactly by facility and program, but by either program, or program and supervisory node. You can extrapolate that to permissions by facility and program.

So I have some concerns about this approach. The role-based access control (RBAC) in the system is already complex and we should not be quick to add a new dimension to it. Since RBAC is already defined by supervisory node (see comment above), we wouldn't necessarily have to add it there; but this ticket is proposing adding it to the permission strings design. This would increase complexity by:

• Adding a new dimension to permission strings - it becomes less clear what a permission string means

• Requiring all requisitions have a supervisory node - this changes what supervisory node id in a requisition means. Before it meant that it is now in the supervisory chain and the node currently assigned is where it is in the chain. Once a node is assigned when created, we can't assume that anymore.

The criteria we are trying to satisfy is to only show the appropriate requisitions to the user. Is it possible to modify the approach of how we search/view requisitions to filter by supervisory node id?