Raw meeting notes which led to the creation of this wiki at https://docs.google.com/a/confluxtechnologies.com/document/d/1cLDTmCF0N8RwJBx2Uh6xUncHTcuYrY3LOWvzMMX0QUg/edit# .What started off as a discussion on Pay go sol module has now extended to a a variety of use cases (involving agent-partner networks, need to provide restricted & hierarchical data scope to such external partners, simplification of relationships between staff and users etc...)

...

Client Self Service Portal

A Client account is created for every Agent. As a Client, the agent has the ability to

• View their own loan or savings account details

• Transfer funds within their own accounts

• Transfer funds to another account.

...

• Extend the staff api to add the ability of associating classification discriminators for associates. Organizations should be able to define their own classifications for associates Ex: Employee,  Agent, partner, funding Partner and report on them intelligently.
• We should also extend the data tables functionality to allow linking specific data tables to associates based on the classification
• We should be able to specify data scoping (either branch: the default wherein the user has access to the entire branch he is linked to, or restricted: where he has scope only on those centers/groups/clients/loans/savings to which he is directly linked) on a per classification basis.
• Organizations should also be able to define hierarchies of associates so that data scope of a Managing associate includes those of all the associates he manages (would be helpful in case of Partner/Agent models where the agents belong to the particular partner)
• Allow linking multiple associates to a particular account (center/group/client/loan/savings). For Ex: We would want to link a Loan officer to a center so that he has data scope on the same, also if the loan for an entire center is sponsored by an external "Partner", say "Kiva", I would also be able to link the Kiva partner to the said center so that they could have data scope on the loans given out by them
• Encapsulate create User A

Associate Classification and Data Tables

...

Associate and Center/Group/Client/Loan/Savings linkages

Discussions

Q) How many types of system users do you recognize?

Just two

• Clients : Customers with read access on their accounts and the ability to make account transfers
• Associates (for the lack of a better term) : Back office users. Any actors from the bank of acting on behalf of the bank ( encapsulates Staff, agents , partners, extension counter networks, funders who want visibility on loans funded by them etc)

Q) I don't see any use of introducing Classification for associates? Can't we associate data scope directly to roles?

We allow attaching multiple roles for a user. Adding data scope to roles brings in additional complexity as a user can be assigned multiple roles each with different data scopes. So we suggest the approach of associating a data scope against the Associate classification

Also, data scope only makes sense to an Associate user (we currently do not see the need of data scopes for Client users)

These classification would also be used to attach appropriate data tables to Associates ( The data I would want to capture for a staff/ partner / agent etc would be different)

Q)  Are you adding complexity by creating a new Entity called "Associates"

No, we are not. We are only extending the existing staff entity

Q) My requirement is to have a network of Agents. We want the Organization managing these agents (our partner) to have data scope on all loans managed by their Agents so that they can calculate commission for their agents etc

The design proposes adding a hierarchy for Associates. Parents would have access to the data scope of their children.

So, you would create an Associate discriminated as "Partner" and have all the agents of the the particular partner created as Associates with their parent set to the Partner.

Q) I do not like / understand how users and staff are currently modeled in MifosX

We originally had only users and API's for creating/editing users. All a user ahd (and still has) is a firstname, lastname and and email address. A User has complete data scope on the branch he is created in.

Roles and permissions are used to determine the kind of activity he can perform on this data scope.

The Staff entity was added in later and was used only for lookup purposes in the application (the ability to associate a staff to a user was added in only a couple of releases ago)

Q) How do you see Staff and users working in the future ?

We would expect that the Staff API's (which we refer to as associates in this wiki) would be updated to encapsulate user creation.

So a client app developer would use the Staff API to create a staff and optionally provide him with access to the system. Similarly the update Staff API's could be used for changing the credentials of the staff login into the system

We would no longer be using the User's API . However, their would be no changes to the internal logic (only the API end points change) i.e both Staff and the associated user would sit in different tables and the firstname/lastname /email address of the User table would be populated based on the parameters passed into the staff API

Q) I am concerned that such encapsulation would result in cryptic errors due to constraints on the user table. For ex: A Client creation could throw an error if a Staff user with the same name is present etc and maybe very difficult for the end user to comprehend the root cause

Ideally the API should return a clear message saying "A client user with the current login already exists etc". So we should not run into any such issues

Also, the existing users API would only be modified to return only Staff users by default. By passing a query parameter to it we can retrieve either/both the staff and Client user so the UI for viewing any system users should still provide all the information required

Q) I would suggest that all foreign keys point to the user table instead of the staff and Client table

This is currently not a part of our plan as all Associates/clients need not be users of the system. I can have some associates meant solely for lookup purposes like a Client relationship manager etc 

Q) There would be issues with managing firstname /lastname/ email address across Client/Associates and User tables

We could always query these fields directly from the linked staff and client table

If the concern is about having unnecessary joins, we could make it the responsibility of the Client and Associates API to ensure any changes to firstname, lastname and email address are propagated to the User API