¿Cómo permitir descargar imágenes junto con otros datos de usuario (csv) desde la sección de actividad?

Nosotros (unos pocos voluntarios de la comunidad de Krita) hemos configurado un servidor de Discourse para la comunidad de Krita artist. La configuración es muy similar a la de Blenderartists.org.

Al ser un foro relacionado con software de arte, las discusiones contendrán muchas imágenes. Desde la perspectiva del RGPD, Discourse ofrece una forma de descargar los datos del usuario desde la sección de actividades en el perfil. Sin embargo, he notado que la descarga no incluye las imágenes que el usuario ha publicado en el foro. Me gustaría preguntar si existe alguna manera de incluir las imágenes publicadas por los usuarios en los archivos ZIP descargados. ¿Existe algún plugin que proporcione esta funcionalidad?

Gracias.

It’s not currently available in core nor in any plugins I know of unfortunately.

We should arguably include any images the user uploaded in the data download.

Technically they still have the URLs so they could just parse and pull them. I worry about image heavy users ending up costing lots and lots of server time when they click the button.

Sorry if this seems a silly idea, will a predetermined time frame given to user to come back for the zip file help. During this period the zip creation can be done when there is less server activity.

I am uneasy allowing a random end user with lots of activity the ability to trigger downloading half a gig of data from s3 for re-packaging.

Much prefer to provide them with a link to a script they can run against the export to download images.

I’m not an expert, but I believe that from a GDPR perspective this is not an acceptable solution. @RGJ do you know?

closing this for 6 days so our lawyer has a chance to read this before this gets derailed into a GDPR drama.

you still have the ability to run the script as an admin for the user and email them images if you want.

¿Hay alguna actualización al respecto? ¿Un script/herramienta para usar o una corrección en el núcleo?

Sé cómo hacerlo manualmente, pero soy más avanzado que otros.

Solo para ampliar eso,

![Screenshot_20200422-132435|281x500](upload://dYJTG1LPTCy8fp52SrPh7a1p89j.png)

provino de un user-archive.csv generado hoy. Ese no es un enlace muy amigable para el usuario.

Ayer realicé por primera vez desde mayo una exportación de publicaciones y veo que se le ha prestado algo de atención, aunque con una elección extraña (para mí):

Pero no hay imágenes en ella y aún veo fragmentos (probados con meta) con URLs muy difíciles de usar, como: ![screen-20200627-125657|385x397](upload://nsHMu7zGRvQ1Y9WuIPrrygpWbC6.png) (nota que esa es una imagen que subí después de la actualización de mayo).

Incluir imágenes en el archivo sería un dolor de cabeza. Lo que podríamos incluir fácilmente es la publicación cooked junto con la raw, de modo que las imágenes y todo lo demás que se transforma se asocien de una manera estándar que pueda analizarse fácilmente.

¿Cómo funciona eso con la opción de URLs prefirmadas introducida recientemente? Confieso que no sé mucho sobre cómo se implementa, pero mi temor es que las URLs no sean estables.

(Con lo cual me refiero a: Secure Uploads )

Si colocamos la publicación procesada como sugiere @Falco, las URLs serán /secure-media-uploads/blah. La URL firmada solo se genera cuando se solicita la subida desde la URL de medios seguros, por lo que no deberías tener problemas.

¿Cuál es el estado de esta solicitud de función (si es que lo es)?

Vamos a dividir esto en varias preguntas más pequeñas:

  1. ¿Existe actualmente alguna forma para que un usuario obtenga una copia de todas las imágenes incluidas en sus publicaciones?
  2. ¿Hay alguna forma de obtener (o recrear) estas publicaciones en su formato procesado, al menos en la medida en que las imágenes subidas estén en el lugar que les corresponde?

Si bien no estoy seguro de poder escribir un script completo, intenté averiguar cómo reconstruir la URL de las imágenes basándome en la información que se incluye actualmente en user_archive.csv, pero no veo cómo sería posible, dado que parece no haber correlación entre el enlace de la imagen proporcionado en el archivo csv y la URL pública de esa imagen en el foro.

Por ejemplo, tengo ![image|499x436](upload://tIh81VxrDGPzUkxhikPmbgFGbO6.png) en mi archivo csv y la URL de esa imagen en el foro es https://forum.example.com/uploads/default/original/2X/d/d04053334ed6a40db3cdcf83c1c6eb139079494e.png, por lo que incluso si el script usara tIh81VxrDGPzUkxhikPmbgFGbO6.png en combinación con alguna URL base, no podría recuperar la imagen, ¿verdad? ¿O una imagen tiene de alguna manera múltiples identidades?

¡Gracias por revivir este tema! No lo había visto antes. :smiley:

Al revisarlo, comparto tanto la aparente creencia de @codinghorror de que las imágenes deberían ser accesibles de esa manera, como la preocupación de @sam sobre las demandas que esto impondría a los recursos del lado del servidor, particularmente en casos donde el usuario no está interesado en las imágenes en sí mismas.

No puedo hablar sobre la viabilidad, pero desde un punto de vista estrictamente de UX, siento que sería mejor tener un botón separado de descargar imágenes presentado junto a la opción de descarga existente, o una ventana emergente preguntando si deseas que se incluyan las imágenes al usar la opción de descarga existente.

Por el momento no, tendrías que ir al foro. Apoyo el cambio de @Falco como una mejora rápida provisional para la situación.

¿Quieres decir que tendrías que obtener las imágenes navegando a las publicaciones reales? Pero eso no te daría imágenes de publicaciones que han sido eliminadas u ocultas para ti, ¿verdad?

Con respecto a la

Cuando @sam y @Falco están de acuerdo en algo, ¿significa que se ha agregado a alguna línea de producción?

A veces sí… a veces no. Esto aún no se ha programado.

Priorizaré agregar “cocinado” a la exportación, es un cambio fácil, debería ocurrir en algún momento del próximo mes.