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. Agree/disagree/other? -- Adam Monsen ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mifos-functional mailing list Mifos-functional@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mifos-functional
