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.
关于这个话题有什么新消息吗？
我正在寻找一个可以浏览已上传文件的选项。
我想，对 Discourse 来说，排序和列出文件可能没有对我们那么重要。
类似问题：
这里有一些用于获取帖子上传详情的 Data Explorer 查询。对于未安装 Data Explorer 插件的站点，或许可以将类似功能添加到管理员报告部分。如果这些数据不符合您的需求，请告诉我。
返回用户、其上传数量以及总上传大小（以 KB 为单位，保留两位小数）。与 users 表的连接是为了防止返回已删除用户的数据。结果按总上传大小降序排列。
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
返回用户、包含该上传的帖子以及上传文件的大小（以 KB 为单位）。结果按上传大小降序排列。
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
该查询需要您提供 :end_date 参数。日期格式应为 ‘yyyy-mm-dd’，例如 ‘2020-01-08’。它将返回以 end_date 为结束的 30 天期间内，所有有帖子上传的日期的数据。返回内容包括日期、上传数量以及该日期的总上传大小（以 KB 为单位）。结果按日期排序。
--[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
我是一名新加入的（Meta）社区成员，最近接手了另一个使用 Discourse（并由 Discourse 托管）的社区的管理工作。在仪表板上，我刚刚看到上传文件占用的空间出现了一次“跳跃”（从约 0.7GB 增加到 1.2GB）。看来数据探索器（Data Explorer）仅适用于商业版及以上套餐……是否还有其他方式可以找出最近哪些文件占用了额外的 0.5GB 空间？
这完全是我的责任。
过去我们曾存在一个严重漏洞，导致未能正确统计所有上传文件的大小。
当用户上传一张图片时，我们通常会将其调整大小 3 到 4 次，以生成不同分辨率并进行优化。这些优化后的图片会存储在云端，并继续占用存储空间。
要查看实际的图片，可以执行以下操作：
SELECT * FROM optimized_images
@simon 或许可以更新上述内容，将 optimized_images 纳入考虑？
啊，这很有道理。我在写这篇帖子时也曾短暂地怀疑过是否如此；)
嗯，也许值得在仪表盘的存储计量器上添加一句简短的说明，以免用户误以为有人正在用未知数据窃取他们的存储空间；)
另外，如果你们能创建一个不需要“商业计划”插件的“上传检查器”，那将非常受欢迎！！
祝好！
我终于明白了，我该如何查看不同主题和帖子中成员的上传列表？！
我想浏览上传文件目录。我的具体使用场景是调查这个已失效链接的详细信息：
如有任何管理员支持协助操作，将不胜感激。或者我是否遗漏了什么？此致，R
另一种变通方法是：
$ tar -xvzf xxxx.tar.gz$ cd uploads管理员门户上的图形用户界面将提供更好的用户体验。因此，我投票支持该功能。 R