Last modified: 2011-12-14 17:37:36 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 T17897, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15897 - Break down protection summary in log_params (machine-readable, timezone-friendly, localizable expires date/timestamp)
Break down protection summary in log_params (machine-readable, timezone-frien...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page protection (Other open bugs)
1.14.x
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 29646 (view as bug list)
Depends on:
Blocks: 21127 29235
  Show dependency treegraph
 
Reported: 2008-10-08 20:46 UTC by Roan Kattouw
Modified: 2011-12-14 17:37 UTC (History)
2 users (show)

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


Attachments

Description Roan Kattouw 2008-10-08 20:46:00 UTC
As of r40713, log entries for protections store some sort of protection summary like [edit=autoconfirmed] (expires 13:04, 4 October 2008 (UTC)) [move=sysop] (indefinite) in log_params, along with a flag telling whether cascading protection was enabled. Instead of storing this as one blob of formatted text, it would be cleaner and more API-friendly (more about this below) to store each of the pieces in a separate element.

So instead of $paramArray = array('[edit=autoconfirmed] (expires 13:04, 4 October 2008 (UTC)) [move=sysop] (indefinite)', 'cascade') I'd like to see $paramArray = array('edit', 'autoconfirmed', '20081004130400', 'move', 'sysop', 'infinity', 'cascade')

As to the API-friendliness: the current format makes it hard to extract protection data from list=logevents in a reliable way (currently, the only way is to parse the string, but that's not very future-proof). It'd be nice to be able to present this data in a decent format.

Assigning to Aaron as he did the log_params change.
Comment 1 Aaron Schulz 2008-10-08 21:04:11 UTC
This was actually due to r40770
Comment 2 Brion Vibber 2011-06-29 21:25:24 UTC
Adding a bunch of keywords to the summary so can find this bug again. :)

Bug 29021 is an example of the difficulties this causes; we got a report of a page on he.wikipedia.org that had mysteriously lost part of its protection settings... after some while of various people poking at it, we finally realized that the log line actually listed an expiration date for the part that had turned off .... but the date was listed in Hebrew, making it hard to find and extract from a mixed-language log line rendering by non-Hebrew speakers.

Bug 21127 also notes the confusion caused by hardcoding UTC time; for lots of European and some Asian languages, the vast majority of users have their timezone set to the local default and they're not used to having hardcoded UTC timestamps sitting around as often. Allowing it to be formatted into the local timezone along with all the other dates around it in the log view would improve consistency.
Comment 3 Mark A. Hershberger 2011-06-29 23:06:09 UTC
*** Bug 29646 has been marked as a duplicate of this bug. ***
Comment 4 Robin Pepermans (SPQRobin) 2011-07-06 22:01:57 UTC
This kind of clean-up should probably also be done for e.g. block log. The expiry time and other stuff is hardcoded in the params field.

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


Navigation
Links