Use case:
If a redirect is created to a section of a page, or a related topic, and then a full page is created for the topic, it cannot be moved to the redirect without moving the redirect out of the way
Implementation:
A new right is added, delete-redirect, to allow users to overwrite all single-revision redirects. The deletion is logged separately as delete/delete_redir2
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add `delete-redirect` for deleting single-rev redirects during moves | mediawiki/core | master | +150 -42 |
We've discussed this internally in the CPT group, and we don't see a big objection, and it seems like a nice benefit, especially for people who do a lot of page moving. We'd like to see you get some community discussion on this to shake out any possible bad ramifications before there's a patch ready to review.
My patch wasn't going to assign this right to anyone by default, since the only non-controversial assignment would be sysop, which doesn't need this since it has delete rights.
I'm having the deletion logged differently (delete/delete_redir2 instead of delete/delete_redir), given that the deletion is inherently different.
Following the current behaviour for delete and move, the actual move is logged as a normal move/move
Question: this will introduce a variation of moving over an existing page that allows users without delete rights to overwrite any single revision redirect. Given that this deletion should not be possible outside the context of moving a page, it seems like the only way to do this via the api would be to add the functionality requested in T44886: No option to move over an existing non-redirect page in the API (adding on option to the move api to move over an existing page). That task was declined by @Anomie, saying
Given the new feature introduced here, @Anomie would you be willing to reconsider declining that task?
No.
action=move already supports the existing case of moving over a single-revision redirect that points to the source of the move, i.e. moving A over B when B exists as a single-revision redirect to A. This new feature is just removing the "that points to the source of the move" condition, and can be added as such without going all the way to doing what was requested in T44886.
If you look at the patch I provided, to ensure that the user intended to delete a different redirect and enforce the user right restrictions I used the same process as the current moving over an existing article (i.e. delete before the move, rather than as part of it) and so I don't believe that the current action=move supports this new behaviour.
Sorry; I've been working on this at https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/554365/, but haven't tagged the task until it was ready for review
Change 559622 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Add delete-redirect for deleting single-rev redirects during moves
I looked at this, but the comments I left on PS5 do not seem to have been addressed in PS6.
PS6 was just a rebase.
The comment on PS5 was regarding moving "delete by overwriting" logic out of the movepage special page and into the movepage class itself.
@daniel commented:
Since "automatically move before deletion" is a notion owned by the UI layer, it seems correct to handle the permission there as well. One could of course argue that this logic belongs into the MovePage class, but that should be a separate discussion and a different patch.
@Anomie commented:
Is it a notion owned by the UI layer? Remember that if we put it there then it has to be implemented multiple times: in SpecialMovepage, in ApiMove, and potentially at some point in the future in a MW REST API Handler as well. If we put it here, then we just have to have each of those UI layers call it in the right way.
but that should be a separate discussion and a different patch.
Why do it wrong only to go back and fix it soon after?
@DannyS712 commented:
If I submit a patch to move delete and move logic into the MovePage class (haven't looked at doing this yet, just asking, not committing) will it be reviewed?
I don't believe that this should be included as part of this task, but can look into doing it separately if CPT can commit to reviewing it?
Change 559622 merged by jenkins-bot:
[mediawiki/core@master] Add delete-redirect for deleting single-rev redirects during moves
Are there any default (or wmf-specific) groups this will be added to, or will WMF communities need to request this be added to groups as needed?
No groups have it yet. I was envisioning this as a right for enwiki's page mover group, and was planning to start a discussion for that at some point once the train reaches enwiki
We should consider granting to autoconfirmed by default, though I'm not sure it's the right course. Since it only allows deletion of single revision redirects, I doubt that misuse will lead to serious disruption, and with rate limits any problems should be caught before they get out of hand. That said, since revisions are deleted, any problems would have to be resolved by admins because non-sysops wouldn't be able to figure out where the redirect pointed before the page was deleted. For smaller projects with few admins, that might be a bottleneck to avoid.
@DannyS712: I'm not familiar with the api specifics, but could we log the original redirect target as part of the history or deletion log entry? If the deleted target was part of the publicly visible log history it could mitigate some of those problems. Something like: "User:Example moved the page Foo to Bar over a redirect targeting Biz." That way if editors need to clean something up they know to restore a redirect to Biz without requiring rights to view deleted history
That is not currently logged, and I'm not sure how to do so.
If I understand the history correctly, the automatic deletion of single-revision redirects that point to the title being moved was added to combat page move vandalism. That shouldn't be a concern here, which is why I didn't assign it to autoconfirmed by default
I'd say it isn't. For enwiki's page mover group, it's fine, but becoming autoconfirmed is a simple process. I'd prefer not to see 4-day-old accounts (with a few sandbox edits on some wikis) creating vandalism pages and moving them above valid redirects, creating damage that requires sysop tools to undo. While it will never happen to the same page again, there's a lot of targets to choose from on large wikis.