Page MenuHomePhabricator

How to deal with redundant block
Open, Needs TriagePublic

Description

For example a user be indef blocked twice.

Event Timeline

ConsequencesExecutor already reduces many blocks into one, which is the longest. But it currently does not take the talk page access flag ('blocktalk') into account. The following is a proposed solution.

If an unblocked user triggers multiple filters, some of which block the talk page access and some do not, they should be deduplicated per 'blocktalk'. If the longest 'blocktalk' happens to be longer than the longest 'blocktalk'-less one, only the latter one may be assumed. Otherwise, two blocks will be issued.

When a blocked user edits their talk page, the same deduplication procedure will take place. If it results in a 'blocktalk'-free block, it should be deduplicated with the existing block and possibly updated (instead of inserting another one). But if the talk page access is kept, the user could exploit this to generate logspam.

Multiple identical option blocks do not appear to be reducing in to one, they are just layering on top of each other.

{7BBD1D43-51E3-4740-B976-D44B5A80FB6B}.png (531×1 px, 34 KB)