Last modified: 2014-11-17 09:21: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 T20954, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18954 - Allow Special:Log to be filtered by log_action as well as log_type
Allow Special:Log to be filtered by log_action as well as log_type
Status: NEW
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Low enhancement with 7 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 56329 (view as bug list)
Depends on:
Blocks: 14334 17293
  Show dependency treegraph
 
Reported: 2009-05-27 11:46 UTC by Happy-melon
Modified: 2014-11-17 09:21 UTC (History)
12 users (show)

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


Attachments

Description Happy-melon 2009-05-27 11:46:26 UTC
This is probably a dupe, but I couldn't find it, and is related to bug17293.  This would probably require a new index on the logging table, action_time, but would be very useful.
Comment 1 Brion Vibber 2009-05-27 17:03:16 UTC
Can you clarify a bit what sort of filtering you'd want and what it might look like from a user interaction perspective?
Comment 2 Happy-melon 2009-05-27 21:08:19 UTC
Initially, extending the dropdown that currently default to "all public logs" to look something like this:

*All public logs
*Block log
**Blocks
**Unblocks
**Modifications
*Protection
**Protection
**Unprotection
**Modifications
*etc

Where a user can select any of the fields: selecting, say "*Block log" would have the same effect as currently: all actions of log_type='block'; but selecting "**Blocks" would display only log entries where log_action='block' (and redundantly, log_type='block').  Of course, this would probably require us to keep a track of exactly what log_action values we're expecting, so we can assign them system messages etc.  [[mw:Manual:Logging table]] suggests there're some fairly obtuse values floating around, which might need some cleanup (or at least working out where they came from and what to call them).  

Ultimately, it would be nice, in combination with bug17293, to implement a multiple select (a la the selects for status and resolution on bugzilla's advanced search) to select a number of log_types (or, even better, arbitrary log_actions). This would make it much easier to resolve bugs like bug17148 (and the similar one for suppression log entries showing up there, which I can't find), simply by changing LogEventsList::showLogExtract() to disregard these log_actions.  But that's a separate issue, and a separate bug.  
Comment 3 Aaron Schulz 2009-10-14 01:17:56 UTC
*** Bug 20839 has been marked as a duplicate of this bug. ***
Comment 4 Krinkle 2011-04-11 22:54:56 UTC
So, in order to be able to effeciently query by log_action, which indexes need to be added or changed ?

Right now there is:
>	CREATE INDEX /*i*/type_time ON /*_*/logging (log_type, log_timestamp);
>	CREATE INDEX /*i*/user_time ON /*_*/logging (log_user, log_timestamp);
>	CREATE INDEX /*i*/page_time ON /*_*/logging (log_namespace, log_title, log_timestamp);
>	CREATE INDEX /*i*/times ON /*_*/logging (log_timestamp);
>	CREATE INDEX /*i*/log_user_type_time ON /*_*/logging (log_user, log_type, log_timestamp);
>	CREATE INDEX /*i*/log_page_id_time ON /*_*/logging (log_page,log_timestamp);
at http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/tables.sql?view=markup&pathrev=84394#l1185

It may take more time for WMF to do this after deployment of the code (since it most likely requires the famous musical dance with the servers), but that should not block the development of this feature.

We should identify the needed changes to the indexes so that development can continue so wikis can use this feature as soon as possible (especially smaller wikis, outside WMF). In addition to the indexes there is much more that will have to be done
* interface for Special:Log
* stuff in the API perhaps
* debugging and optimalization
* whatever else that can and will go wrong

If we keep postponing this just for the indexes issue, the rest will get blocked too. If it's too dangerious for WMF or if WMF won't be able to do this anytime soon, it could be disabled by default until everything is sorted (like with the category sorting).
Comment 5 Roan Kattouw 2011-04-12 09:59:09 UTC
(In reply to comment #4)
> So, in order to be able to effeciently query by log_action, which indexes need
> to be added or changed ?
> 
> Right now there is:
> >	CREATE INDEX /*i*/type_time ON /*_*/logging (log_type, log_timestamp);
We would need to add (type, action, timestamp) there I guess.
Comment 6 Bawolff (Brian Wolff) 2011-09-11 02:50:31 UTC
Note, the index was added in r93211 by Reedy. Also I believe we already support filtering by action in the api, so all that's left is putting it in the web interface.
Comment 7 Rd232 2012-12-21 16:34:39 UTC
Code was mentioned for this over a year ago. What happened?
Comment 8 Krinkle 2013-01-02 11:02:26 UTC
-"schema-change". Index on log_type and log_action is available since 2011 and API supports it.

e.g. where [[m:Special:Log/newusers]] includes auto creations (which is effectively all WMF accounts globally since meta is in the auto-login) and:

https://meta.wikimedia.org/w/api.php?format=jsonfm&action=query&list=logevents&leaction=newusers/create&leprop=user%7Ctimestamp&lelimit=500

Only includes the "create" account (not CentralAuth autocreate or create2).
Comment 9 Kunal Mehta (Legoktm) 2013-10-29 18:37:07 UTC
*** Bug 56329 has been marked as a duplicate of this bug. ***

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


Navigation
Links