Cada vez que intento cambiar la propiedad de un PM existente a una dirección de correo electrónico que no está en nuestro sistema, obtengo un error en lugar de que se cree un nuevo usuario en espera. A medida que ingreso la dirección de correo electrónico, aparece el menú desplegable de autocompletado con la opción del icono de sobre y lo selecciono tal como lo haría al crear un usuario en espera desde un nuevo PM, pero en la ventana emergente de Cambio de Propiedad parece que esta funcionalidad no funciona por alguna razón.
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?
¿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…”
Ese es un caso interesante. Quizás los usuarios simulados necesiten ser tratados como usuarios reales, para casos como estos.
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í.