Do stewards need flow-create-board for global renames to be able to rename user's Flow boards? They don't have it currently.
@Trizek-WMF:
Every time a user who uses Flow on its talk page asks to change its username, the Flow board is not moved.
Last case. I had to be pinged, find someone to delete the destination page and then move the Flow board (when I have enough rights to move Flow pages on the designated wiki). Give the right to bureaucrats to move Flow boards would help.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T96304 Validate which Flow moves are allowed? | |||
| Open | None | T126229 flow-create-board for bureaucrats?, global renamers? stewards (done) (and "Global rename script" ?) |
I checked with @Legoktm. Global rename bypasses permissions checks, so this is unnecessary provided Flow does its checks in the right way (T126389: Update move permission code).
@Legoktm @Catrope We might want to just do this and see if it solves it, rather than dig into the above.
This is still an issue per T150572: When a page move is triggered by RenameUserJob, page should be moved anyways even if it is a Flow board.
If so, apparently this is needed for "Global rename script" as well per T159482: Enable Flow in cawiki User talk namespace of new users.
We've added the 'flow-create-board' right to our global group so we can manually fix Flow board moves afterwards. This is still an issue of course, and the best solution IMHO would be what I mentioned on T150572. Thanks.
Alright, let's also see if that helps with the automated moves too. We may still need to do 'Global rename script' as well.
@Mattflaschen-WMF: New issue with this today at zh.wiki again. Now that we have 'flow-create-board' rights on our global group I could move the page (but I had to delete the destination page first in order to move the board as the system complained that the content model was not allowed in the target page).
My idea is that globalrename does this, either with our accounts or Global rename script when our accounts do not exist on the wiki. The other option might be to have Flow talk page manager do this for each user rename. Does that sound good as well? Regards.
Did you start with the global rename, or start with the a manual rename?
Did you get the error about "content model was not allowed in the target page" in the global rename or in a manual rename?
Was the destination page a redirect? Does global rename normally delete destination pages automatically?
A global renamer just did the global rename first, of course. He later noticed that the Flow board didn't moved, so he asked me if I could manually fix it so I did.
Did you get the error about "content model was not allowed in the target page" in the global rename or in a manual rename?
In the manual page-move.
Was the destination page a redirect? Does global rename normally delete destination pages automatically?
No, destination page was not a redirect. It had wikitext content though which was added after the rename was performed (page didn't existed before the rename).
Regards.
Got it, thanks. Also, I see the renaming user did exist on zh.wiki, so 'Global rename script' isn't relevant for this case.
So we still need to track down T150572: When a page move is triggered by RenameUserJob, page should be moved anyways even if it is a Flow board. Giving 'Global rename script' flow-create-board probably wouldn't help.
I don't remember why we didn't give flow-create-board to global renamers. @MarcoAurelio Any objection to adding global renamers?
That may not solve the "I could move the page (but I had to delete the destination page first in order to move the board as the system complained that the content model was not allowed in the target page).", but it should at least address cases where there is no destination page.
(@Trizek-WMF If I read https://meta.wikimedia.org/wiki/Global_renamers right, the 'bureaucrat' group technically is not relevant. It's just there is overlap between the two groups.)
I've put T231783 in upcoming work for the Growth-Team. As for this task, it seems like the title & description need to be updated to make it more clear about what is being requested here. Because of unclear requirements and the upcoming Talk Pages project, the Growth-Team will not work on this in the short-to-medium term.
global-renamer is a local group existed on Meta-Wiki, and if flow-create-board permission should be given to all global renamer, a global group is required to be created. This is a really rare case - currently, only stewards have both local (metawiki) and global groups. What's more, not all users pending rename have Flow talkpage enabled - in fact, only a small percentage of them. Seems some old discussion on Meta-Wiki concluded that as cases involving move action of Flow talkpage are kind of rare, there does not exist a large necessity of creating a global group - including flow-create-board permission - to global renamers. Stewards could fix them if an issue is found.
In that case, I suggest making the Flow talk page manager do that automatically when global renamers rename users.
According to a recent query, There are at least 200 user talk pages not moved just on zhwiki alone, so this is definitely not a minor issue.
200 pages is a lot. I think the Growth team needs to discuss about this issue once again.