Noting the CodexTablePager component that was just added to Codex PHP. If we make use of that, we'd probably want to make use of the pagination feature on the Vue side, too, but that sounds like an improvement separate from this task.

Going to merge into T379167 as it's more descriptive of the problem.

I'm taking this off the sprint board to avoid confusion, as it sounds like we're still not are what we want. This task as written I'm pretty sure is wrong, but maybe we can rework it to only show edit/unblock for block entries that are active? That is sensible in all situations, and especially (much) later when our block log component is used elsewhere in MW.

I did forget about the "change visibility" link (for those who have rights to do so). That should be in the block log. So we do need the menu items!

In T379404#10310694, @dmaza wrote:

UI and social impact that comes with it are considerable

Could you exapnd? what does this mean?

I remember Partial blocks being enabled only on a handful of wikis following similar reasoning and now it is not optional anymore. What would be the benefit of having multi-blocks disabled?

UI and social impact that comes with it are considerable

Could you exapnd? what does this mean?

I think the gain in code simplicity is worth the loss in interface simplicity, given that this interface will only ever be seen by advanced users, and that we're anticipating multiblocks coming along soon after and being deployed on all production wikis

I think the gain in code simplicity is worth the loss in interface simplicity, given that this interface will only ever be seen by advanced users, and that we're anticipating multiblocks coming along soon after and being deployed on all production wikis

and to show Active Blocks even when multiblocks is not enabled

@dmaza @MusikAnimal IMO it makes more sense to remove the menu item entirely from Block Log, and only show it in Active Blocks (and to show Active Blocks even when multiblocks is not enabled)

Thinking ahead, one day we may want to reuse the block log component in other places (once they are Codex-ified).

I think there might be some confusion here: I was saying that the current behaviour is fine for now, and that as soon as you start typing it clears the block logs (but doesn't re-query for new data until you select a target). So all is well?

@Samwilson @MusikAnimal I'm guessing from Sam's last comment that this isn't absolutely necessary for the first release of Codex-Special:Block?

@Samwilson Confirmed "Editing their own talk page" is working as designed now as seen in the video below. Regarding AC3, I have created T379032. Thanks for all your work and I will move this to Done now!

Change #1087137 merged by jenkins-bot:

[mediawiki/core@master] SpecialBlock: Fix logic of showing User_talk editing block option

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

Change #1087137 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/core@master] SpecialBlock: Fix logic of showing User_talk editing block option

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

Ooh! Right, yeah that makes sense.

In T377722#10286560, @Samwilson wrote:

I'm assuming that the description didn't mean to have "not" and say, that when the block is partial and selecting the "User_talk" namespace, "Editing their own talk page" should be hidden since they are being blocked for all User_talk namespace, which includes their own talk page, right?

Yep! That's my understanding too. @dom_walden are we thinking about this correctly, or are things backwards?