Add ability to edit a user's birth date

Description

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.

Environment

None

Activity

Show:
emilytucker
October 4, 2010, 5:51 PM

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).

Ghislain Hachey
October 4, 2010, 10:08 PM

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.

Regards,


GH

Ryan Whitney
February 9, 2011, 9:09 PM
Edited

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
    *

Ryan Whitney
February 9, 2011, 9:10 PM

We should also be clear this is for the customers and not Mifos users. Not sure that a duplicity check is necessary for Users.

George Lteif
November 2, 2011, 1:34 PM

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"
    fix DOB

then change it back to active

this is tested on version 1.6, 2.0 and 2.1

Assignee

UdaiU

Reporter

Ghislain Hachey

Labels

None

Implementation Priority

None

URL

None

Story Points

None

Team

Core

Scheduled For

None

Epic

None

productboard URL

None

Man Day Estimate

None

Components

Fix versions

Affects versions

Priority

Minor
Configure