The logging table stores the log_namespace, log_entry of the affected pages
it also stores at log_page the page_id
Behavior: for an upload action, log_page gets a 0
Expected: to store there the page_id of the description page
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T44164 Wiki Loves Monuments 2013 (tracking) | |||
| Resolved | None | T39144 UploadWizard: Wiki Loves Monuments contest issues (tracking) | |||
| Resolved | kaldari | T40606 Set log_page to the page_id of its description page for upload actions |
RobLa not having the page_id there makes some queries that should be simple, quite convoluted.
For instance, here's what I ended up coding for determining the (original) uploader and date of an image:
Still, I remember it being fooled by files uploaded with a filename equal to others deleted.
You cannot just rely on the upload filename given in the Log table, since the file may have been renamed. The last upload may not be what you want (eg. FlickrReviewer uploading a bigger size). I don't remember right now the reason for not diving into oldimage table.
Having the log_page would allow a simple JOIN from the upload log entry to get the associated page (if not deleted). And in Wiki Loves Monuments there will be many scrutiny of images and logs.
(In reply to comment #4)
Fixed in https://gerrit.wikimedia.org/r/21960
Keeping open until deployment.
Why? Deployment happens automatically every 2 weeks. Waiting for merge is long enough.
No, bugs get closed when they are merged into master. I expect Commons will get this change on the 5th of September with the 1.20wmf11 deployment to all non-wikipedia wikis.
That's too late for Wiki Loves Monuments and would screw up the data. For us this is not fixed so please keep it open or just deploy it to Commons earlier.
Closing this again is a good way to piss off your volunteer developers, so please don't.
I've created Gerrit change 22008 to have this (hopefully) merged into wmf/1.20wmf10 and deployed for 1.20wmf10 wikis (including commons). Krinkle was correct to resolve this bug.