Last modified: 2011-03-13 18:06:28 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 T14571, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 12571 - Allow Special:Log/rights to be sorted by rights changed
Allow Special:Log/rights to be sorted by rights changed
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Special:...
: schema-change
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-10 03:26 UTC by Mike.lifeguard
Modified: 2011-03-13 18:06 UTC (History)
3 users (show)

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


Attachments

Description Mike.lifeguard 2008-01-10 03:26:47 UTC
To allow sorting of log entries by the rights changed. Something like "&right=sysop" would then show entries where the sysop right was granted or revoked. Simetrical said "very hard to do server-side" but here's the request regardless.
Comment 1 AGK 2008-01-11 19:56:29 UTC
This is a highly useful addition, and I'd be pleased to see a developer that finds the time to implement a brief log fork implementing this. Early agreement for this has been generally seen, at the WT:RFR page <http://en.wikipedia.org/wiki/WT:RFR>.

Anthony

User:AGK
en.wikipedia.org
Comment 2 Aaron Schulz 2008-01-11 19:58:49 UTC
Don't expect his to happen, really.
Comment 3 AGK 2008-01-11 20:01:18 UTC
Why do you say that? Is it /unable/ to be done? Is it being refused? Is the situation too controversial at this time?
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-11 20:16:10 UTC
This is totally impractical with the current schema.  Scanning a few hundred times as many rows as are needed would probably be common with the enwiki setup, even if you don't allow arbitrary searches of this type.  (If you do, you could look for all bureaucrat promotions with a limit of 500 set and force a scan of *all* rights-change rows.)  Some new schema would have to be developed, possibly specific to userrights logs but possibly uniform across all logs.  The former is messy and problematic in various ways.  The latter is cleaner and works better for combined log display, but I'm not sure how it would be best achieved.

One possibility would be to break off log_params into its own 1:N table, theoretically something like logparams (lp_log, lp_key, lp_value) (with lp_log a foreign key into logging.log_id).  Then, for instance, for userrights, instead of storing "sysop\nsysop, bureaucrat", we could store two rows like ('previousgroup', 'sysop'), ('newgroup', 'sysop'), ('newgroup', 'bureaucrat').

In practice, for this to be efficient we would need to denormalize substantially, since cross-table indexes aren't possible.  To allow efficient retrieval of all rollback additions we would probably need something like (lp_log, lp_type, lp_action, lp_key, lp_value, lp_timestamp, lp_deleted), with all the added fields being carbon copies of the respective logging columns.  Finally, redundancy should be added to the rows, so that in the case of user rights, you would add additional keys like 'addedgroup', 'removedgroup'.  That would make the desired query something like

SELECT *
FROM loggingparams
JOIN logging ON lp_log = log_id
WHERE lp_type='rights'
AND lp_action='rights'
AND lp_key='addedgroup'
AND lp_value='rollbacks'
AND lp_deleted = 0
ORDER BY lp_timestamp DESC

would be efficient with appropriate indexes ("appropriate" being, I guess, (lp_type, lp_action, lp_deleted, lp_key, lp_value, lp_timestamp) or some similar monstrosity).

Honestly, this would require so much denormalization that it might be best to scrap the entire logging table and add all its fields to the loggingparams table, since the former would contain practically no useful information not already contained in the latter.

Needless to say, all this is fairly complicated.  I don't anticipate this getting done unless some dev gets really interested in solving the problem (Werdna seems to be a good suspect for this sort of thing).  It would have considerable benefits beyond this, though: it would allow much more flexible log filtering and sorting for *all* log types.  Of course domas will hate all the wasted disk space and indexes, too.  Anyone have a better idea that would actually work?
Comment 5 Mike.lifeguard 2008-01-14 22:57:18 UTC
There is a decent script for this thanks to Splarka. Might be nice to have it in the software, but I won't cry if you kill this bug.
Comment 6 Aaron Schulz 2008-05-10 22:45:37 UTC
not implementable

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


Navigation
Links