Discourse users are discussing the need for a feature to view and manage uploaded files. terraboss initially suggested adding an extra tab to the admin interface to track disk usage, file sizes, click rates, and filtering by extension and search terms. Tarek_Khalil and sam agree that this feature would be useful, but propose it as a report rather than a top-level tab.
sam outlines the main use cases for this feature, including understanding the upload problem, identifying the largest uploads, and tracking trends. joffreyjaffeux agrees that filtering logic would be necessary.
simon provides Data Explorer queries to retrieve details about post uploads, which could be added to the admin reports section. jochen_weber and robbie.morrison express the need for this feature, particularly for tracking recent file uploads and investigating linkrotted URLs.
robbie.morrison proposes a workaround by creating and downloading a site backup, but suggests that a GUI interface on the admin portal would provide a better user experience.
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
저는 (메타) 커뮤니티의 신규 멤버이며, 최근 Discourse(및 Discourse 호스팅)를 사용하는 다른 커뮤니티의 관리자 업무를 맡게 되었습니다. 대시보드에서 업로드(Uploads)가 사용하는 용량에 갑작스러운 증가(약 0.7GB에서 1.2GB로)가 발생한 것을 확인했습니다. 데이터 탐색기(Data Explorer)는 비즈니스 플랜 이상에서만 사용 가능한 것 같은데… 최근 추가된 0.5GB를 차지하는 파일들을 확인할 수 있는 다른 방법이 있을까요?
이것은 전적으로 제 책임입니다.
과거에 모든 업로드의 크기를 올바르게 계산하지 못하는 큰 버그가 있었습니다.
사용자가 이미지를 업로드하면 다양한 해상도와 최적화를 위해 최대 3~4회까지 리사이즈를 수행합니다. 이러한 최적화된 이미지는 클라우드에 저장되며 여전히 저장 공간을 차지합니다.
실제 이미지를 확인하려면 다음을 실행할 수 있습니다:
SELECT * FROM optimized_images
@simon optimized_images를 고려하도록 위 쿼리를 업데이트해 주실 수 있을까요?
아, 그게 말이 되네요. 제가 여기에 글을 쓴 직후에 잠깐 그런 생각도 해봤거든요 
흠, 대시보드의 저장량 게이지에 그런 내용이 담긴 짧은 문장을 하나 추가하는 게 어떨까요? 사람들이 알 수 없는 데이터가 저장 공간을 차지하고 있다고 오해하지 않도록 말이죠
그리고 비즈니스 플랜 플러그인이 필요 없는 "업로드 검사기(Uploads inspector)"를 만들어주신다면 정말 감사하겠습니다!!
감사합니다!
결국 다른 주제와 게시물에서 멤버들의 업로드 목록을 어떻게 확인할 수 있는지 이해하지 못했습니다!!?
업로드된 파일 디렉토리를 탐색하고 싶습니다. 특히 다음 링크가 깨진(linkrotted) URL의 세부 사항을 조사하는 것이 제 사용 사례입니다:
이 작업을 수행하는 데 관리자 지원이 이루어진다면 큰 도움이 될 것입니다. 아니면 제가 놓친 것이 있을까요? 좋은 소식이 있기를 바랍니다, R
또 다른 우회 방법은 다음과 같습니다:
$ tar -xvzf xxxx.tar.gz$ cd uploads관리자 포털에 GUI 인터페이스가 제공되면 더 나은 UX를 제공할 수 있습니다. 따라서 저는 해당 기능이 추가되기를 지지합니다. R