[Mifos-developer] Customer as User

[James Dailey]

Vishwas, 

A few weeks ago I had a discussion with Binny about the Client_As_User need in MifosX.  He mentioned you would be the one to discuss this with. 

This came up in the context of the PayGoSolar GSOC project and how we are thinking about 3rd party Agents, but is actually much broader. 

Currently MifosX Clients (aka Customer) cannot login themselves and see just their accounts.  Therefore, as an example, Internet Banking for a Customer is not supported. 

In the Agent Model that we are proposing, the use case is for the Agent to accept physical cash and make a transfer from his account to the Client (Customer) account. (CashIN)  This is how many Agent models are implemented as it creates an accounting record.  It is even more important that the record exists when the cash movement is from the Client (Customer) Account outward to the Agent.  (CashOut)    This would be implemented on the Android and the idea is to have the Agent be a Client (Customer) with a User Account linked to his and only his accounts. He has permissions to transfer funds from his account to another account after authentication.  

Again, for Internet Banking, general Customer Access use case, Agent use cases, the current User/Role permission schema and how it meshes with Staff/Hierarchy is insufficient and needs to be revised.

Now, I am not sure if you have a design yet, but what I have discussed with Binny and again with Antonio is an approach that involves delinking the current User/Role from Staff/Hierarchy models and replacing that with a new concept of a linking table between Users and Clients/Staff.  

Users -->  Linking table <---  Clients --> Accounts_belongs_to_Clients 

Users -->  Linking table <---  Staff (for backwards compatibility) -->Accounts_Assoc_Staff

The Linking Table is fundamentally just mapping the UserFK with the ClientFK.  

Also, Linking Table <---> Permissions 

I'm also sure its not that simple. 

Could you let us know what your thoughts are in this regard?  Antonio - did I capture our conversation ok?  

Others please feel free to chime in if you have a design or were involved in the original design and can shed light on the best way to proceed.  

Regards, 

- James Dailey 

[Binny Gopinath Sreevas]

James, Vishwas,

 

I am assuming that:

a)      an agent will not be able to view the client accounts, but will only be able to view transactions that this agent did with the client

b)      a client will not be explicitly mapped or tied down to an agent i.e. a client can be serviced by any agent

 

I agree with you on introducing a linking table to link a user with Client/Staff/Agent etc.

 

Some thoughts:

Option 1:

a)      Extend the client entity to represent an Agent too – do you see any pitfalls in doing this?

b)      Introduce a “User” to “Entity” mapping table – a user can be mapped to more than one entity (which can be either a staff or a client/agent)

o   A “relationship type” field in this table will define the kind of authorization this user has on the entity

Examples:

User1 à is à Client1 (has full access to Client1’s accounts)

User2 à is à Staff1

-          if Staff 1 is not a Relationship Officer, then User2 has full access to Staff1’s branch data

-          If Staff1 is a Relationship Officer, then User2 has access to only specific clients who are mapped to Staff1

c)       Does it make sense to introduce a “segment” field for clients? This will be used to classify clients as “agents” and any other “types” of customers:

o    “Agent” will be one of the segments

o   Other segments could be Retail Customers, SMEs (Small Medium Enterprises), VSEs (Very Small Enterprise) etc.

o   In a typical banking scenario – it could have values like Wealth Customers, Corporate Customers etc.

Ideal solution will be to introduce a type (Personal vs. Non-Personal customer) and a customer-segment

Also, we may need to enable segment-specific data tables for Clients – so that Agent details can be captured easily.

Eventually, we could introduce product level restrictions for different segments (ex. Agents cannot have loan accounts)

 

Option 2:

a)      Extend the staff object to capture Agent details and also allow accounts (of certain product types only) to be opened for staff who are agents

b)      Introduce User to Entity mapping table – similar to point b) above

 

I like Option 1 better, as:

-          It enables self-service channels (like internet banking) for Clients too

-          Existing client level reports and navigation can be re-used for Agents too

-          If an Agent has access to clients’ (similar to a staff role) accounts – then we may need to introduce a Client-to-Client-relationship table with a “relationship type” that will define the kind of access an agent (who is also a client) has on his/her clients.

 

Thanks
Binny

[Antonio Carella]

Hi everyone, 

James, yes, the summary above captures our conversation. 

Thanks

Antonio

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
Mifos-developer mailing list
mifos-d...@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer

[James Dailey]

Binny - Comments inline. 

On Fri, May 23, 2014 at 4:05 AM, Binny Gopinath Sreevas <binny.g...@gmail.com> wrote:

James, Vishwas,

 

I am assuming that:

a)      an agent will not be able to view the client accounts, but will only be able to view transactions that this agent did with the client

AGREED.  

b)      a client will not be explicitly mapped or tied down to an agent i.e. a client can be serviced by any agent

AGREED.  

 

I agree with you on introducing a linking table to link a user with Client/Staff/Agent etc.

 

Some thoughts:

Option 1:

a)      Extend the client entity to represent an Agent too – do you see any pitfalls in doing this?

AGREED.  This is the design Antonio and I are proposing.   

b)      Introduce a “User” to “Entity” mapping table – a user can be mapped to more than one entity (which can be either a staff or a client/agent)

o   A “relationship type” field in this table will define the kind of authorization this user has on the entity

Examples:

User1 à is à Client1 (has full access to Client1’s accounts)

User2 à is à Staff1

-          if Staff 1 is not a Relationship Officer, then User2 has full access to Staff1’s branch data

-          If Staff1 is a Relationship Officer, then User2 has access to only specific clients who are mapped to Staff1

Yes.   

c)       Does it make sense to introduce a “segment” field for clients? This will be used to classify clients as “agents” and any other “types” of customers:

o    “Agent” will be one of the segments

That's a good idea.   

o   Other segments could be Retail Customers, SMEs (Small Medium Enterprises), VSEs (Very Small Enterprise) etc.

o   In a typical banking scenario – it could have values like Wealth Customers, Corporate Customers etc.

Exactly, that is needed if Mifos is to be used by many MFIs that lend to both individuals and to small companies - its often missed in requirements gathering.   

Ideal solution will be to introduce a type (Personal vs. Non-Personal customer) and a customer-segment

Also, we may need to enable segment-specific data tables for Clients – so that Agent details can be captured easily.

Eventually, we could introduce product level restrictions for different segments (ex. Agents cannot have loan accounts)

 

Option 2:

a)      Extend the staff object to capture Agent details and also allow accounts (of certain product types only) to be opened for staff who are agents

b)      Introduce User to Entity mapping table – similar to point b) above

 

I like Option 1 better, as:

-          It enables self-service channels (like internet banking) for Clients too

-          Existing client level reports and navigation can be re-used for Agents too

-          If an Agent has access to clients’ (similar to a staff role) accounts – then we may need to introduce a Client-to-Client-relationship table with a “relationship type” that will define the kind of access an agent (who is also a client) has on his/her clients.

Binny - I agree Option 1 is better.  

Thanks
Binny

 

 

From: James Dailey [mailto:jamesp...@gmail.com]
Sent: 23 May 2014 11:02
To: Mifos software development
Subject: [Mifos-developer] Customer as User

 

Vishwas, 

 

A few weeks ago I had a discussion with Binny about the Client_As_User need in MifosX.  He mentioned you would be the one to discuss this with. 

 

This came up in the context of the PayGoSolar GSOC project and how we are thinking about 3rd party Agents, but is actually much broader. 

 

Currently MifosX Clients (aka Customer) cannot login themselves and see just their accounts.  Therefore, as an example, Internet Banking for a Customer is not supported. 

 

In the Agent Model that we are proposing, the use case is for the Agent to accept physical cash and make a transfer from his account to the Client (Customer) account. (CashIN)  This is how many Agent models are implemented as it creates an accounting record.  It is even more important that the record exists when the cash movement is from the Client (Customer) Account outward to the Agent.  (CashOut)    This would be implemented on the Android and the idea is to have the Agent be a Client (Customer) with a User Account linked to his and only his accounts. He has permissions to transfer funds from his account to another account after authentication.  

 

Again, for Internet Banking, general Customer Access use case, Agent use cases, the current User/Role permission schema and how it meshes with Staff/Hierarchy is insufficient and needs to be revised.

 

Now, I am not sure if you have a design yet, but what I have discussed with Binny and again with Antonio is an approach that involves delinking the current User/Role from Staff/Hierarchy models and replacing that with a new concept of a linking table between Users and Clients/Staff.  

 

Users -->  Linking table <---  Clients --> Accounts_belongs_to_Clients 

Users -->  Linking table <---  Staff (for backwards compatibility) -->Accounts_Assoc_Staff

 

The Linking Table is fundamentally just mapping the UserFK with the ClientFK.  

Also, Linking Table <---> Permissions 

 

I'm also sure its not that simple. 

 

Could you let us know what your thoughts are in this regard?  Antonio - did I capture our conversation ok?  

 

Others please feel free to chime in if you have a design or were involved in the original design and can shed light on the best way to proceed.  

 

Regards, 

- James Dailey 

 

 

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
Mifos-developer mailing list
mifos-d...@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer

--
James Dailey
skype: jdailey

[Vishwas Babu]

James, Antonio and Binny,

Reiterating the requirements in the thread (to ensure that there is no gap in my understanding)

Req 1: It would be nice to have a self service portal for a Customer, where are customer can 

a) View his basic details

b) View "some" details of his loans (with certain restrictions, say maybe only active loan accounts or accounts in a set of statuses which can be safely shared with a customer)

c) View "some" details of his  savings accounts (with similar restrictions as above)

d) Optionally transfer money from one of his savings account to any other savings accounts whose number is known to him. This would work like a regular account transfer, i.e you cannot undo a transaction you made etc. There is no concept of maker checker etc (which is a possibility for any account transfer done at the back office by existing users)

Req 2:The project goal is to have "Agents" who needs seem identical to those of the Customer service portal described above

Is the Agent additionally also allowed to transfer funds from the account of any other user into his account? ( If so, modelling him as a customer would be misleading )

Now, given that the permissions we associate with a customer are very different from those we to associate with the existing "Users" (where "users" refer to back office employees). Shouldn't they be kept completely separate?

If we were to design a Customer service portal, the initial inclination would probably be to 

1) Store customer login details etc in the customer table or any other table linked to a customer. Would not want to mix them with the user table and potentially affect query / caching performance on the user table ( given that the number of staff/users would be negligible compared to the number of customers needing self service )

2) Have separate set of cleaner API's for Client activities (and their associated permissions etc), based on the assumption that we might want to have restrictions on the kind of data a Client can view on his own loan and savings (internal states and notes are meant for the MFI's etc) and we cannot really reuse any exiting API as is for customer consumption. So, we would essentially be building wrappers on exiting API's

3) Down the line, Organizations would want to have the flexibility of deploying the "Client Self Service portal" separately (maybe talking to a replicated database etc) . The primary goal would always be to ensure maximum availability for users against customers...

So technically, we would probably add the MifosX platform codebase as a dependency for the Client access portal gradle project and reuse most of the existing services etc and add the relevant new API'S and client authentication. (might be easier to logically separate out the functionality in the existing code base  and ignore this requirement for the first cut)

4) Have a Client Portal Android app different from a backend android app (as there might not be any real re-usability between a backoffice android app and a customer self service app)

5) If we were to build a separate Web app for the customer portal, create a new codebase for the same (the backoffice app is heavy due to functionality it supports)

If we are also considering Option 2  for achieving agent functionality (Modelling Agents as Staff) . Do we intent to extending savings so that it can be linked to a staff/user etc? (seems to introduce a bit of complexity)

Would an approach similar to https://mifosforge.jira.com/wiki/display/projects/Teller+Cash+Management suffice ? 

This would work best if you enable accounting for a savings product, so 

a) We mark a user as an "Agent" and associate deposit permissions for savings accounts with him

b) Link a ledger account for the Agent Entity as a whole

c) For any activity made on a savings account by an agent, set the Savings Reference (Fund source) to the Agent Ledger account. 

d) Create reports on the ledger account filtered by Agent (user id) to view  cash in/out etc for a particular agent

Regards,

Vishwas

P.S: These are initial thoughts and some/most of it might be drivel. It happens quite often that I completely misunderstand requirements....

[James Dailey]

Vishwas - comments inline.  

On Sun, May 25, 2014 at 12:15 PM, Vishwas Babu <vishwa...@gmail.com> wrote:

James, Antonio and Binny,

Reiterating the requirements in the thread (to ensure that there is no gap in my understanding)

Req 1: It would be nice to have a self service portal for a Customer, where are customer can 

a) View his basic details

b) View "some" details of his loans (with certain restrictions, say maybe only active loan accounts or accounts in a set of statuses which can be safely shared with a customer)

c) View "some" details of his  savings accounts (with similar restrictions as above)

d) Optionally transfer money from one of his savings account to any other savings accounts whose number is known to him. This would work like a regular account transfer, i.e you cannot undo a transaction you made etc. There is no concept of maker checker etc (which is a possibility for any account transfer done at the back office by existing users)

James: Agreed. This is the Nice To Have at this point, although I would argue that if we make a design that supports it, then it could largely be for "free". 

 

Req 2:The project goal is to have "Agents" who needs seem identical to those of the Customer service portal described above

Is the Agent additionally also allowed to transfer funds from the account of any other user into his account? ( If so, modelling him as a customer would be misleading )

James:  Agents in the first use cases needed would only be allowed to transfer from their "current account" to the "Current Account" of another Customer.   (note, we need better language around "savings accounts" in general - but out of scope for now).   As I noted, inbound deposits to a Customer Acct are generally considered safe. 

Agents models however must also be allowed to make payments "authorized on behalf of" the Customers.  While the authorization schema - how it is set up, how it is enforced, etc, is beyond the scope of this GSOC project, my hope is that we can make a good design choice here for the long term. 

Agents are therefore somewhere in between Customer and Field Staff.  They are not employees of the Bank/MFI.  They are independent, and/or they may be part of a single "Agent Network".  

 

Now, given that the permissions we associate with a customer are very different from those we to associate with the existing "Users" (where "users" refer to back office employees). Shouldn't they be kept completely separate?

James: This is the crux of the discussion.  I agree that this is where we are and am arguing that we need to rethink this model.  I believe that a better design is to generalize Users to include ALL USERS with a special case for back office employees.  Overlapping and yet mutually exclusive permission schemas seem really hard to maintain.   

 

If we were to design a Customer service portal, the initial inclination would probably be to 

1) Store customer login details etc in the customer table or any other table linked to a customer. Would not want to mix them with the user table and potentially affect query / caching performance on the user table ( given that the number of staff/users would be negligible compared to the number of customers needing self service )

2) Have separate set of cleaner API's for Client activities (and their associated permissions etc), based on the assumption that we might want to have restrictions on the kind of data a Client can view on his own loan and savings (internal states and notes are meant for the MFI's etc) and we cannot really reuse any exiting API as is for customer consumption. So, we would essentially be building wrappers on exiting API's

3) Down the line, Organizations would want to have the flexibility of deploying the "Client Self Service portal" separately (maybe talking to a replicated database etc) . The primary goal would always be to ensure maximum availability for users against customers...

So technically, we would probably add the MifosX platform codebase as a dependency for the Client access portal gradle project and reuse most of the existing services etc and add the relevant new API'S and client authentication. (might be easier to logically separate out the functionality in the existing code base  and ignore this requirement for the first cut)

4) Have a Client Portal Android app different from a backend android app (as there might not be any real re-usability between a backoffice android app and a customer self service app)

James: That is a key question - my *hope* is that the infrastructure of the Backend Android App (framework, libraries, components, etc) can be leveraged fully.  Perhaps a separate build can be made, where certain components are included or not based on the target apk.  

5) If we were to build a separate Web app for the customer portal, create a new codebase for the same (the backoffice app is heavy due to functionality it supports)

If we are also considering Option 2  for achieving agent functionality (Modelling Agents as Staff) . Do we intent to extending savings so that it can be linked to a staff/user etc? (seems to introduce a bit of complexity)

Would an approach similar to https://mifosforge.jira.com/wiki/display/projects/Teller+Cash+Management suffice ? 

James:  I understand the point, however Tellers are very conceptually different from Agents.  Agents are intentionally meant to refer to "3rd Party Agents" as found in the regulations of many countries, where such models are allowed.  

* Agents must be registered individually and KYC maintained on them.  

* Additional documentation about each Agents must be maintained. 

* Agents have only the funds available in their accounts for transfer 

* Limits to Agent activities on Customer Accounts must exist 

* Agents are "pre-authorized" to initiate transfers to an account (inbound) 

* Agents may be part of an Agent Network, which does account balancing across the network-nodes 

While important differences exist, the Agents should be kept as independent Accounts - rather than a single "Agent Entity" i.e. that is why I don't think tying them to a specific Ledger Account makes sense legally and operationally.  

In any case, the important thing is to get to a design that can be:

a) forward compatible with the general Agent model needed by MifosX ; and 

b) fulfills the specific GSOC payGoSolar agent model needs. 

This would work best if you enable accounting for a savings product, so 

a) We mark a user as an "Agent" and associate deposit permissions for savings accounts with him

b) Link a ledger account for the Agent Entity as a whole

c) For any activity made on a savings account by an agent, set the Savings Reference (Fund source) to the Agent Ledger account. 

d) Create reports on the ledger account filtered by Agent (user id) to view  cash in/out etc for a particular agent

Regards,

Vishwas

P.S: These are initial thoughts and some/most of it might be drivel. It happens quite often that I completely misunderstand requirements....

  

James:  Going this direction means that we punt on the larger design questions I think.  Is that right?  

[Vishwas Babu]

Hi James,

Thanks for the detailed overview of the Agent model and it does make perfect sense to model an Agent as a customer based on the requirements you have shared.

Binny and I had a quick chat regarding similar requirements shared by other organizations over the last few days.

A particular Organization we spoke to has an (Partner) Agent network whose requirements are somewhat identical to those you have shared. In addition, they optionally give agents the ability to also collect loan repayments directly on behalf of the Bank which is then deposited back to the Bank at the end of every business day etc (so for loan repayments, they expect the agents to behave similar to loan officer, as in there is no transfer happening from current accounts etc, and the agents are allowed to record repayments on Loans directly from their Android devices following which sms receipts are sent out to the customer etc). They was also talk about giving agents access to Basic client/loan data when agents are linked to particular "Centers" or Clients directly.

Taking these new requirements into cognizance, Binny and I now think that it would be better to add a discriminator to the staff for identifying them as Agents/External partners and extending savings so that It can be linked to staff accounts.  

Binny: Can you please confirm that I have captured our discussion accurately?

Regards,

Vishwas

------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk

[Binny Gopinath Sreevas]

Vishwas,

 

Do we want to add a discriminator or add a new entity itself called Agent?

If we add a discriminator we will need to modify all existing staff based queries to include this discriminator in the where clause to restrict it to only actual staff (and not agents).

 

Thanks
Binny

[Ed Cable]

Hi all,

Here's my crack at notes from today's call. Vishwas and others please revise if I didn't capture everything correctly:

http://goo.gl/AIV7B4

Customer/Client as User Discussion

June 3, 2014

On the Call - James, Antonio, Binny, Vishwas, Ed

Plan of Action

Extend as Client Object

For the short-term, ideal course to implement the self-access portal for client/simple PayGoSol agent use case is to extend the client object which will allow client-as-agent to log into system, have permissions to view loans, view savings, and do account transfer.

• Might not cover all agent scenarios but all the work is necessary and there will be no wasted effort

• Client level of permissions (will always be the model needed for direct client banking)

• Linking of client accounts to staff accounts (this is standard practice in other systems to allow staff to have savings, etc.)

	Pros	Cons
Extend as Client Object	Simpler, technical - have access to all accounts, etc. From API perspective, can clearly separate APIs that client has access to vs. that which staff has access to. Clients won’t accidentally have ability to view other loan/savings, etc.	(for agent model) - Not right from functional perspective as agents are not clients. For normal operations, how to separate clients from clients-as-agents.
Extend as Staff Object

• Use cases supported:

• Client can directly view their own loan or savings account details

• Client can transfer funds within their own accounts

• Client can transfer funds to another account.

• Implementation Plan

• API for /loans /savings /customer - fetching loans/savings/customers - add wrapper for these so they can be client-level permissions

• Extend permissions table to add another column for client permissions

• Make it so only clients can have these permissions, don’t want normal users to have access to these - as they will already use existing APIs

• Filter out these client permissions from permissions view for other users

Link Client to Staff Account

Clients-as-agent need ability to create new accounts so they will have to use staff-level permissions to do as such but want client to have only one login.

• Use cases supported

• Client-as-agent being able to open up new PayGoSol accounts

• Staff being able to have their own savings accounts.

• Implementation Plan

• Modify client creation API so there’s the ability to create a logged-in user at time of client creation.

• Through model-linking will link client account to staff account so they have back-office permissions.

• Separate staff permissions then so staff can’t make transactions to their own accounts as staff.

Open Issues

• For normal back-office operations, we would need to exclude clients-as-agents from dropdown lists of client and client reports

• Vishwas: for reports, can do this by excluding all clients who are linked to staff

• For dropdown of client lists, it’s possible to exclude as well.

Future:

• For full support of agent model, explore if a separate agent entity type needs to be created

• Binny to start a wiki page documenting:

• Use cases of an agent

• Pros and Cons of each approach.

On Sat, May 31, 2014 at 11:57 PM, Sander van der Heyden <sandervan...@musoni.eu> wrote:

Unfortunately both slots are blocked in my calendar.  But feel free to go ahead without me.

Just some general feedback I picked up (or misunderstood) during the thread below. I think there are currently 2 seperate things which are seperate on a technical level, but linked on the functional.

First is the differentiation in customer types, between agent, business, individual/jgl customer. All of these types need to have certain KYC information tracked, which is a a nice link-in for the MifosX datatable concept, which is already there. I think the current datamodel with the m_client table already supports all of these types, if we add a differentiator there. If we make sure the datatables concept is able to handle the mapping between the customer type set in the m_client table and the datatables linked to that type, we can also track whatever information we want on that customer type. 

For instance, James mentioned that an agent needs to keep a float with the institution, which would be nothing else than a regular savings account (with or without overdraft) which would then be used to transfer to/from clients. So client pays 10 to agent, agent does an account transfer in the system, and then deposits the 10 later on. But in the meantime his balance in the system is -10. This is exactly the same way M-PESA and others work with their agent model. This would be a relatively simple first implementation. Similar things would happen for a "normal" client or business.

The next functional requirement is the ability for different customer types/user types to be able to log in to the system and perform certain tasks. Although the current authentication mechanism works pretty well, and can be extended as well, I think a fair bit of rethinking of the rights and roles model would be required to make this secure enough to use. But the current model might be a good start to add these users to the users table as well (if possible, otherwise we should just authenticate against a view on top of 2 tables?), and then making sure that each customer type has a predefined role as part of the system configuration. 

These roles could then be validated for not having super-admin-type of rights (to safeguard MFI's from accidental massive security breaches). Or do we want to give certain permissions the ability to only be given to system users instead of customers (flag in m_permission)? I think a very key requirement would be as well to see that the rights and roles model is extended with some limits, to make sure customers can only transfer X etc. I will see if I can find some east african central bank regulations around the types of limits you need here.

Just some thoughts on the sunday morning, feel free to let me know if you have any questions.

Sander

--

Sander van der Heyden

CTO Musoni Services

Mobile (NL): +31 (0)6 14239505
Mobile (Kenya): +254 (0)707211284
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter! 
Postal address: Hillegomstraat 12-14, office 1.11, 1058 LS, Amsterdam, The Netherlands

On 1 Jun 2014, at 03:59, Binny Gopinath Sreevas <bi...@confluxtechnologies.com> wrote:

 

Prefer the Tuesday time slot as it is a little easier on my evening .. J

 

Thanks 
Binny

 

 

From: Ed Cable [mailto:edc...@mifos.org] 
Sent: 31 May 2014 03:00
To: James Dailey
Cc: Binny Gopinath; Vishwas Babu; Antonio Carella; Markus Geiß; Sander van der Heyden
Subject: Re: [Mifos-developer] Customer as User

 

Would be helpful if I actually included Sander's email :)

 

Sander - adding you to this thread in case you are ready to weigh in with some of your potential customer as user use cases.

 

Ed

 

On Fri, May 30, 2014 at 2:19 PM, Ed Cable <edc...@mifos.org> wrote:

Let me also add Sander to this thread as well given the potential work his team may have going forward with their direct online banking use cases.

 

Ed

 

On Fri, May 30, 2014 at 2:16 PM, James Dailey <jamesp...@gmail.com> wrote:

Vishwas, Binny & Ed, 

 

As mentioned on the GSOC call, let's have a discussion to close out this issue and move forward with a design. 

 

Markus has asked to be part of this as he has an interest in seeing an Agency model supported and believes also that the batch API work will need to take into account the way that the Agent data modeling and API calls are constructed. 

 

Binny queued up the question which begs the question about the design - see below.  

 

Ed mentioned there is a client/partner organization with Agent requirements - we should get those as part of this discussion.  

 

Antonio is going to have this as a blocker in his design in the next few weeks, so its important we resolve soon-ish.  

 

Given time differences and my schedule, I have available next week: 

Tuesday 6:30-7:30am PDT / Tuesday 7pm - 8pm IST 

Thursday 9:30am - 11am PDT/ 10pm - 11:30pm IST 

 

Do either of those work?  

 

Regards, 

James 

 

---------- Forwarded message ----------
From: Binny Gopinath Sreevas <binny.g...@gmail.com>
Date: Thu, May 29, 2014 at 5:32 AM
Subject: Re: [Mifos-developer] Customer as User

To: Mifos software development <mifos-d...@lists.sourceforge.net>

Vishwas - comments inline.  

 

Would an approach similar to https://mifosforge.jira.com/wiki/display/projects/Teller+Cash+Managementsuffice ? 

 

 

 

------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet

Mifos-developer mailing list
mifos-d...@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer

 

-- 
James Dailey
skype: jdailey

 

--

Ed Cable

Mifos Community Manager

Director of Community Programs, Mifos Initiative

edc...@mifos.org | Skype: edcable | Mobile: 484.477.8649

 

Collectively Creating a World of 3 Billion Maries | http://openmf.org  

 

Note: As of Jan 1, 2014 my email has changed from edcable@openmf.org to edcable@mifos.org. Please update your address book accordingly.

 

 

 

--

Ed Cable

Mifos Community Manager

Director of Community Programs, Mifos Initiative

edc...@mifos.org | Skype: edcable | Mobile: 484.477.8649

 

Collectively Creating a World of 3 Billion Maries | http://openmf.org  

 

Note: As of Jan 1, 2014 my email has changed from edcable@openmf.org to edcable@mifos.org. Please update your address book accordingly.

--

Ed Cable

Mifos Community Manager

Director of Community Programs, Mifos Initiative

edc...@mifos.org | Skype: edcable | Mobile: 484.477.8649

Collectively Creating a World of 3 Billion Maries | http://openmf.org  

Note: As of Jan 1, 2014 my email has changed from edcable@openmf.org to edcable@mifos.org. Please update your address book accordingly.

[Markus Geiß]

Sorry for not attenting ;) but I was pulled in a Workshop with Actuate (BIRT) for the whole week.

Here are my 2 cents:

Is an Agent really a separate entity? I think it is a special Role for a Staff with limited permissions to it.

I'm not sure about an Agency, maybe it could be modeled as a special kind of an Office?

This would ease the changes and we could use existing functionality. At least for me it would feel weird to model an Agent as a Client and I'm sure this will come back to us in the future with special handling all through the code.

Cheers

Markus 

--

YAGNI likes a DRY KISS

[Binny Gopinath Sreevas]

Markus,

 

Noting down some of my thoughts after yesterday’s call.

 

An Agent would have: one user record, one client record and one staff record.

 

We probably may need to introduce a mapping between a user and one or more entities to capture this. Example:

                AgentUser1 is Client1

                AgentUser1 is Staff1

               

                AgentUser1 may be mapped to multiple roles like ClientUserRole, AgentUserRole and one of the staff roles. This mapping will derive the kind of data a user has access to.

 

In the example of pay-as-you-go-solar: an agent will be mapped to two roles:

                                a) Client-User-Role

                                b) Agent-User-Role - agent role will have rights to create a client too and while creating - open a default savings account too for this customer

 

                The Agent App’s user-interface would be built to deal with both client self-service tasks as well as certain staff functionality like “creating customers with a default account”.

               

                In my opinion we should eventually be introducing, a data-scope discriminator for a role which could have values like:

                                OWN - will have access to only own data (ex. a client user)

                                MAPPED - will have access to only entities explicitly mapped to entities of this user (ex. a user who is loan officer – who will be mapped to a staff)

                                BRANCH - will have access to all data of the branch to which this entity is mapped (ex. a branch staff or head office staff)

               

                Also, customer could have a new field called “Recruited By” or “Onboarded By” – to keep track of who/which agent brought this client in.

 

This is the reason why I think it is ok to start off on the agent model by first enabling client-self-service access. Do you still see a concern?

Is my thoughts above in line with what others too are thinking?

 

Vishwas,

 

I am dead against creating client-user specific APIs in Mifos X. I am of the opinion that security and functionality should not be handled this way, but should be handled in a  generic reusable way by using permissions and the above "user-to-entity mapping" and by introducing "data-scope-discriminators" for roles or some similar mechanism. It may be more complicated, but will be more suitable if we want to introduce different types of “Client User Roles” – like “SME users”, “private banking users” and “normal internet-banking users”.

 

Thanks
Binny

 

 

From: Vishwas Babu [mailto:vis...@confluxtechnologies.com]
Sent: 03 June 2014 22:45
To: Markus Geiß
Cc: Ed Cable; Sander van der Heyden; Mifos software development; Binny Gopinath Sreevas; James Dailey; Antonio Carella
Subject: Re: [Mifos-developer] Customer as User

 

Agree with you Markus, the broad consensus during the call was to model the Agent as a staff and for any savings accounts required for an agent, we would first create a customer account for him (so he could use the customer self service portal for account transfers etc)

 

Will be updating the entire design we discussed at https://mifosforge.jira.com/wiki/pages/editpage.action?pageId=72908832 in another 4-5 hours

 

Regards,

Vishwas

 

On Tue, Jun 3, 2014 at 9:35 AM, Markus Geiß <mgei...@gmail.com> wrote:

Sorry for not attenting ;) but I was pulled in a Workshop with Actuate (BIRT) for the whole week.

 

Here are my 2 cents:

 

Is an Agent really a separate entity? I think it is a special Role for a Staff with limited permissions to it.

 

I'm not sure about an Agency, maybe it could be modeled as a special kind of an Office?

 

This would ease the changes and we could use existing functionality. At least for me it would feel weird to model an Agent as a Client and I'm sure this will come back to us in the future with special handling all through the code.

 

Cheers

 

Markus 

On Tue, Jun 3, 2014 at 6:20 PM, Ed Cable <edc...@mifos.org> wrote:

Hi all,

Here's my crack at notes from today's call. Vishwas and others please revise if I didn't capture everything correctly:

 

http://goo.gl/AIV7B4

 

Customer/Client as User Discussion

June 3, 2014

On the Call - James, Antonio, Binny, Vishwas, Ed

Plan of Action

Extend as Client Object

For the short-term, ideal course to implement the self-access portal for client/simple PayGoSol agent use case is to extend the client object which will allow client-as-agent to log into system, have permissions to view loans, view savings, and do account transfer.

·         Might not cover all agent scenarios but all the work is necessary and there will be no wasted effort

o    Client level of permissions (will always be the model needed for direct client banking)

o    Linking of client accounts to staff accounts (this is standard practice in other systems to allow staff to have savings, etc.)

 

	Pros	Cons
Extend as Client Object	Simpler, technical - have access to all accounts, etc.   From API perspective, can clearly separate APIs that client has access to vs. that which staff has access to. ·         Clients won’t accidentally have ability to view other loan/savings, etc.	(for agent model) - Not right from functional perspective as agents are not clients. For normal operations, how to separate clients from clients-as-agents.
Extend as Staff Object

 

·         Use cases supported:

o    Client can directly view their own loan or savings account details

o    Client can transfer funds within their own accounts

o    Client can transfer funds to another account.

·         Implementation Plan

o    API for /loans /savings /customer - fetching loans/savings/customers - add wrapper for these so they can be client-level permissions

o    Extend permissions table to add another column for client permissions

§  Make it so only clients can have these permissions, don’t want normal users to have access to these - as they will already use existing APIs

·         Filter out these client permissions from permissions view for other users

 

Link Client to Staff Account

Clients-as-agent need ability to create new accounts so they will have to use staff-level permissions to do as such but want client to have only one login.

·         Use cases supported

o    Client-as-agent being able to open up new PayGoSol accounts

o    Staff being able to have their own savings accounts.

·         Implementation Plan

o    Modify client creation API so there’s the ability to create a logged-in user at time of client creation.

o    Through model-linking will link client account to staff account so they have back-office permissions.

§  Separate staff permissions then so staff can’t make transactions to their own accounts as staff.

 

Open Issues

·         For normal back-office operations, we would need to exclude clients-as-agents from dropdown lists of client and client reports

o    Vishwas: for reports, can do this by excluding all clients who are linked to staff

o    For dropdown of client lists, it’s possible to exclude as well.

Future:

·         For full support of agent model, explore if a separate agent entity type needs to be created

o    Binny to start a wiki page documenting:

[Vishwas Babu]

Binny,

>>I am dead against creating client-user specific APIs in Mifos X. I am of the opinion that security and functionality should not be handled this 

https://mifosforge.jira.com/wiki/display/MIFOSX/Pay+as+you+go+solar+Module lists the generic extensions that could be built to support the following

a) Client self service portal

b) Staff having customer accounts and separate permission checks for the accounts

b) Expanding staff to include any associates (for lack of a better term) , discriminators for associates , linking data scopes to discriminators, ability to define hierarchies of associates (and the resultant chaining of data scopes) and allowing linking multiple associates to an account  (center/group/client/loan/savings)

This isn't very different from what you describe. The demarcation between client portal api and back office api's is suggested mainly for the reasons listed at https://mifosforge.jira.com/wiki/display/MIFOSX/Pay+as+you+go+solar+Module#PayasyougosolarModule-ClientSelfServicePortal

@Sander , Pramod, Nayan, Ashok, Michael, Markus et al. : Do you have any thoughts on the same? This might be something we can discuss on the developer call tomorrow

Regards,

Vishwas  

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

[Sander van der Heyden]

Hi All,

Sorry I could not make it to the call, seems like you had a very interesting discussion. Let's discuss indeed in the developer call. 

I was inclined to agree with Binny on the duplication, as the features are 95% identical and it seems bloated. When reading up on the actual proposed integration I think it can work quite well. But the main reason for me would be  when you might want to put far stricter firewall/load-balancing rules on one part of the API's (Core) than the other (client) (from an infrastructural perspective). This makes that pretty easy.

 At the same time I think that a lot of the extensions of the current rights and roles framework can be beneficial on many more levels than just client-facing. Limits etc that would have to come in to play might also work on your regular users (and are quite common in other systems). So my ideal situation would be for the user entity to get mapped to either staff / client table. Possibly the scoping in the user entity needs to be made more fine-grained than just offices. Not sure what good datascopes might be, but from the top of my head: Client (type) / Group / Center / Branch / Institution. Whereby all of these can be derived from either the linked staff member, or the linked client so no need to really select them separately. In this situation a client can get a client-type such as individual, business / agent etc. Roles mechanism becomes more fine-grained allowing to setup the roles for these different user types. 

Reason for modelling an agent as a user of type client with  client_type agent would be that the float account is the foremost thing the agent has, all actions that he does should involve that account. If not, then you start opening up a huge possibility for fraud/risk when agents are allowed to transfer from client A to B without their float account in between. If all transactions go through the float account anyway, there is no longer a need to make this into a very specific user type and he is much more like a client that has some extra rights.  

Sander

--

Sander van der Heyden

CTO Musoni Services

Mobile (NL): +31 (0)6 14239505
Mobile (Kenya): +254 (0)707211284
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter! 
Postal address: Hillegomstraat 12-14, office 1.11, 1058 LS, Amsterdam, The Netherlands

 

Sander

<image001.png>

http://p.sf.net/sfu/NeoTechMifos-developer mailing list

[Vishwas Babu]

Hi All,

We had a number of question related to this design in the developer call. The questions and their answers have been added to the wiki at https://mifosforge.jira.com/wiki/display/MIFOSX/Pay+as+you+go+solar+Module#PayasyougosolarModule-Discussions

This should hopefully add more clarity on the suggested design. Please feel free to add any additional questions that may have been missed out into the wiki.

Regards,

Vishwas

[Sander van der Heyden]

Hi Antonio, James,

I was wondering if you have been able to implement the structure described below as part of the PayGoSol work, and if so where it can be checked out? We are keen to start re-using some of this work in the upcoming weeks and would be very helpful to know the status.

Thanks,

Sander

--

Sander van der Heyden

CTO Musoni Services

Mobile (NL): +31 (0)6 14239505
Mobile (Kenya): +254 (0)707211284
Skype: s.vdheyden
Website: musonisystem.com
Follow us on Twitter! 
Postal address: Hillegomstraat 12-14, office 1.11, 1058 LS, Amsterdam, The Netherlands

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."

http://p.sf.net/sfu/SauceLabsMifos-developer mailing list