Page MenuHomePhabricator

Allow searching also by new/target name on moving log page
Open, LowPublic3 Estimated Story PointsFeature

Description

Now our moving log only searchs the moving action by the source page's name, but we can't searchs the action by the target page's name.

Though we can check out the moving action in the page history or find the redirection which was the source page's name by some tools,we can't find the redirection which is deleted,or it's too hard to find it from a huge page's history.

So I suggest that we need to change the data structure of the moveing logging entity to make that we can search the page moving logging record by the target page's name too.


See Also:
T14984: Improve filtering and search in Special:Log

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:22 AM
bzimport set Reference to bz64184.
bzimport added a subscriber: Unknown Object (MLST).

Thanks for taking the time to report this!

I'm wondering if this is the same request as in bug 12984?

(In reply to Andre Klapper from comment #1)

Thanks for taking the time to report this!

I'm wondering if this is the same request as in bug 12984?

It looks like this but it's not the same.

Maybe we can make the logging list's interface can been changed when selecting the log type which it looks like the Extension:ApiSandbox.

Liangent said that For now’s data structure,Only Insert two moving log entity which one's log_title is the source page's name and the other's log_title is the target page's name.Or Query it in the database firsthand.

Would provide a useful page name history.

I mean, not altering the logs, providing a special page which would display all previous title of a given page would be sufficient.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM

Change 762102 had a related patch set uploaded (by TTO; author: TTO):

[mediawiki/core@master] Allow searching the move log by destination title

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

TTO subscribed.

This task looks set to come in 10th in the Community-Wishlist-Survey-2022 ; it didn't look particularly difficult to code up, so I thought I'd have a crack.

My patch adds the move's destination title to the DB's log_search table for new moves. There is also a maintenance script to backfill this data for old move log entries so that they too can be searched.

To search for log entries regarding a page being moved to title X, you have to go specifically to the move log (as opposed to "all public logs") and enter X in a new text field which is provided for this purpose. That's not a great UX - as a user, I would expect that simply searching Special:Log for target X would return all log entries where X was either the origin or the destination of a move. However, that's not very easy to implement, and is also not what this task is asking for, so I suggest we use T152829 to track that additional enhancement.

I'm wondering if Community-Tech might have a moment to look at this, in view of

In T66184#7706002, @TTO wrote:

This task looks set to come in 10th in the Community-Wishlist-Survey-2022

The patch is written and is almost there, just some minor issues have been flagged, but I have no time to address them.

TheresNoTime changed the task status from Open to In Progress.Nov 21 2022, 4:27 PM
TheresNoTime claimed this task.
In T66184#8243480, @TTO wrote:

I'm wondering if Community-Tech might have a moment to look at this, in view of

In T66184#7706002, @TTO wrote:

This task looks set to come in 10th in the Community-Wishlist-Survey-2022

The patch is written and is almost there, just some minor issues have been flagged, but I have no time to address them.

I've rebased & am working through the comments made — thank you again for your hard work @TTO!

TheresNoTime changed the point value for this task from 2 to 3.Dec 5 2022, 2:52 AM

Prefer T152829's solution. That works better in cases where the same name has been occupied by multiple pages at different points.

Prefer T152829's solution. That works better in cases where the same name has been occupied by multiple pages at different points.

I've added a note to this patch to bring a reviewer's attention to your comment :-)

Prefer T152829's solution. That works better in cases where the same name has been occupied by multiple pages at different points.

Please note the code-writer’s previous comment:

In T66184#7706002, @TTO wrote:

To search for log entries regarding a page being moved to title X, you have to go specifically to the move log (as opposed to "all public logs") and enter X in a new text field which is provided for this purpose. That's not a great UX - as a user, I would expect that simply searching Special:Log for target X would return all log entries where X was either the origin or the destination of a move. However, that's not very easy to implement, and is also not what this task is asking for, so I suggest we use T152829 to track that additional enhancement.

Test wiki created on Patch demo by TheresNoTime using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/770dbdaea0/w

From the perspective of the title search on Special:Log it would be easier to just insert a second log entry into the database. Only the first entry goes to RC (with IRC and feed) and the second is there to allow searching under the new name.
That would also allow to find the log entry from the "all public logs" selection, while the log_search solution would only work on Special:Log/move. This makes linking easier from history where a "View logs for this page" link is provided.
But that would increase the storage need for logging, where the log_search solution fits better in.

Two log entries would also bring in some problems, when looking at all logs of a performer contains often the same info. Maintenance work like revdel or suppression of bad page names needs to be done on two entries. [Edit: It must also be clear on implementation which of the both log entry gets the associated pageid/revid of the new and old page, even on redirect overwrite, redirect suppression]
I have no idea what is better, the current patch set is working and looks good.

For the protect log there is already a log entry added on move under the new name to make it possible to find the protect log for the existing (and not expired) protect of that page, to be shown when non-priviliged users want to edit a moved page. This second log on moving protected pages gives this inspiration.

Test wiki on Patch demo by TheresNoTime using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/770dbdaea0/w/

Pppery changed the task status from In Progress to Open.Nov 2 2023, 4:15 AM