Currently, the user can't edit the users' birth date. That means if it was mis-entered, they are stuck with a wrong birth date. This should also be something that can be edited.
Note, if/when we fix this-- we'll need to trigger a "duplicity" check for other customers with same name and birthdate. (The original reason we made this field non-editable was because of using it to check for client uniqueness across the database. As long as we trigger the duplicity check, then I'm OK with making this editable).
I personally disagree with this design decision. Although unlikely for a particular MFI, there could be people with the same name born on the same day. It would NOT be incorrect to have these two people in the DB.
Also, some people have to create two system users (same person) because a user cannot take care of more than one branch (a constraint I also find unnecessary strict.) This (inconvenient) workaround would then become impossible unless a wrong birth date would be entered, therefore, introducing incorrect/bad data in the DB circumventing the goal of the duplicity check in the first place.
I would personally do my "duplicity" check based on the user name only.
My two cents.
GH, it is pretty unlikely to get the same name and DOB and the check is a large help in countries where you get people with a lot of the same name. We really only run into issues in places like India where people don't know their exact DOB and just their general age. The workaround is easy, which is to add something to the middle or second last name and alter the field slightly, which will get you past.
That being said, the better solution here would be to create an override function. This is something we might actually think about implementing across the application, especially as we add more potential business roles. Process would be something like
User edits account and it triggers duplicity check
User saves profile (whatever the state is before pending approval)
User notifies staff person with rights to override to review the application
User with rights to override is allowed to approve after the duplicity check is displayed.
Mifos logs the actions for audit purposes
We should also be clear this is for the customers and not Mifos users. Not sure that a duplicity check is necessary for Users.
I just wanted to comment that in versions prior to 2.2.1 you could update the Government ID or DOB by changing the client's status to "on Hold"
so what you need to do is
change client status to "on Hold"
then change it back to active
this is tested on version 1.6, 2.0 and 2.1