Every time I attempt to change ownership of an existing PM to an email address not in our system, I get an error rather than a new staged user being created. As I enter the email address, the autocomplete dropdown with the envelope icon option does appear and I do select just as I would with a creating a staged user from a new PM, but in the Change Ownership popup it appears as if this functionality does not work for some reason.
It’s not possible to change ownership to an email address. You need to change ownership to an actual user.
OK, so the issue is not creating a staged user prior to ownership change, it’s doing an ownership change with a staged user at all.
Is this a technical limitation or a design decision about how staged users should function with regard to content ownership? If a staged user can properly own a PM that they initiated themselves via email, then they shouldn’t they be able to own other messages created via other means (if all messages are treated equally)? I suppose the ownership change procedures might not support the staged user case, but if the relative effort was not too high, I would vote for this to become supported.
For context, the use case with our organization is a help desk group with messages submitted to it that are either:
- Emails forwarded through a non-standard/non-parseable forward format (i.e. an email notification forwarded from a partner’s separate ticketing system), or
- Emails that come from non-email-based origins (i.e. a tweet or facebook message or typeform notification email)
Being able to change ownership to a staged user (especially a newly staged user) would allow much quicker and simpler fixing of the associated contact (so that we can then immediately begin conversing with them), as well as aligning the functionality of the dropdown in Change Ownership with the dropdown in the PM composer (the autocomplete suggestion with the envelope icon).
Unless I’m missing something, right now the only workaround is to copy and paste the body into the bottom of a new PM sent to their email and then to archive/delete the original forwarded message thread, is that correct?
1 « J'aime »
Y a-t-il eu de nouvelles informations à ce sujet ?
De temps en temps, nous avons une situation où nous devons créer un nouvel utilisateur temporaire, puis lui attribuer la propriété d’un sujet créé en son nom.
Existe-t-il un moyen simple et rapide d’y parvenir ?
La meilleure façon de créer un utilisateur fictif est de commencer par un PM adressé à l’adresse e-mail de l’utilisateur fictif. Ensuite, une fois que l’utilisateur fictif a été créé, vous pouvez faire ce que vous avez à faire avec lui.
Sauf pour lui assigner un message. À moins que je ne fasse quelque chose de mal, je ne semble pas pouvoir le faire avec un utilisateur mis en scène.
Ah, oui. Il n’est pas possible de transférer la propriété d’une publication à un utilisateur mis en attente. Désolé pour la confusion. Les utilisateurs mis en attente ont des capacités très limitées car ce ne sont pas des « utilisateurs réels »… jusqu’à ce qu’ils se connectent.
Pouvez-vous m’en dire plus sur votre cas d’utilisation ?
Occasionnellement, nous devons créer un ticket de service pour le compte d’un de nos clients. La plupart de nos clients de service et de support n’existent que dans notre Discourse en tant qu’utilisateurs mis en scène.
Ce serait la voie la plus simple pour l’un d’entre nous de créer le message, puis de transférer la propriété de ce sujet au client en question.
S’il existe un autre moyen de le faire qui n’implique pas d’essayer de créer des sujets via l’API que je peux transmettre à notre équipe de support, je serais heureux de le faire.
J’ai juste besoin de pouvoir écrire un document interne avec les étapes et elles ne peuvent pas inclure quelque chose comme : « Connectez-vous en SSH au serveur et… »
1 « J'aime »
C’est un cas intéressant. Peut-être que les utilisateurs fictifs doivent être traités comme de vrais utilisateurs, pour des cas comme ceux-ci.
1 « J'aime »
Je ne suis pas sûr de ce que vous suggérez ici.
Quelque chose que je peux faire, ou une mise à niveau de fonctionnalité ?
Désolé pour cela ! L’autocorrection de mon téléphone me trahit régulièrement ! 
Je l’ai corrigé.
J’ai transmis la demande de fonctionnalité à l’équipe d’expérience du personnel, mais malheureusement, je ne suis pas sûr qu’elle se concrétise un jour car cela impliquerait une refonte majeure du système d’utilisateurs mis en scène.
Avez-vous envisagé de « désenregister » ces utilisateurs ? Actuellement, cela peut être fait en ligne de commande, ce que je sais que vous ne recherchez pas.
cd /var/discourse
./launcher enter app
rails c
User.find_by_email("itsmedebryc@yahoo.com").update(staged: false)
Peut-être qu’un bouton pour désenregister via la page d’administration des utilisateurs est la fonctionnalité que nous recherchons ici.
Une autre idée qui me vient à l’esprit… le ticket de service doit-il absolument être initié par le client ? Pourquoi ne pas simplement créer le ticket (MP) vous-même depuis votre boîte de réception de groupe et inclure leur adresse e-mail ? Vous êtes alors l’auteur et ils sont impliqués.
Je ne veux pas les désactiver car je ne veux pas qu’ils soient exposés à des e-mails récapitulatifs qu’ils pourraient ne pas vouloir recevoir, à moins qu’ils ne créent leur propre compte sur notre forum.
Nous n’utilisons pas les MP, nous utilisons des sujets de catégorie. S’il existe un moyen de les ajouter au sujet, cela me conviendrait.
Ce sujet a été automatiquement fermé 30 jours après la dernière réponse. De nouvelles réponses ne sont plus autorisées.