[
http://mifosforge.jira.com/browse/MIFOS-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
emilytucker updated MIFOS-3216:
-------------------------------
Fix Version/s: (was: Release E - Iteration 3)
Release E - Iteration 4
> 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
> Assignee: Van Mittal-Henkle
> Priority: Major
> Fix For: Release E - Iteration 4, Release E
>
>
> 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
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Mifos-issues mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-issues
