Author: happy.melon.wiki
Description:
This is probably a dupe, but I couldn't find it, and is related to T19293. This would probably require a new index on the logging table, action_time, but would be very useful.
• bzimport | |
May 27 2009, 11:46 AM |
F3010907: deletion log.PNG | |
Nov 24 2015, 3:54 PM |
Author: happy.melon.wiki
Description:
This is probably a dupe, but I couldn't find it, and is related to T19293. 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?
happy.melon.wiki wrote:
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.
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);
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
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.
-"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:
Only includes the "create" account (not CentralAuth autocreate or create2).
Change 253072 had a related patch set uploaded (by Cenarium):
Enable filtering by actions on Special:Log
@Cenarium, just a comment on the idea: if this filtering is already allowed by the API, why not do it for all logs without requiring modifications to the logs (like https://gerrit.wikimedia.org/r/253073 )? Changing the structure of the logging table can be quite painful, more than any performance issue I think.
We need to have mediawiki messages to display for each log action, unlike the API, so available actions and their associated message must be specified somewhere for each filterable log.
In general, logs should not require modification. Patrol (T27799) is a special case, since it only had one log action - and in that case I think it can be done without much issue.
Change 257559 had a related patch set uploaded (by Cenarium):
Allow filtering by log action in FlaggedRevs
Hard to say at the moment. We'll know when it's merged (a few days to a week after that).
Definitely not SWAT. This would be totally out of scope and is a case for the regular deployment schedule, I presume.