[
http://mifosforge.jira.com/browse/MIFOS-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kay Chau updated MIFOS-3216:
----------------------------
Assignee: Van Mittal-Henkle
Description:
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 .
was:
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 .
Scheduled For: Product
Fix Version/s: Release E
van, can you review the proposals by Sam
> 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
>
>
> 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
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Mifos-issues mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-issues
