As a user with an institutional account, I want to transition to another account when I relocate.

[kcondon]

A user works for institution A and creates an institutional Dataverse account while there. They later move to institution B and want to keep their account and what privileges are still relevant.

Currently this requires a Support ticket and the intervention of a super user to first convert to a local account with the new email address, then the user logs in a converts their account following the workflow prompts in the UI.

See http://guides.dataverse.org/en/4.8.4/installation/shibboleth.html#converting-accounts
for the process.

There are 3 issues to consider:

1. Provide a simple push button transfer workflow to both the end user and to a super user.
2. Provide messaging to explain not to log in using their new institutional account but instead transfer the existing one since that creates a second account.
3. Provide a way to merge accounts in the case that a second account had been created and roles were assigned, content added.

Currently if the new institutional account already exists, their account needs to first be deleted, after all roles are removed, then the original account needs to be converted to local, then the user logs in and converts it to the new shib account.

[pdurbin]

Nice discussion on this issue during sprint planning yesterday. One thing I meant to say is that Shibboleth ("institutional account) users will see (for example) "Leaving your institution? Please contact Harvard Dataverse Support for assistance." It looks like this:

While this is better than nothing and at least sets expectations that they're sort of locked in to their current login method, perhaps we could replace this with a "Convert to Username/Email Account" button and workflow.

#3704 is related in the sense that it's easy to get confused about which account type you have.

[kcondon]

I think the idea @pdurbin mentions above would be a good incremental change.

Posted this on Slack but might be useful here:
hey sorry for the lack of clarity on my user authentication ticket in sprint planning yesterday. In essence, I think I was saying to allow the end user to directly switch institutional logins. One simple way I can imagine is to allow them to log in to their new institution while logged in to their old one and that would automatically convert. It could even be a "I'm moving" option on username or account info page. If for some reason their new shib account is not yet active, provide a temp local login move with instructions to access move option again once ready, using appropriate email. Last, way future or maybe not at all but why cannot auth method and account be separate -have one account that supports multiple auth methods?
anyway, that's all, happy Thursday!
oh yeah, and in the case they have already lost their current institutional log in and so need to be revetted, provide same move capability to super admins from manage user page -click on a username in table, opens to a useraccount-type view or same exact view with move options.

[kcondon]

@pdurbin
I know the incremental approach above would require little code and is a good first step.

To help with the next step, I was thinking more about direct conversion I am not sure where the complexity lies -there are 2 tables, the account types are exactly the same, barring the default info, which is always overwritten when logging in via shib, I think the email and eppn are the only unique bits and those could be adjusted prior to logging in (eppn would be blank because we don't know it yet) and perms indexing would need to happen for group membership changes. Plus, we already have the concept of moving from one account (builtin) to a new shib account so the idea of adjusting an account to be a shib account is already there, except the starting point would be another shib account. So, before executing the log in to the new account, switch email, clear eppn, and treat it as an already approved builtin conversion?

Anyway, would love to hear at a high level the potential steps and how it could work.

[djbrooke]

I'm going to close this with the desired solution being to create an account at the new institution, and then, using the new merge functionality (#5514), to merge that old account into the new.

[pdurbin]

@djbrooke I still like my "Convert to Username/Email Account" button idea above because it's self-service. No need to email support. But with 881 open issues I certainly appreciate a little housekeeping here in the issue tracker. 😄