[prev in list] [next in list] [prev in thread] [next in thread]
List: mifos-developer
Subject: Re: [Mifos-developer] Customer as User
From: "Binny Gopinath Sreevas" <binny.gopinath () gmail ! com>
Date: 2014-05-29 12:44:23
Message-ID: 084a01cf7b3a$0cffbd00$26ff3700$ () gmail ! com
[Download RAW message or body]
This is a multipart message in MIME format.
[Attachment #2 (multipart/alternative)]
This is a multipart message in MIME format.
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
From: Vishwas Babu [mailto:vishwasbabuaj@gmail.com]
Sent: 28 May 2014 13:56
To: Mifos software development
Subject: Re: [Mifos-developer] Customer as User
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
On 27 May 2014 22:24, James Dailey <jamespdailey@gmail.com> wrote:
Vishwas - comments inline.
On Sun, May 25, 2014 at 12:15 PM, Vishwas Babu <vishwasbabuaj@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?
On 23 May 2014 22:42, James Dailey <jamespdailey@gmail.com> wrote:
Binny - Comments inline.
On Fri, May 23, 2014 at 4:05 AM, Binny Gopinath Sreevas <binny.gopinath@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:jamespdailey@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-developer@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer
--
James Dailey
skype: jdailey
------------------------------------------------------------------------------
"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-developer@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer
------------------------------------------------------------------------------
"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-developer@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer
--
James Dailey
skype: jdailey
------------------------------------------------------------------------------
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 \
<http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk> \
&iu=/4140/ostg.clktrk Mifos-developer mailing list
mifos-developer@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer
[Attachment #5 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type \
content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 \
(filtered medium)"><style><!-- /* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
mso-fareast-language:EN-IN;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-IN link=blue vlink=purple><div \
class=WordSection1><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Vishwas,<o:p></o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Do we want \
to add a discriminator or add a new entity itself called \
Agent?<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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).<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks \
<br>Binny<o:p></o:p></span></p><p class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><span \
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p \
class=MsoNormal><b><span lang=EN-US \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span \
lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Vishwas Babu \
[mailto:vishwasbabuaj@gmail.com] <br><b>Sent:</b> 28 May 2014 13:56<br><b>To:</b> \
Mifos software development<br><b>Subject:</b> Re: [Mifos-developer] Customer as \
User<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><p \
class=MsoNormal>Hi James,<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Binny and I had a \
quick chat regarding similar requirements shared by other organizations over the last \
few days.<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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. \
<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal>Binny: Can you please confirm that I have captured our discussion \
accurately?<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal>Regards,<o:p></o:p></p></div><div><p \
class=MsoNormal>Vishwas<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal \
style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On 27 May \
2014 22:24, James Dailey <<a href="mailto:jamespdailey@gmail.com" \
target="_blank">jamespdailey@gmail.com</a>> wrote:<o:p></o:p></p><div><p \
class=MsoNormal>Vishwas - comments inline. <o:p></o:p></p><div><p \
class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Sun, May 25, \
2014 at 12:15 PM, Vishwas Babu <<a href="mailto:vishwasbabuaj@gmail.com" \
target="_blank">vishwasbabuaj@gmail.com</a>> wrote:<o:p></o:p></p><div><p \
class=MsoNormal>James, Antonio and Binny,<o:p></o:p></p><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Reiterating the \
requirements in the thread (to ensure that there is no gap in my \
understanding)<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Req 1: It would be \
nice to have a self service portal for a Customer, where are customer \
can <o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>a) View his basic \
details<o:p></o:p></p></div><div><p class=MsoNormal>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)<o:p></o:p></p></div><div><p class=MsoNormal>c) View "some" \
details of his savings accounts (with similar restrictions as \
above)<o:p></o:p></p></div><div><p class=MsoNormal>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)<o:p></o:p></p></div></div><div><p \
class=MsoNormal><o:p> </o:p></p></div></div><div><p \
class=MsoNormal>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". <o:p></o:p></p></div><div><div><p \
class=MsoNormal> <o:p></o:p></p></div><blockquote \
style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Req 2:The project \
goal is to have "Agents" who needs seem identical to those of the Customer \
service portal described above<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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 \
)<o:p></o:p></p></div></div></blockquote><div><p \
class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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". <o:p></o:p></p></div><div><div><p \
class=MsoNormal> <o:p></o:p></p></div><blockquote \
style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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?<o:p></o:p></p></div></div></blockquote><div><p \
class=MsoNormal><o:p> </o:p></p></div></div><div><p \
class=MsoNormal>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. \
<o:p></o:p></p></div><div><div><p \
class=MsoNormal> <o:p></o:p></p></div><blockquote \
style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If we were to \
design a Customer service portal, the initial inclination would probably be \
to <o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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 \
)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal>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<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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...<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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)<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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)<o:p></o:p></p></div></div></blockquote><div><p \
class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><div><p \
class=MsoNormal><o:p> </o:p></p></div><blockquote \
style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm \
6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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)<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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)<o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Would an approach \
similar to <a href="https://mifosforge.jira.com/wiki/display/projects/Teller+Cash+Management" \
target="_blank">https://mifosforge.jira.com/wiki/display/projects/Teller+Cash+Management</a> \
suffice ? <o:p></o:p></p></div></div></blockquote><div><p \
class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal>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. \
<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p \
class=MsoNormal>* Agents must be registered individually and KYC maintained on them. \
<o:p></o:p></p></div><div><p class=MsoNormal>* Additional documentation about \
each Agents must be maintained. <o:p></o:p></p></div><div><p class=MsoNormal>* \
Agents have only the funds available in their accounts for \
transfer <o:p></o:p></p></div><div><p class=MsoNormal>* Limits to Agent \
activities on Customer Accounts must exist <o:p></o:p></p></div><div><p \
class=MsoNormal>* Agents are "pre-authorized" to initiate transfers to an \
account (inbound) <o:p></o:p></p></div><div><p class=MsoNormal>* Agents may be \
part of an Agent Network, which does account balancing across the \
network-nodes <o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><p \
class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In any case, the \
important thing is to get to a design that can be:<o:p></o:p></p></div><div><p \
class=MsoNormal>a) forward compatible with the general Agent model needed by MifosX ; \
and <o:p></o:p></p></div><div><p class=MsoNormal>b) fulfills the specific GSOC \
------------------------------------------------------------------------------
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-developer@lists.sourceforge.net
Unsubscribe or change settings at:
https://lists.sourceforge.net/lists/listinfo/mifos-developer
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic