Last modified: 2014-05-23 16:25:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T38497, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 36497 - Hiding file upload log entry should also hide the contents of the "Summary" box on file pages
Hiding file upload log entry should also hide the contents of the "Summary" b...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Revision deletion (Other open bugs)
All All
: Low minor with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: schema-change
Depends on:
Blocks: SWMT
  Show dependency treegraph
Reported: 2012-05-03 20:48 UTC by Tomasz W. Kozlowski
Modified: 2014-05-23 16:25 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Tomasz W. Kozlowski 2012-05-03 20:48:29 UTC
The default behaviour of many of our upload tools, scripts, and the UploadWizard is to insert the data from the upload process into the upload log description entry -- for example, see a random file uploaded with UploadWizard <>.

However, hiding the upload log entry containing inappropriate information does not completely remove the data from the wiki, for it is still visible in the "Summary" box visible on the file description page -- in this example, here <>.

To remove the data from the box, one needs to re-upload a file again, and suppress the edit summary -- please have a look at a real life example at <>.

As both the edit summary and the upload log entry contain the very same data, it would be nice to have the ability to hide the edit summary while hiding the upload entry log (and the other way round).
Comment 1 Aaron Schulz 2012-05-04 02:23:27 UTC
You don't have to re-upload, just make a new edit and suppress the old one.
Comment 2 Snowolf 2012-05-04 11:47:02 UTC
I just tested the bug on testwiki per request from Odder, it appears indeed that revision deletion / suppression of the edit summary has no effects on the "summary" box, which in practice leaks the suppressed info. See -
Comment 3 Snowolf 2012-05-14 20:20:36 UTC
Aaron, unless I'm misunderstanding something here, making a new edit doesn't fix it, because it's the file log, not the edits on the page.
Comment 4 Aaron Schulz 2012-05-15 08:33:47 UTC
(In reply to comment #3)
> Aaron, unless I'm misunderstanding something here, making a new edit doesn't
> fix it, because it's the file log, not the edits on the page.

You mean the "file history" (image+oldimage table)? Yes, that would require reverting to an old version or a dummy upload (if there was none), since you can't hide anything in the current versions. I don't recall why that is, since regular page "revision history" does not have this limitation (the only limitation is that you can't hide the text, just the user/comment).

Probably the file code could be refactored to allow hiding the img_description field/user by itself.
Comment 5 Tomasz W. Kozlowski 2012-11-03 21:34:49 UTC
This is just to mention that the current behaviour is seriously annoying when dealing with mass suppression requests, because one needs to (1) re-upload every single file that leaks certain information and then (2) suppress the contents of the "Summary" box. 

I've had to do this ever since becoming an oversighter on Commons, and can tell that it considerably slows down the whole suppression process.

As the "Summary" box contains the very same data that is visible in the description of the upload log, not having to suppress/rev-delete it on its own would be highly appreciated, and especially time-saving.
Comment 6 Scott Martin ( 2013-01-31 13:20:36 UTC
Additionally, the file history table is visible on file description pages on any given Wikipedia. This means that even if someone has performed a Wikimedia-wide rename for privacy purposes, such file summaries will leak private information outside of Commons in multiple locations. I'm changing this bug from "Enhancement" to "Normal" for that reason; this issue needs to be addressed.
Comment 7 Pierre-Selim 2013-08-20 09:09:23 UTC
As a fresh oversighter, I can tell you that this bug is already a nightmare for me.

As a product owner myself, I know this kind of bugs can get stuck in the backlog  however it is quite essential for privacy protection (I already have a list of 46 files to upload one by one ...).

Thank you for reading my plea ^_^
Comment 8 Bawolff (Brian Wolff) 2013-08-20 17:40:42 UTC
Marking as schema change. image table doesn't have img_deleted.
Comment 9 Pierre-Selim 2014-05-23 16:25:03 UTC
Is there any plan in fixing this bug and making oversighter life a little less hard ?

Note You need to log in before you can comment on or make changes to this bug.