Hello friends,
what are you thinking about some extra tab at the admin interface to keep control over the current disk usage, files sizes, click rates, filtering them after extension and searching for specific terms?
I wish, I could get more control over all attachments.
Best
That’s something I definitely want done. Not sure when though.
Sounds useful!
There is a bunch of product questions around how this could/should work in my mind. It looks like a problem that has been already figured out or solved in other forum software, but I wonder how will this be framed / built around Discourse’s philosophy.
I am also wondering more about the manifestations of providing uploads settings, e.g.: if you chose to introduce extension configuration, the composer needs to cater for this when users are selecting/uploading attachments, and so on. Also, whether this should be in core, or as a plugin.
On the bright side, if we ignore all questions / assumptions / product / design considerations, it doesn’t look like it is technically tricky, I made a one hour spike here (this is very immature implementation though 
).
You can definitely extend this with a bunch of useful features: settings, search / filtering, sorting, etc (and some other considerations like supporting pagination, …)
If youbtalking about admin tools. You can considure usong plugin data explorer whic allows admins to query database. When I hunting free space I am querying db there is table uploads whic gives you size location and other useful things. Also one good thing is that deleating rows from uploads also dealeting files. Becouse ther is sidekiq job pruge oprhan uploads.
I am totally open to adding something here, but I feel a top level tab is a bit too much .
Conceptually this feels like a “report” to me with a drilldown vs a section for uploading things.
I would like to see this link to the new report
When I think about this problem I think the main use case is around admins trying to get a handle on the … upload problem…
Why do I have so many uploads?
Which users have the most/largest uploads ?
What are the 100 biggest uploads on my forum?
How many things were uploaded in the last month? That way I can keep track of trends.
@codinghorror / @j.jaffeux what are your thoughts here?
Yes I agree it could be a report, we might have to start working on the filtering logic I talked with you months ago. But other than that it should be good.
Great line of questioning @sam !
I think perhaps I lack some context on what is the admin’s job / use case for the upload problem, but it appears to be (if there is any research or perhaps admin opinions to confirm that, it would be great!) that it can be framed as: I am an Admin, I want to gain understanding of my instance’s uploads usage.
I wonder if there are any after actions when the job / use case is satisfied. For example, if the admin notices a problem or a trend, will the admin/site_settings/category/files is the place they can optimise their file uploading strategy?
Also, I agree that the Uploads section is heavy as a top level tab for this use case.
Any news about this topic?
Im looking for a option to look through the uploaded files.
I guess, sorting and listing files isn’t as much as important for Discourse as for us. 
Similar issue:
Aquí tienes algunas consultas de Data Explorer para obtener detalles sobre las cargas de publicaciones. Es posible que algo similar pueda agregarse a la sección de informes de administración para sitios que no tienen instalado el complemento Data Explorer. Avísame si estos datos no son lo que buscas.
Devuelve el usuario, la cantidad de cargas y el total de cargas en KB redondeado a dos decimales. El JOIN con la tabla users evita que se devuelvan datos de usuarios eliminados. Los resultados se ordenan por el tamaño total de las cargas en orden descendente.
WITH uploads_with_optimized AS (
SELECT
ul.user_id,
ROUND((SUM(COALESCE(oi.filesize, 0)) + SUM(ul.filesize)) / 1000.0, 2) AS total_kb
FROM post_uploads pul
JOIN uploads ul
ON ul.id = pul.upload_id
LEFT JOIN optimized_images oi
ON ul.id = oi.upload_id
GROUP BY ul.user_id
)
SELECT
uwo.user_id,
COUNT(uploads.user_id) AS upload_count,
total_kb
FROM uploads_with_optimized uwo
JOIN uploads
ON uploads.user_id = uwo.user_id
GROUP BY uploads.user_id, uwo.user_id, total_kb
ORDER BY total_kb DESC
LIMIT 50
SELECT
ul.user_id,
COUNT(ul.user_id) AS upload_count,
ROUND(SUM(ul.filesize) / 1000.0, 2) AS total_kb
FROM post_uploads pul
JOIN uploads ul
ON ul.id = pul.upload_id
GROUP BY ul.user_id
ORDER BY total_kb DESC
LIMIT 50
Devuelve el usuario, la publicación con la carga y el tamaño del archivo de la carga en KB. Los resultados se ordenan por el tamaño de la carga en orden descendente.
SELECT
ul.user_id,
pul.post_id,
ROUND((SUM(oi.filesize) + ul.filesize) / 1000.0, 2) AS total_kb
FROM post_uploads pul
JOIN uploads ul
ON ul.id = pul.upload_id
JOIN optimized_images oi
ON ul.id = oi.upload_id
GROUP BY oi.upload_id, ul.user_id, pul.post_id, ul.filesize
ORDER BY total_kb DESC
LIMIT 100
SELECT
ul.user_id,
pul.post_id,
ROUND(ul.filesize / 1000.0, 2) AS total_kb
FROM post_uploads pul
JOIN uploads ul
ON ul.id = pul.upload_id
ORDER BY total_kb DESC
LIMIT 100
La consulta requiere que proporciones un parámetro :end_date. La fecha debe estar en formato ‘aaaa-mm-dd’. Por ejemplo, ‘2020-01-08’. Devuelve resultados para el período de 30 días que finaliza con la end_date. Devuelve el día, la cantidad de cargas y el total de cargas en KB para ese día, para todos los días del período que tengan cargas de publicaciones. Los resultados se ordenan por día.
--[params]
-- date :end_date
SELECT
ul.created_at::date AS day,
COUNT(1) AS upload_count,
ROUND((SUM(COALESCE(oi.filesize, 0)) + SUM(ul.filesize)) / 1000.0, 2) AS total_kb
FROM post_uploads pul
JOIN uploads ul
ON ul.id = pul.upload_id
LEFT JOIN optimized_images oi
ON ul.id = oi.upload_id
WHERE ul.created_at::date BETWEEN :end_date::date - INTERVAL '30 days' AND :end_date
GROUP BY ul.created_at::date
ORDER BY ul.created_at::date DESC
--[params]
-- date :end_date
SELECT
ul.created_at::date AS day,
COUNT(1) AS upload_count,
ROUND(SUM(ul.filesize) / 1000.0, 2) AS daily_upload_kb
FROM post_uploads pul
JOIN uploads ul
ON ul.id = pul.upload_id
WHERE ul.created_at::date BETWEEN :end_date::date - INTERVAL '30 days' AND :end_date
GROUP BY ul.created_at::date
ORDER BY ul.created_at::date DESC
Soy un nuevo miembro de la comunidad (meta) y recientemente asumí las tareas de administración de otra comunidad que utiliza Discourse (y que está alojada por Discourse). En el panel de control, acabo de ver un “salto” en el espacio que utilizan las subidas (de aproximadamente 0,7 GB a 1,2 GB). Parece que el Explorador de datos solo está disponible para planes de Negocios o superiores… ¿Habrá alguna otra forma de averiguar qué archivos recientes están utilizando los 0,5 GB adicionales?
Esto es completamente culpa mía.
Antes tuvimos un error importante donde no estábamos calculando correctamente el tamaño de todas las cargas.
Cuando un usuario carga una imagen, a menudo la redimensionamos de 3 a 4 veces para varias resoluciones y optimizaciones. Estas imágenes optimizadas se almacenan en la nube y aún ocupan espacio de almacenamiento.
Para ver las imágenes reales, puedes:
SELECT * FROM optimized_images
@simon, ¿quizás podrías actualizar lo anterior para tener en cuenta optimized_images?
Ah, eso tiene mucho sentido. De hecho, me pregunté brevemente si podría ser eso… justo después de escribir este mensaje aquí 
Hmmm, quizás valga la pena añadir una breve frase al respecto en el medidor de almacenamiento del panel de control, para que la gente no piense que alguien está desviando su espacio de almacenamiento con datos desconocidos
Y si alguna vez creas un “Inspector de subidas” que no requiera los complementos del plan Business, ¡lo agradeceríamos mucho!
¡Saludos!
Finalmente, no entendí cómo puedo ver la lista de las subidas de los miembros en diferentes temas y publicaciones. ¡¡¿¿??
Me gustaría explorar el directorio de archivos subidos. Mi caso de uso en particular es investigar los detalles de este enlace roto:
Cualquier apoyo interpretado de administración para hacerlo sería de gran ayuda. ¿O he pasado por alto algo? Con mis mejores deseos, R
Otra solución alternativa es:\n\n- crear y descargar una copia de seguridad del sitio con "incluir subidas"\n- navegar a ese archivo y descomprimirlo, por ejemplo desde la línea de comandos: $ tar -xvzf xxxx.tar.gz\n- cambiar al directorio de subidas: $ cd uploads\n- seleccionar entre las secciones original y optimizada y explorar el árbol de archivos resultante\n- ninguno de los nombres de subida está presente, todos los nombres implementan cadenas aleatorias (o codificadas)\n\nUna interfaz gráfica de usuario en el portal de administración proporcionaría una mejor experiencia de usuario. Así que mi voto es para esa funcionalidad. R