|
||||||||
|
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 |
||||||||
------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________ Mifos-issues mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-issues
Michal,
my thoughts on the database table to support this and some of the rules around it are as follows. Happy for anyone to update them. Also happy to talk about it if my notes are obscure.
m_loan will still contain a field (loan_officer_id) for the current loan officer (if one exists)
In Mifos X, loan officers (is_loan_officer field on m_staff) are linked to loans rather than clients or groups. So, in a report/screen display such as the one mentioned, the key tables would be m_staff, m_loan, m_loan_officer_assignment_history (DDL at end) and m_client. We do have an api where we can setup and run a report/display like this but this Jira is about ensuring the history data is maintained and available for the report.
Notes
loan officer relationship isn't mandatory so can be null. Not sure if we should record history in this case. Initially, I suggest only recording cases where a loan officers is assigned.
The first m_loan_officer_assignment_history entry is recorded (if loan officer is recorded) when the loan is approved (even if the loan officer field is updated earlier). The history start_date is the loan approvedon_date. If the loan is subsequently unapproved, this entry would need to be removed.
After that, changing the loan_officer_id should be restricted to specific API calls
(such as a loan reassignment api and a (bulk) loan officer reassignment api) and not be allowed through the update loan API/UI.
The history start_date (which is the date of reassignment) would be user-provided defaulting in the UI to today.
The history start_date must be on or after the current history start_date.
The end_date (which is a derived field) of the previous entry is then set to the current start_date.
It is possible that a user may want to alter/correct the dates they put in. Maybe this can be Phase 2 functionality and parked for now.
Edge Case: If a loan happens to be reassigned more than once in a day (typically due to input error) just update the current one i.e. its not identical to an audit capability
Only say this because it complicates reporting if more than one loan officer is assigned to a loan in one day (and I don't think is a real world situation). So, maybe loan_id and start_date should be unique.
Suggested database table DDL.
CREATE TABLE `m_loan_officer_assignment_history` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`loan_id` bigint(20) NOT NULL ,
`loan_officer_id` bigint(20) DEFAULT NULL,
`start_date` date NOT NULL,
`end_date` date DEFAULT NULL,
`createdby_id` bigint(20) DEFAULT NULL,
`created_date` datetime DEFAULT NULL,
`lastmodified_date` datetime DEFAULT NULL,
`lastmodifiedby_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`id`),
CONSTRAINT `fk_m_loan_officer_assignment_history_0001` FOREIGN KEY (`loan_id`) REFERENCES `m_loan` (`id`),
CONSTRAINT `fk_m_loan_officer_assignment_history_0002` FOREIGN KEY (`loan_officer_id`) REFERENCES `m_staff` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;