Hi Kay
I did a modification to the control flow during the course of the day. I believe the problem with including the data in the new page, was that the general perception was that I was reading spouse/father details in the first page, while reading family details in the second. (reading similar fields across two pages was not a good idea). Currently I am reading data from two pages, like shown below. I hope that's okay. I can revert to the old design if needed, no sweat. Now the control flow is this way. I have provided two configuration properties in the applicationconfiguration.default.properties file ClientInformation.AreFamilyDetailsRequired ClientInformation.MaximumNumberOfFamilyMembers If the clienInformation.AreFamilyDetailsRequired is set to true, and say ClientInformation.MaximumNumberOfFamilyMembers is set to 10, this is the control flow 1) http://tinyurl.com/yk554mf ( the number of members that can be added will be limited to the number in the configuration property, here 10) 2) http://tinyurl.com/ykk4bfy (the number of rows displayed should be number of rows selected in the first page, btw I haven't done it yet. Part of my (ever growing) agenda tomorrow :) ) 3) http://tinyurl.com/yl54s49 (the page expected in the step 2, if the property were set to false) And when its set to false this is the control flow, works like the original thing 1) http://tinyurl.com/yhayg5m 2) http://tinyurl.com/yz29ecg I haven't included middle name ( I just noticed that point in the mail you sent) in this screenshot, will do that tomorrow. (Also the date field looks like a text field, forgot to change that) I think the pictures answer questions 1-6 :) Regarding 7, I am currently not doing any error checking on the fields. I will be doing some basic error checks like date validation, unmarried/widowed can't have spouse etc. I plan to provide configuration properties on how many family member of a particular relationship type can exist . Maybe age validation for children ( for instance they can be only minors?). I should probably make most validations here configurable. I don't think it will be good to do validations across fields ( for instance compare child's age with father) as they may not hold true all the time. Regarding 8, I haven't implemented delete. But obviously it is part of roadmap , I will be doing that in the next few days. I am going to work on the preview part tomorrow. But I need to figure out how to do the edit/delete. I am really sorry I forgot to create the page for this feature on the site. I should have done it today but I forgot about it again :( . Will try to remember and do it tomorrow . Thank you and regards Chandan -----Original Message----- From: Kay Chau [mailto:[email protected]] Sent: Thursday, October 15, 2009 5:18 AM To: Mifos functional discussions Cc: [email protected]; Thandavarayan, Parthasarathy Subject: Re: [Mifos-functional] [Mifos-developer]Feature:Capturingadditionaldetails oftheclients family Hi Chandan, A few more questions ... I am removing mifos-dev as the questions I am asking are still tied to functionality. 1) Do you have a new mockup then with the actual fields? Would be helpful to see that... 2) Is the number of rows for the client's family details dynamic (based on how many family members) or will there be say just 5 blank rows where the client can fill in this information as much as they need. Is there a max that will be imposed? 3) Have you looked at the Define Loan products page right now where if you select "by loan Cycle" for the installments, it dynamically shows the rows needed for that? That could be one option ... though if you are trying to avoid Javascript, that might not help. 4) From your previous email, there were 7 fields GK wants to record for the client 1) First Name, Second Name, Last Name 2) Date Of Birth 3) Relation to the client* 4) Gender 5) Living status** Is that going to be all across the page for each family member? Also, I noticed Middle Name was missing. Since that is in the current information Mifos saves for spouse/father, think it'd be good to keep it consistent. 6) In the scenario you're proposing then, would the existing spouse/father row be replaced by the new rows you are creating if they set the configuration property for "AreFamilyDetailsRequired" to true? 7) What error checking is being done on the fields and will all those fields be required for every person they add as a family member or will only some of them be required? 8) Can you delete a family member? Is that simply editing the client information, and then blanking all the fields in a row? Thanks Chandan for all your work! It would be great to have a wiki page on mifos.org that details what you've been doing, document the questions and answers we've had so far, and provide some use cases so we can better understand the flow of this in the application and make note of what we might need to do later to enhance this feature. Kay > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, October 14, 2009 5:24 AM > To: [email protected]; [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [Mifos-functional] [Mifos-developer]Feature:Capturingadditional > details oftheclients family > > Hi all > > This is to update everyone on the progress of work on this feature. > > > Currently everything is on the first page like before, but there is a > property added into the application configuration property file and > based on the value of this property ( true/false) the data capture > fields will be displayed. > > Basically, to put it in better 'words', currently there is a > {spouse/father field} and the {family details table}. If the > configuration value for 'ClientInformation.AreFamilyDetailsRequired' is > set to false the former will appear and the latter won't. If this > property is set to true, the latter is displayed and former isn't. > > There is a table called family_lookup which is basically a mirror of > spouse_father_lookup with additional rows that have mapping to other > family members ( which are present in the lookup_value). > > I have tried to not modify the already existing jsp/java code till this > point, like I said if the configuration property is set to true the > control flows through the additional code. > > Data is written into the database ( this is data without any > validations) on submit of this page. The target schema for the table > isn't really fixed though, the idea was to complete the cycle once, with > reads from the UI and writes into the database. > > Also, I haven't modified the other jsps/classes to enable 'preview' and > 'edit' for this feature, so there is more work that needs to be done > there. I am postponing the validations part of this enhancements to > after I am done with this (At this point I have a feeling that I will > end up implementing really basic validations, rigorous validations here > can be quite a bother). > > > Regards > Chandan > > > PS: This is with regard to the discussion about where to include the > 'additional field capture' in. Currently I have included it in the same > page as discussed, but please do note that including it in a fresh new > page doesn't mean that the other MFIs, who don't use this feature, will > be accessing this page. This page can always be skipped. So this is not > an issue. Including it in a new page will make the code more cleaner. > > > -----Original Message----- > From: Rao, Chandan > Sent: Friday, October 09, 2009 10:23 AM > To: Mifos functional discussions; Mifos functional discussions > Cc: [email protected]; Thandavarayan, Parthasarathy > Subject: RE: [Mifos-functional] [Mifos-developer] > Feature:Capturingadditional details oftheclients family > > > > Hi! > > > Given that GK is the only MFI (right now) who needs to fill out these > > fields-- we need to make sure that turning on/off these additional > > fields is configurable. We don't want to clutter up the create-client > > pipeline with several new fields that aren't commonly used. > > I am pretty convinced this is the way to go. Seems very sensible. I will > make the appearance of this field configurable. > > > "Will you be adding those 3 lookup fields to the Lookup Options in Mifos > then? What kind of validations are you planning to do on all the > additional fields?" > > I will be using the current lookup_value tables in Mifos. > > "Did you decide not to make the # fields GK needs dynamic then?" > > For now no.Though I haven't really given this much thought. :( If I do > make it dynamic, I don't see how it will be any better than the create > custom field option already present. (i.e i can't write validations for > the dynamic fields) > > > "Will be great if you can share some mockups/screenshots as you work on > this." > I do have a screenshot that i had sent to Dheerendra the day before. It > just had a preview pic of what the final page was intended to look like. > Please ignore the fields. This was just to clarify with them on whether > this was the kind of functionality they were looking for. GK seemed > satisfied with this. > > http://tinyurl.com/ylkllaz > > > > Ryan, regarding the usage of Custom fields. > > GK did give it a try and they decided it didn't really suite the > functionality/ease of use that they were seeking. Also Lack of > validations is a big pain and the current system takes only string > input. > > > > > > -----Original Message----- > From: Kay Chau [mailto:[email protected]] > Sent: Thu 10/8/2009 6:31 PM > To: Mifos functional discussions > Cc: [email protected]; Thandavarayan, Parthasarathy > Subject: Re: [Mifos-functional] [Mifos-developer] > Feature:Capturingadditional details oftheclients family > > Chandan, > > Can you do the same as you did for the age enforcement feature and add a > page to the mifos wiki to detail this feature? > > > Given that GK is the only MFI (right now) who needs to fill out these > > fields-- we need to make sure that turning on/off these additional > > fields is configurable. We don't want to clutter up the create-client > > pipeline with several new fields that aren't commonly used. > > Agree with Emily that these should be configurable. > > > Relationship id, customer id (from customer table), first name, last > name, Date of birth, relationship (lookup), living status (lookup), > gender(lookup) > > Will you be adding those 3 lookup fields to the Lookup Options in Mifos > then? What kind of validations are you planning to do on all the > additional fields? > > > GK also wanted to know If the number of fields could be made dynamic. > As in the ability to make it greater than 5 tomorrow. We were of the > opinion that since this will involve schema and code changes it will be > really hard to make the fields dynamic. > > Did you decide not to make the # fields GK needs dynamic then? > > Will be great if you can share some mockups/screenshots as you work on > this. > > Thanks for following up on this list! > > Kay > > > > -----Original Message----- > > From: Emily Tucker [mailto:[email protected]] > > Sent: Thursday, October 08, 2009 2:48 PM > > To: [email protected] > > Cc: [email protected]; [email protected] > > Subject: Re: [Mifos-functional] [Mifos-developer] Feature: > Capturingadditional > > details oftheclients family > > > > Responding only to mifos-functional list-since my response relates > only > > to the functionality aspects of the email below... > > > > >I have been working on this feature for a couple of days now, > > >I thought I will update the group on my status and issues. > > > > Thanks for the update, Chandan-- and sharing your ideas on your > > approach. > > > > >Please suggest improvements to this control flow/ structure... > > >{I initially thought that the client family details could > > >be put on the same page as the first page (had modified the jsp to > > >reflect this thought process), but there was a opinion that the > > >family details could be moved to a new page. I feel that this is a > much > > better idea.} > > > > Given that GK is the only MFI (right now) who needs to fill out these > > fields-- we need to make sure that turning on/off these additional > > fields is configurable. We don't want to clutter up the create-client > > pipeline with several new fields that aren't commonly used. > > > > Given that, I don't think having a separate page makes sense. Because > > most MFIs would disable/hide these fields, the page would be blank. > (The > > alternative, of course, is that you build it so the page only displays > > if those fields are enabled-- but that approach seems too complicated > > for simply adding additional fields). > > > > Emily. > > > > > > > ------------------------------------------------------------------------ > ------ > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart > your > > developing skills, take BlackBerry mobile applications to market and > stay > > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Mifos-functional mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mifos-functional > > ------------------------------------------------------------------------ > ------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Mifos-functional mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mifos-functional > > > > > > ------------------------------------------------------------------------ ------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Mifos-functional mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mifos-functional ------------------------------------------------------------------------ ------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mifos-functional mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-functional ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mifos-functional mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-functional
