Review SPI change to support user-defined plugins that deal in data other than
account payments
-----------------------------------------------------------------------------------------------
Key: MIFOS-3216
URL: http://mifosforge.jira.com/browse/MIFOS-3216
Project: mifos
Issue Type: Improvement
Reporter: Sam Birney
Priority: Major
The Mifos deployment I've been helping with has not been able to completely
switch off their old MIS because of a few functional gaps that are not
supported in the application: late penalties, overpayments, write-backs.
After discussing possible approaches, we decided the best strategy to fill
these gaps until Mifos adds this functionality would be a custom plugin that
can import this information from a spreadsheet and store it in a new table.
This table would be outside the mifos schema but in the same database, so it
can have referential integrity with the accounts in mifos and its data can be
displayed in reports alongside standard mifos data.
So, I wrote this new plugin following the example of the bank import plugin.
The concept seems to work well in testing and we think it will address the
customer need. The one catch is that it requires the relevant SPI to widen its
definition of permissible types.
Specifically, in ParseResultDto.java, there are two methods that deal in a
List<AccountPaymentParametersDto>. My understanding is that limits the current
set of possible plugins to be related only to making account payments. For our
new plugin, we would like to have a class that extends TransactionImport.java
and be able to parse and store, for example, a
List<OtherTransactionParametersDto>.
Also, imagine other possible future plugins that might not even be monetary
information at all, perhaps importing GIS information about the physical
locations clients use to make payments.
So, I would propose changing these two methods in ParseResultDto.java to just
deal in a more abstract List<Object>. Or maybe there is something more
specific than Object, but less specific than AccountPaymentParametersDto, but
I'm not sure what that would be. This way each plugin can have flexibility to
parse and store its own type of data, and each will be responsible for
enforcing its own type safety. That makes sense to me, because restricting
plugins to only work on one specific set of columns in a spreadsheet seems
contrary to the purpose of allowing plugins to be user-defined .
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://mifosforge.jira.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Mifos-issues mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-issues
