I'm trying to wrap up the implementation for story 23 ( http://snipurl.com/1xku4 ) and I just wanted to confirm an issue with the PMs (Emily, et al).
My question is about all of the optional states, but I'm hoping the solution for one can be applied to all five. "the flag" below refers to "whether or not the 'pending approval' state is enabled for clients". Meaning, whether or not clients enter a state of "pending approval" upon creation (or are, I assume, automatically approved). Also note that I simply refer to "the config file". In reality there is a "default" or "master" config file, and customizations to settings are placed in a different file; these customizations override default values.
Currently, in the database, the flag is on. This database value will be used to effectively save the state of the current setting for the flag. This is an unfortunate compromise between engineering elegance and the need to complete this story in that a table of configuration data is now being used to save state. At any rate, the config file will be used to override what is in the database.
>From the story (see URL above): once it is turned on, no mechanism is
provided for turning it off. Given this, the config file can only be used to turn on the flag.
The logic to figure out if the flag is on at runtime will be similar to that used to figure out whether loans can be made for groups.
1. is the flag on in the database and is the flag on in the config file? if so, it is "on" to the application. Client Pending Approval state is enabled. 2. else, is the flag off in the database and on in the config file? If so, it it is "on" to the application. Also, the database value will be updated to be "on". The value cannot be turned off after this. 3. else, is the flag on in the database and off in the config? If so, throw an exception at startup.
The only problem with this logic is that the second condition can never be met since the flag in the database is currently on.
Potential solutions: 1. turn the flag off in the database, and off in the config file. For existing installations, the config file must be changed by hand to override the flag value to "on" if support for the pending state is desired. May hide existing records in the "pending" state or cause other unknown/unrelated problems. 2. leave the flag on in the database and on in the config file. No way to turn off the flag. 3. leave the flag on in the database and off in the config file. Non-starter. Causes an exception immediately upon startup since flag cannot be overridden to "off".
I see #1 as the best option for now since the config file will probably need editing, and I don't see the existing data migration issues as severe.
I would say option 1 is the least desirable from an operational perspective, as MFI's are more likely to want the Approval to be required than not, hence the client should immediately enter the pending approval state.
[mailto:mifos-functional-boun...@lists.sourceforge.net] On Behalf Of Adam Monsen Sent: Thursday, January 17, 2008 2:56 AM To: Mifos functional discussions Subject: [Mifos-functional] data migration for process flow optional states
I'm trying to wrap up the implementation for story 23 ( http://snipurl.com/1xku4 ) and I just wanted to confirm an issue with the PMs (Emily, et al).
My question is about all of the optional states, but I'm hoping the solution for one can be applied to all five. "the flag" below refers to "whether or not the 'pending approval' state is enabled for clients". Meaning, whether or not clients enter a state of "pending approval" upon creation (or are, I assume, automatically approved). Also note that I simply refer to "the config file". In reality there is a "default" or "master" config file, and customizations to settings are placed in a different file; these customizations override default values.
Currently, in the database, the flag is on. This database value will be used to effectively save the state of the current setting for the flag. This is an unfortunate compromise between engineering elegance and the need to complete this story in that a table of configuration data is now being used to save state. At any rate, the config file will be used to override what is in the database.
>From the story (see URL above): once it is turned on, no mechanism is provided for turning it off. Given this, the config file can only be used to turn on the flag.
The logic to figure out if the flag is on at runtime will be similar to that used to figure out whether loans can be made for groups.
1. is the flag on in the database and is the flag on in the config file? if so, it is "on" to the application. Client Pending Approval state is enabled. 2. else, is the flag off in the database and on in the config file? If so, it it is "on" to the application. Also, the database value will be updated to be "on". The value cannot be turned off after this. 3. else, is the flag on in the database and off in the config? If so, throw an exception at startup.
The only problem with this logic is that the second condition can never be met since the flag in the database is currently on.
Potential solutions: 1. turn the flag off in the database, and off in the config file. For existing installations, the config file must be changed by hand to override the flag value to "on" if support for the pending state is desired. May hide existing records in the "pending" state or cause other unknown/unrelated problems. 2. leave the flag on in the database and on in the config file. No way to turn off the flag. 3. leave the flag on in the database and off in the config file. Non-starter. Causes an exception immediately upon startup since flag cannot be overridden to "off".
I see #1 as the best option for now since the config file will probably need editing, and I don't see the existing data migration issues as severe.
On Wed, 2008-01-16 at 22:45 -0500, Amy Bensinger (Contractor) wrote: > Hi, Adam.
> I would say option 1 is the least desirable from an operational > perspective, as MFI's are more likely to want the Approval to be > required than not, hence the client should immediately enter the pending > approval state.
Thank you, Amy.
There's actually a fourth option I forgot to mention that is also somewhat workable, at least for new Mifos installations:
4. leave the flag off in the database and on in the config file. Flag will be turned on during the first start-up after the logic is in place. Only way to turn the flag off is to, before first start-up, change the flag in the config file.
I just want to underline the fact that only options 1 and 4 actually provide configurablility of the "pending approval state enabled for clients" flag (even if the only possible customization for this flag is from off to on).
Just talked through this with Emily and she agreed with Amy that using the current setting for the flag ("on") is a good default, and the PMs are ok with the fact that the flag cannot be turned off once it is on.
Additionally, she concurred that the other flags were fine as they currently are in the database. Here's a quick summary of all the flags and their default settings, using the key names as they will appear in the system-wide default configuration file (applicationConfiguration.default.properties):
Since these are the current database defaults, no data migration will be performed on existing data.
This means that, unless a .custom.properties file is placed in the classpath prior to the first deployment of a particular Mifos instance, the values that default to "true" (above) will be permanently in that state.
For folks following trunk development that wish to disable (or keep disabled) any of the enabled process flow optional states above, you can manually set corresponding values in the database to zero and create a .custom.properties file prior to start-up of a Mifos instance using a war built from the HEAD (after I commit the story #23 code). When I commit the code for story #23, I'll mention this again.
Overriding default configuration values is described in this mifos-developer mailing list post: http://tinyurl.com/yw3x96 and all this v1.1 configuration mumbo jumbo will eventually be distilled and added to this "configuring mifos" document on mifos.org: http://tinyurl.com/375mgu
Thank you Emily and Amy for your sage wisdom!
(and Van, and Kim, and Sam, and Aliya, and George, and James, and Tom, and Terry, and everyone else that helps explain to me this interesting engine under the Mifos hood)
