Last modified: 2014-11-17 09:21:03 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.
Can you clarify a bit what sort of filtering you'd want and what it might look like from a user interaction perspective?
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.
*** Bug 20839 has been marked as a duplicate of this bug. ***
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).
(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.
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.
Code was mentioned for this over a year ago. What happened?
-"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).
*** Bug 56329 has been marked as a duplicate of this bug. ***
