A partir de Discourse 2.5.0.beta3, los administradores del sitio pueden fusionar usuarios que no son personal sin necesidad de acceder a la consola. Por razones de seguridad, los usuarios del personal aún deberán fusionarse mediante la consola.
Visite la página de administración de usuarios y seleccione «Fusionar» en la parte inferior de la página.
Ingrese el nombre de usuario en el que desea fusionar la cuenta y haga clic en «Transferir y eliminar @nombredeusuario» para iniciar el proceso de fusión.
(notas: asegúrese de que no haya espacios antes ni después de la coma)
Esto fusiona los datos del usuario de origen en el usuario de destino antes de eliminar el usuario de origen. El contenido de 45 tablas se fusiona, por lo que, dependiendo de la cantidad de datos asociados al usuario de origen, este proceso puede tardar un tiempo.
Los autores de complementos pueden integrarse en el proceso de fusión manejando el evento :merging_users. Ya lo he implementado para el complemento de encuestas, que fusiona los votos de los dos usuarios fusionados.
Problemas conocidos:
Los enlaces entrantes que aún hacen referencia al usuario de origen (por ejemplo, https://talk.example.com/t/some-topic/17/3?u=source_username) no se asociarán con el usuario de destino.
Un usuario solo puede tener un usuario sombra (de la función permitir publicación anónima). Por lo tanto, si ambos usuarios fusionados tenían un usuario sombra, el que pertenecía al usuario de origen se perderá… bueno, aún estará allí, pero ya no estará asociado a ningún usuario existente.
Thank you for this feature, it is huge for my use case! I am currently porting our forums from phpBB to Discourse and wanted to use SSO via a custom provider. Since we could not easily link SSO accounts to our legacy accounts and works flawlessly!
If anyone else is going to use this make a note of this:
rake users:merge['mattbr_sso', 'mattbr_legacy'] will not work as expected, the SSO will not go through. However:
rake users:merge['mattbr_legacy', 'mattbr_sso'] works perfectly and allows you to migrate all the posts into the SSO account.
When using the ‘User Event’-webhook created or login (or approved?) the duplicates will be existent on a connected site as well and one might want an automatism to clean them up as well, if the connected site supports that.
I haven’t used webhooks yet but plan to. On my connected site (using Discourse as SSO provider) the users are only created at first login for now. + I had duplicate users in my old forum before migrating to Discourse which I was looking forward to consolidate once this feature becomes available.
Yes, it will. I should be able to make this happen for the 2.0 release.
You will have to update the user’s created_at manually if you want to set it to the oldest post. The merge process uses the created_at from either the source or target user – whatever date is earlier.
Any chance the staff action log could better show what happens to users when they are merged? Here’s how it looks now - just shows that system has deleted the user but no context. The details only show some info about the user that got deleted as a result of the merge.
How about adding a staff note along the lines of “Username with email was merged to this account, date”
This is what I did when I was merging accounts manually. Probably more work than a staff action log entry, but might be useful information at some point later.
Is there an easy way to change which email address is primary?
Here’s my use case:
imported user with email user@defunctdomain.com emails from user@fancynewemail.com which creates a staged user. After a few PMs with the staged user, I merge the accounts, but the primary address is still the old one. And from the web interface I can’t change the email in his profile because it’s already taken. By him.
Perhaps this is a bug in the multiple email address model and not a complaint for here.
The simple solution, which took me much to long to come up with, is to delete the old address.
Is there something easier that I should do?
I need to keep the old username with the new email. The staged user is the real problem. Perhaps I should just delete the staged user, but then I don’t have an easy way to reply to them to tell them what happened.
It’s pretty cumbersome to merge[‘newname_newemail’,'oldname_bogusemail"] and then have to do something like