Username change without changing history

[RichardTaylor]

There are circumstances where we might want to change a username (effective from a particular point in time) and have the system use the original name for correspondence threads before that date.

eg. Someone changes their name on marriage

eg. Someone changes their name for any other reason

[RichardTaylor]

There has since been another case of a user changing their name where this feature could have been used.

[RichardTaylor]

There's been a case on WhatDoTheyKnow where a user signed up with their first name; and now wants their full name as their user name.

As the user has got a history of requests with correspondence from public bodies asking for their full name when requests were made without it we shouldn't really "change history" by changing the username.

This is just an update to note this is still a feature which would, on a rare occasion, be desirable.

[hsenag]

Doesn't the actual correspondence show how the request was signed at the time, even if the user changes their name later?

[RichardTaylor]

The displayed user-name name is the most prominent name associated with the request; and this can be different from the name actually used to sign off the request.

I think changing the username on past requests would be confusing.

If we allow a user-name to be changed we could end up with requests where the authority has replied to a name no-longer present in the request. ie. they've replied to the username (which the authority sees the request as being "from") rather than who it is signed off by.

We could change the name but add an alert explaining we had done so; but I think it would be best not to change history.

If we did allow a username change without changing history perhaps where a change had occured we'd want a note on old and new requests saying the name has changed.

[hsenag]

OK, so the confusing thing would be that there would be correspondence addressed to and signed off from the old name, but the new name would appear in things like the "From:" bit of outgoing messages?

[RichardTaylor]

My understanding is if we change a username then we change the name displayed at the top right of every outgoing message as well as the name shown at the top of the request thread.

The only place the old name might appear is in the sign-off within the body of outgoing messages.

My top concern about "changing history" in this way is in some cases we might be making it look as if public bodies had made up names to address their responses to.

It's also just bad in my view to silently change history; what if someone had referenced the request in a news article, or other publication and referred to it as a request by "user name" only for us to have changed that name.

Also where there has been correspondence relating to the validity of a name as with the example given above, or names declared obvious pseudonyms etc. I think it would be wrong, and confusing, to "change history".

[RichardTaylor]

A new case where this feature would have been useful has come up today. A councillor who has ceased to be a councillor wants "Cllr" dropped from his username.

[RichardTaylor]

Just a note to say we've had another couple of cases where this might have been useful.

I note we'll need to be careful using it as depending on the reason for a name change people might want a clean break from their old identity so we'll need to make sure we have clear instructions from the user as to if they really want a name change or a new account.

[hsenag]

I'm not too sure about the complexity of this one - at least, no really simple solution jumps out at me. What happens to correspondence threads in progress at the time of the request?

[RichardTaylor]

Just a quick note to say we've had another case on WhatDoTheyKnow where this feature would have been useful.

[henare]

We just had someone ask how they can change their name. They signed up using only their first name for privacy reasons but after making a request were no longer concerned about that so wanted to add their last name.

In this case they probably would have been fine just updating their display name and not the URL name.

[RichardTaylor]

A user of WhatDoTheyKnow just got married and this feature would have been useful to deal with their subsequent request to change their name on WhatDoTheyKnow. We've changed their username for them but this leaves the history a little inconsistent with the new name where the username is shown but the old name in the body of the requests.

[RichardTaylor]

There has been another case on WhatDoTheyKnow today where this feature would have been useful.

[RichardTaylor]

Another case arose today - where someone who has made hundreds of requests on WhatDoTheyKnow under using a single word name, and had many rejected on the grounds of not providing a full name, wanted a second word added to their name. Given the history of rejections just adding the second word to the user name could have made the presentation of existing correspondence misleading / hard to understand. The option to change the name from a point in time would have made the decision on what to do easier.

[RichardTaylor]

Another +1 from today. A user making requests under the name of an "organisation" wanted to change that organisation's name.

We want to encourage organisations to use WhatDoTheyKnow to make requests and from time organisations do change their names so handling such events nicely would be good.

The situation isn't terrible at the moment as the name used at the time of the request will probably still be in the text of the correspondence even if a user name is changed.

[RichardTaylor]

Another +1 for this following a WhatDoTheyKnow user changing their name.

[garethrees]

Maybe name should be added on a per-request basis (InfoRequest#signature?), with User#name being the pre-filled value. That would allow us (or users themselves) to more easily redact the signature, allow user account name changes with less disruption on history, and also allow pro users to use pseudonyms.

Haven't though too much about this, so just noting for when we get to it.

[RichardTaylor]

Adding another +1 for this in light of another request from a WhatDoTheyKnow.com user.

I suspect there's a strong equalities case for this, the lack of this feature is likely to impact women more than men given women tend to change their names on marriage far more than men do. The lack of this feature will also impact those changing their gender more than it will the general population.

[gbp]

So there are two issues here:

1. Preserving historical User#url_name

In the past I have used the friendly_id gem configured with its History module to record pass slugs. See Avoiding 404's When Slugs Change. This works by adding a migration to create a new database table which the gem uses to record generated slugs. To refresh my memory of the gem I have take a look at implementing this and without too much work it seems to be working to a degree.

Would need to consider GDPR/RtE deletion of old slugs.

2. Displaying historical user names on request pages

While we could version the User record as we do with PublicBody, a pick out the correct version's name. I'm not very keen on this as it seems it would be more complex to implement. Also the gem we use hasn't been updated for a long time - we should need to address that by switching to a different gem.

To me it seems better to record the sender somewhere, this could be:

• on the OutgoingMessage records (maybe as OutgoingMessage#from_name to match IncomingMessage#from_name)
• in the params (as from_name) of the outgoing (send/ resend & followup) InfoRequestEvent events for the request.

We should fall back to the User#name if these aren't set.

A rake task to populate the outgoing from_name would be necessary otherwise future name changes wouldn't be obvious for past requests.

When resending an outgoing message, I believe we use the previous stored name and not current user name as this could cause confusion at the authority if both messages were received.

If we record an InfoRequestEvent for on each request when a requester has a name change this will allow us to render a notice explain what has happen inline within the requests correspondence messages.

We also store the User#url_name in some InfoRequestEvent#params_yaml, this will soon be removed with bf3c2b0

[RichardTaylor]

We've had a case today on WhatDoTheyKnow where a user wanted to change their name while having requests in-progress.

This shouldn't cause public bodies a problem, as in life people do change their names, sometimes mid-"conversation", but I can imagine some public bodies might get confused, or raise concerns about the validity of a request if the name change was not explained - given the requirement in FOI law for a request to be associated with the name of the requester for it to be valid.

We could perhaps just advise users about to continue a thread with a name other than the one they previously used that they might want to reference the change in the body of their correspondence.

[garethrees]

Pasting some notes from our in-person shaping session on this.

Overview

We spoke about this in person so won't cover too much of the ground here. The gist is that we want the info request record to be a snapshot in time, so that a rename doesn't affect the request history. We can link to the user's current profile page and make it obvious that since the request was made a rename has happened, and preserve old slugs so that referencing links still work.

OutgoingMessage

• Cache User#name as OutgoingMessage#from_name on message creation.
• Update OutgoingMessage#from to use the cached from_name value.
• Make OutgoingMessage#from_name editable in the admin UI.
• Make OutgoingMessage#from_name redactable¹.
• Make OutgoingMailer resends use the exact contents of the message to be resent, rather than regenerating them.
• Show a warning/notice to remind a user/admin that the name has changed since the last message when following up or resending correspondence.
• Could also include an extra line in the template if following up on an existing thread, but only if we can do it without introducing too much confusion/complexity.
• Make sure the signoff used is correct

InfoRequest

• Add InfoRequest#from_name which delegates to the first OutgoingMessage#from_name.
• Use InfoRequest#from_name rather than @user.name in the request subtitle. This means we’ll always show the name used at the time of requesting, even if we’re linking to an updated user record. We might end up caching the name here later in order to achieve Ability to delete a request but leave an explanation #7414, but for now a method call is fine.
• Make InfoRequest#from_name redactable¹.

User

• Allow users to edit their own name attribute through the UI
• Add a “Previously known as” section which plucks cached names from correspondence sent by the user
• Record previous url_name records
• Show previous url_name records in the admin UI
• Allow PII from previous url_name records to be erased

Misc

• Make sure we’re using the correct name in the UI ([#6154] Make it clearer usernames are published #7600)
• Add From: to the followup form (if it isn’t already)

Footnotes

1. i.e. Any applicable censor rules apply to it. ↩ ↩²

[garethrees]

Don't think this was intended to be closed by just #7702.