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.

...

• 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 , or those acting on behalf of the bank ( encapsulates Staff, agents , partners, extension counter networks, funders who want visibility on loans funded by them etc) who could use the entire suite of API's provided they have the appropriate data scope and necessary roles/permissions

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 directly against the Associate classification

...

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

...

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

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

...

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

...

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). Currently this association has no affect on the data scope

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 associates API to create a staff an associate and optionally provide him with access to the system. Similarly the update Staff associate API's could be used for changing the credentials of the staff login into for accessing the system

We This means that we would no longer be using the User's API .

However, their would be no changes to the internal logic existing schema (only the API end entry points change) i.e both Staff and the associated user would still 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 associates 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

...

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 requireda system admin would need

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 We 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 consistency 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 APIlinked to the same.

An Associate transfer would also mean that the "Office" of the linked user would change etc.

Q) The changes suggested seem complex, we are deviating from the simplicity of the existing security (roles/permissions) architecture

The roles and permissions module is reused as is ans and there are no major changes suggested to the existing security infrastructure. All we are really adding is configurable data scoping for Associates and a separate set of wrapper API's built specifically for Client consumption

Q) We should then completely remove the Users API, shouldn't we?

We do not know, there might be some use cases where this API could still be used. Those who do not wish to use it can simply disable the User related API's (by not giving anybody the permission to access them)

and we can continue to have the API for backward compatibility.

Q) What if I need a Client self service portal where a Client can create a savings account for himself etc?

We have not thought through such scenarios. How would they work? Would a Client be able to to view all savings product in the system and  decide the account he wants to open? Would we have only a subset of Savings products which a Client can directly apply for ? Wouldn't we need a different lifecycle for such scenarios (Or would a application created by a client show up directly in the system)?  

It would be good to revisit the design once we have more such use cases listed down

Q) Hmm, so for the "pay as you go solar" agent (which was the original goal of this design). We would have a row for the agent in three tables! As a client, an associate and a user? Isn't this definitely one row too many?

The original intention was to make it worse! We would have four rows

• An associate account and resulting access to the core mifosx portal: He would use this login for performing his "staff" like duties including creating customers, doing KYC for them (or playing any other role the organization sees fit)
• A client account and access to the client portal: He would use this account to perform account transfers from his savings account to clients savings account etc

The reason for this separation is that the client account may outlast the Associate account, the agent would still have access to the client self service portal even if he is no longer a staff (deactivating an associate would immediately turn of the associate user). There is no reason to show this disjoint behaviour on a mobile app though  . Here we could simply capture a separate user name and password for enabling account transfers.

If this is over engineered, then there is no real harm /extra effort in having a single user account for the agent too (the api restrictions would still be in place, so he would not be able to act on his own accounts using the core loan/savings api, but would only be able to do account transfers using the client portal account transfers API)