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 me gusta
¿Ha habido alguna nueva perspectiva sobre esto?
De vez en cuando, tenemos una situación en la que necesitamos crear un nuevo usuario provisional, luego asignarlo como propietario de un tema creado en su nombre.
¿Hay alguna forma rápida y sencilla de hacer que esto suceda?
La mejor manera de crear un usuario provisional es iniciar un PM dirigido a la dirección de correo electrónico del usuario provisional. Luego, una vez que se haya creado el usuario provisional, puede hacer lo que necesite con él.
Excepto asignarle una publicación. A menos que esté haciendo algo mal, no parece que pueda hacer eso con un usuario preparado.
Ah, sí. No es posible cambiar la propiedad de una publicación a un usuario provisional. Disculpas por la confusión. Los usuarios provisionales tienen capacidades muy limitadas porque no son “usuarios reales” hasta que inician sesión.
¿Puedes contarme más sobre tu caso de uso?
Ocasionalmente necesitamos crear un ticket de servicio en nombre de uno de nuestros clientes. La mayoría de nuestros clientes de servicio y soporte solo existen en nuestro Discourse como usuarios preconfigurados.
Sería el camino de menor resistencia que uno de nosotros cree la publicación y luego transfiera la propiedad de ese tema al cliente en cuestión.
Si hay otra forma de hacerlo que no implique intentar crear temas a través de la API que pueda transmitir a nuestro equipo de soporte, estaré encantado de hacerlo.
Solo necesito poder escribir un documento interno con los pasos y estos no pueden incluir nada como “Conéctate por SSH al servidor y…”
1 me gusta
Ese es un caso interesante. Quizás los usuarios simulados necesiten ser tratados como usuarios reales, para casos como estos.
1 me gusta
No estoy seguro de lo que sugieres aquí. ¿Algo que pueda hacer o una mejora de función?
¡Disculpa por eso! ¡El autocompletado de mi teléfono me traiciona regularmente! 
Lo arreglé.
He transmitido la solicitud de funciones al equipo de experiencia del personal, pero desafortunadamente no estoy seguro de que alguna vez suceda porque implicaría una gran revisión del sistema de usuarios en etapa.
¿Has considerado “desestafar” a estos usuarios? Actualmente, eso se puede hacer desde la línea de comandos, lo que sé que no es lo que estás buscando.
cd /var/discourse
./launcher enter app
rails c
User.find_by_email("itsmedebryc@yahoo.com").update(staged: false)
Quizás un botón para desestafar a través de la página de administración de usuarios sea la solicitud de funciones que estamos buscando aquí.
Otra idea que se me ocurre… ¿la solicitud de servicio tiene que ser iniciada por el cliente? ¿Por qué no iniciar tú mismo la solicitud (MP) desde tu bandeja de entrada grupal e incluir su dirección de correo electrónico? Entonces tú eres el autor y ellos están involucrados.
No quiero desactivarlos porque no quiero que estén expuestos a correos electrónicos de resumen que quizás no les interese recibir, a menos que creen su propia cuenta en nuestro foro.
No usamos Mensajes Privados (MP), usamos temas de categoría. Si hay una manera de agregarlos al tema, estaría bien para mí.
Este tema se cerró automáticamente 30 días después de la última respuesta. Ya no se permiten nuevas respuestas.