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...)
An agent for the pay as you go Solar Module is modeled as an MFI staff with limited permissions, i.e he would only be allowed limited access to staff roles including the ability to create new Clients and opening Pay-go-sol (a savings/current account) accounts for the client.
Building out this functionality would require a minor enhancements to Staff API's wherein we would want to add the ability to tag a staff as a Agent for reporting purposes
Additionally, the Agent would have a savings account with the MFI which would be used for accepting payments from Customers. So the agent would accept physical cash from the customer and make a transfer of the equivalent amount from his current account to the customers current account.
For this bit of the agent functionality, we intend to add the ability of creating a "Client" account for a staff and build out and leverage a generic 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.
We would expect the bank to want to setup permissions for the Client portal (some client would only have the ability to view their loan and savings data, some may be allowed to do account transfers)
It would also be helpful to have the ability to "turn on/off" the Client self service portal from an MFI perspective
We would also want to clearly demarcate the Client portal permissions from the back office permissions as in the only allowed permissions for a client are those listed above, a bank can not (even accidentally) associate any other permissions with a Client
Finally, we would expect that all account data is not safe for Client viewing (in the context of a loan, the client should have access to his basic loan data for only active and closed loans, we might not want to For ex: show loan notes to a customer or the internal approval cycles etc for other loan applications for a client). We also recognize that the Client portal API's would need to evolve independent of the back office API.
We would expose a new root resource for Client portal wrapper API's from the existing MifosX codebase, say mifosng-provider/client-portal/api/v1 and expose wrappers for those API's which make sense from a Client perspective. This would help logically separate the Client portal API's from the back office API's
This can be done similar to http://stackoverflow.com/questions/10231854/multiple-jersey-applications-with-same-path-for-root-resource
It is fairly common for MFI's to provide savings/loans to their employees. However, the accounts related to employees usually have a different set of permissions.
We would need the ability to create a client account for a staff and introduce a new set of update permissions for acting on loan/savings accounts belonging to Staff. This permission is checked for on all update operations related to any employee account, and helps prevent fraud on Employee accounts
We would want to reuse staff to represent any back office entity (Bank Employees, partners & agents, funders etc). To avoid confusion, let's refer to the existing Staff API's as "associates"
Just two
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
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 we would want to capture for different types of associates like staff/ partner / agent etc would be different)
No, we are not. We are only extending the existing staff entity
The design proposes adding a hierarchy for Associates. Parents would have 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 has is a first name, last-name 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). Currently this association has no affect on the data scope
We would expect that the Staff API's (which we refer to as associates in this wiki) encapsulate user creation.
So a client app developer would use the associates API to create an associate and optionally provide him with access to the system. Similarly the update associate API's could be used for changing the credentials for accessing the system
This means that we would no longer be using the User's API .
However, their would be no changes to the existing schema (only the API 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 associates API
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 a system admin would need
This is currently not a part of our plan as all Associates/clients need not be users of the system. We can have some associates meant solely for lookup purposes like a Client relationship manager etc
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 linked to the same.
An Associate transfer would also mean that the "Office" of the linked user would change etc.
The roles and permissions module is reused as is 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
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.
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
The original intention was to make it worse! We would have four rows
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)