Do not allow users to delete last/only/main identity

[castaway]

Describe the bug If the users main identity is deleted, Compose (and no doubt other things) does not work (no default "from")

To Reproduce Steps to reproduce the behavior:

1. Go to 'Identities'
2. Click on the main identity
3. Select Delete
4. Attempt to Compose an email - compose window does not appear as there is no default "from" address (linked to identities)

Expected behavior Identities page to refuse to remove the last/main identity, and compose to always create a new draft

Desktop (please complete the following information):

• OS: All
• Browser all
• Version n/a

Additional context See also #771 (not sure how this one happens)

[castaway]

This isn't possible in the usual scheme of things, the main identity doesn't have a "delete" button at the top of the identities page, and isnt listed in "other identities" at the bottom.

However this came about with a user who's main identity had already vanished (somehow!), and was recreated by visiting the folder prefs in rmm6 and hitting "save". OR they manually recreated it in Runbox7 identities, so it wouldnt be the "inbox" prefs / main identity, just any old plain one.

This new inbox preferences identity was then (presumably) migrated on login to runbox7. At that point they had only one identity, and it wasnt set as default (why not!?). After they set it to default, it showed up in "Other Identities", at which point it was deletable

[castaway]

Summary of current state

Initially, the "main" Identity (aka one with type='main') is created using the details given by the user when they initially create their runbox account (first, last name, chosen runbox login email address).

Users may then create more identities (send-from addresses), or aliases (send-to addresses). Each created alias adds a related identity (so every send-to address can also be sent-from).

By default, the compose form lists all of the identities the user has, defaulting to the 'main' one, followed by their alias-identities, then everything else.

Currently, to change which Identity is listed first on the compose form (for a new email), the identities page allows the user to change which identity is tagged type='main', and moves the previously tagged 'main' identity to be either an 'alias' (if it was one), or an 'external_email' tag.

Once this swap has been made the user is able to delete the identity that was created to reflect their initial runbox account details.

Discussion results

• We should not allow the user to delete their initial/main/"username" profile
  • We should highlight this in some way on the identities screen
  • We allow editing of everything in it other than the email address
• Changing the compose default should be possible without enabling the above
• Tidy up the code (we define a profile object/interface in about 5 different ways)
• This ensures that the user can never remove the last identity (as it'll be the undeletable / initially created, username identity)

[castaway]

Query while poking code: Should changing the main account First name / Last name (in account personal details) update the username profile (and vice versa?)

[gtandersen]

Query while poking code: Should changing the main account First name / Last name (in account personal details) update the username profile (and vice versa?)

I think they should be kept separate since a user may well decide to use a different (version of their) name in an identity than their full/given name (which we require them to keep up-to-date as per our ToS).

[castaway]

Query while poking code: Should changing the main account First name / Last name (in account personal details) update the username profile (and vice versa?)

I think they should be kept separate since a user may well decide to use a different (version of their) name in an identity than their full/given name (which we require them to keep up-to-date as per our ToS).

If they want to do that they could create a separate identity ?

[gtandersen]

Query while poking code: Should changing the main account First name / Last name (in account personal details) update the username profile (and vice versa?)

I think they should be kept separate since a user may well decide to use a different (version of their) name in an identity than their full/given name (which we require them to keep up-to-date as per our ToS).

If they want to do that they could create a separate identity ?

Yes, but they might not be aware of the connection unless we make it very clear in the UI. Some customers are very sensitive regarding identities and their privacy.

What do @runboxdave and @LizTaraldsen think?

[gtandersen]

Query while poking code: Should changing the main account First name / Last name (in account personal details) update the username profile (and vice versa?)

I think they should be kept separate since a user may well decide to use a different (version of their) name in an identity than their full/given name (which we require them to keep up-to-date as per our ToS).

If they want to do that they could create a separate identity ?

Yes, but they might not be aware of the connection unless we make it very clear in the UI. Some customers are very sensitive regarding identities and their privacy.

What do @runboxdave and @LizTaraldsen think?

Confirmed that they should be kept separate on 2024-03-05.

[runboxdave]

I think the discussion here might be confusing because of terminology. In the first bullet point is says "We should not allow the user to delete their initial/main/"username" profile" however, this isn't relevant to this issue because you can't delete the Default Identity anyway.

There is nothing special about the username of an account in terms of identities unless we make it so and there is no evidence to suggest users want it to be available at all times (in fact the opposite is true for some users) or that it should be automatically updated if the account details are updated (which would be a privacy issue for many).

The issue was that in specific circumstances no identity was available and so compose didn't work. Other than through technical bugs if the "Default identity" (whatever it is) can't be deleted then this situation will not occur.

One question does remain though. Can you delete an alias that is part of a default identity? I could see how that might cause an issue.