Page MenuHomePhabricator

Separate log action for moves suppressing redirects
Open, Needs TriagePublic

Description

There should be separate log actions for moves suppressing redirects. Moves saying "without leaving a redirect" should be separated from those with no modifier, while those saying "over a redirect without leaving a redirect" should be separated from those saying "over redirect". The log actions should be "move_suppress_redir" and "move_redir_suppress_redir", or something similar. See also T27799, which is a similar situation for patrol log entries.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 4 2016, 3:59 PM

Do you mean be able to winnow page moves in Special:Log/move using the new dropdown that allows you to filter actions? Page moves overwritting redirects can be already fetched from Special:Log/move, so just moves with no redirect creation remains if I understand your request correctly. Regards.

Do you mean be able to winnow page moves in Special:Log/move using the new dropdown that allows you to filter actions? Page moves overwritting redirects can be already fetched from Special:Log/move, so just moves with no redirect creation remains if I understand your request correctly. Regards.

Yes, and this requires an update to MovePage.php as well as MoveLogFormatter.php.

Change 406586 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/core@master] Separate log action for moves suppressing redirects

https://gerrit.wikimedia.org/r/406586

I don't think this is a good idea, as it is really confusing if you're querying past log entries. Furthermore, the mix of to booleans into four distinct options doesn't seem really elegant to me.

I think automatic tagging of log entries is a much better way to implement this.

@MGChecker Well, the same problem would also occur with patrol log entries as well. If you think that this isn't a good idea, then probably T27799 shouldn't have been a good idea either, then. But that was already fixed for newer log entries. Too late to worry about that, sorry. A task similar to T136493 will have to be created for fixing older move log entries.

While this case may be similar, there are some differences to the decision regarding the autopatrol log action. First, the tagging technology wasn't in reach at this time, furthermore there was only one general log_action before. This time, you already hace a table with distinct log_actions, which makes this one much more confusing for users. While fixing entries into the past may be possible, it isn't easy, and the solution you present here isn't really elegant in my opinion, as it's effectively mixing two bit flags into one. If we start to use log_actions that way, soon some may get the idea to merge three or four bit flags into log_action, which can't be wanted.