User surname/firstname change diverges from the warehouse user account names

[kazlauskis]

By changing a user's surname on the iRecord website this is not synced back to the warehouse. If the user is then making a record with a recording form that doesn't have a Recorder name field on it, then the record will be under an old user's surname. This shows up when using the iRecord App, where users with their names changed get the app records under the original-old names. See this forum post.

This might be linked to Indicia-Team/warehouse#128

An example:

• This is how it is edited on the website

  

• How it appears on the general edit form

  

• The same account on the warehouse with the old name

  

[kitenetter]

There are some wider issues here I think. Years ago I edited my iRecord name from "Martin Harvey" to "Martin C. Harvey" but the app still uses "Martin Harvey" presumably for the reasons Karolis gives above. One of the consequences of the name edit seems to be that it is not possible to bulk verify records attached to "Martin C. Harvey".

We've also had a number of instances of people querying why a name edit hasn't fed through to the league tables that appear in various places.

It is difficult though. If a user gets married and changes their name, they might in some cases wish all their records to be updated to the 'new' name, and in other cases would prefer the old records to stay linked to the name that was used at the time. If we do make name edits propagate through the system we will no doubt end up making changes that some users don't want to see, and also it may be added complication for verifiers.

Would a propagated name change result in records being seen as edited, thus exposing them for re-verification?

One answer might be to give users the choice: upon editing their name they could be asked whether they want the edit to propagate to their existing records. But that's adding complexity.

Are there any other approaches we could consider?

[JimBacon]

This is further complicated because there is not a single way of recording names. It varies between surveys.

Some surveys have sample attributes for name, some use the sample.recorder_names field and some are just linked to a person record which contains a name. Some do more than one of these things. Those which store the name as part of the sample have a record of the name used at time of recording which could be fixed. Those without can only access the persons current name (which I would expect to update if changed in iRecord).

[kazlauskis]

Maybe, for a start, the core drupal account name+surname could be synced to the warehouse ones. This would at least get those records without custom recorder attribute showing correct names.

[johnvanbreda]

@JimBacon I think we can ignore the custom attribute fields that capture a recorder's name at the time the record was input for the purposes of this issue, which is purely about syncing the Drupal user account and the warehouse person details, which is important since the name details on the warehouse are used in various reports such as user leagues. The custom attribute values can remain a snapshot of the name provided at the time the record was created so wouldn't need to be updated.

So, I am fairly clear that the requirement here is to update the warehouse person record's first name and surname fields when a user update's their Drupal profile data for these fields. The issue I have is whether this information should then be synced back into the Drupal profile on any other sites the user logs in to. Here's a contrived example:

1. A user registers on iRecord as Peter Piper. This creates a warehouse user account ID 123, with a person record for first name=Peter and surname=Piper.
2. They then edit their user profile and changed their first name to Peter P. to include their middle initial. So, this issue proposes that the warehouse person record is updated to reflect this which is fine so far.
3. They then register on UKBMS as P.P. Piper. At this point, does the warehouse person record get updated? The answer to this is probably yes.
4. Do we now update their iRecord profile for them next time they log in, so their first name is modified to P.P. to match UKBMS and the one stored on the warehouse?

I think if the answer to 4 is yes then it gets quite complicated, with 2 way sync and potential clashes. It would be further complicated in some cases where partners share an email address, one logging in to iRecord and the other to UKBMS. Not an ideal setup but I'm aware it has happened.

Given the complexity of taking this further, is there any objection to this requirement being limited to the following: When a user first registers on any website and their user already exists on the warehouse, or when a Drupal profile is subsequently updated and their name details are altered, then the person details stored on the warehouse are updated to match those provided in the Drupal profile.

[BirenRathod]

I think changing name & matching according to Drupal's profile way to go ahead. If possible you can add the message like "you have been registered previously with [existing name], would you like to change to this [new name]" .

[JimBacon]

Couple of thoughts.

1. I don't think changing the person name currently triggers an update on the cache_samples_nonfunctional table. It will be needed for reports to reflect the new name.
2. When updating the cache, a name in a sample attribute is preferred to a warehouse person name so, where a survey stores the name at time of recording, this will continue to show.

[kitenetter]

I'm going to close this old issue - the question of how we handle names still comes up, but has been more recently addressed in #869