|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________ Mifos-issues mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-issues
This comment replaces my previous one. Pull Request sent and merged.
After discussion with Marco & Enrique and Keith - we decided
i) role means an employee role (aka m_staff) and not the permission roles (though there's an obvious connection)
ii) we would provide the flexibility to link employees to other employees for the purpose of setting up a hierarchy that can be used for drill down purposes (although we had said to Marco we wouldn't do this in iteration 1 - it turned out it was needed)
Technically, this means we added the 3 following database fields:
m_appuser.staff_id - Allows (optionally) an application user that logs on to be related to an m_staff employee.
m_staff.organisational_role_enum - identifies the role of the employee (at least for the purposes of the TEVI work.
Valid values are Program Director 100, Branch Manager 200, Field Agent Coordinator 300 & Field Agent 400
m_staff.organisational_role_parent_staff_id - identifies who the employee is under (at least for the purposes of the TEVI work.
You can see by the 'at least' comments that we are not saying this implementation will suffice for all organisation role/hierarchy functionality. It might be close though. We've even left the is_loan_officer flag there (which is used to link loan officers to clients and groups. So, in the case of TEVI when defining a loan officer that is a Field Agent (which it always would be) both the is_loan_officer flag and the organisation_role_enum gets set (probably hidden from the user though). This is all to note that 'this can change at some point'. We decided not to try to implement the typical 'flexible' functionality that would allow an employee to play any number of roles and to be linked to other employees in various roles for any number of different purposes... cos it would mean an explosion of api and UI functionality and we still might not get it right first time.
Notes
-------
A) To test out changes - add "&applicationProfile=TEVI" to the end of the reference app url.
For localhost this would be something like (depending on the location of your github directory):
file:///C:/dev/mifosxfork/mifosx-community-apps/IndividualLendingGeneralJavaScript/IndivLendHome.html?tenantIdentifier=default&baseApiUrl=https:/localhost:8443/mifosng-provider/api/v1/&applicationProfile=TEVI
B) All custom TEVI code can be seen in file
mifosx-community-apps\IndividualLendingGeneralJavaScript\resources\configs\customisations\TEVICustom.js
In this file 4 roles that match TEVI requirements are catered for.
i) "Program Director"
ii) "Branch Manager"
iii) "Coordinator"
iv) "Field Agent"
A simple, static test message is shown in each case and this proves that it is working.
Marco, as we've only added the database fields and there is no api or UI that supports you have to (like me) fill in the data yourself.
I set up 4 staff members (for each of the roles) and in the mysql workbench gui filled in the 2 new fields and then set up 4 users and in the mysql worbench gui set the staff_id to the appropriate staff member. So, just a little care is needed until api and UI are done (but this shouldn't stop us moving forward with the landing page work).