Notably the enwiki electcom shouldn't be the decider in how this software works - some users of it may want this functionality even if others don't; perhaps adding support to securepoll for differentiating block-types for restrictions though?

A check somewhere (not sure where)

If it helps at all, I believe that would be here, with the blocked param being defined from User::isBlocked here.
Edit: naturally, I missed @Dreamy_Jazz's much more informative break down of the call tree here.

I would want to see the settings for blocked to be split, one for partial blocks and one for sitewide blocks. Therefore you can have a combination of allowing and not allowing partially blocked / blocked users. It doesn't necessarily make too much sense to disallow partially blocked users but allow blocked users, but I don't see that there necessarily needs to be a check to disallow this combination.

To make matters more complicated: fawiki's election policy states that users are only not allowed to vote if they are fully blocked or partially blocked from the Project namespace. Because SecurePoll cannot enforce that, and because our eligible voter list is always known a few days prior to the election start date, we actually import the list of eligible voters by hand, and at the end of the voting period, we manually check to see if anyone voted while blocked and have those votes struck by an election admin.

Anyway, the point is: it is not as simple as "partial blocks would be allowed to vote". At least in the case of fawiki, the specifics of the partial block matter. I am not sure if it is reasonable to expect SecurePoll to be able to support such complex eligibility criteria on-the-fly.

For very complex cases, those are likely a minority of users - that can be added to the override list as needed?

The sane thing to do here (and to resolve this task specifically) is just to add 'allows-partial-block' flag. 'not-blocked' will continue behaving as it does now, that means any block, which is intuitive. If the partial flag is further set, then the block will be inspected and if it's partial then voting be allowed.

Additional complex conditionals (block in namespace, number of pages blocked from, and whatnot) are not impossible but I'd consider that out of the simple scope here and would be better if discussed in a separate task.

I mean something like this

Before 'Must not be blocked' is checked	After

Probably this may stay stalled until the issue come up again while another election is ongoing which is not good, :) What English Wikipedia chooses this year is to allow partial blocked users to vote and this is unlikely to change,

Adding @eprodromou to review

I will be willing to write a patch if PET is committing to review

Change 667979 had a related patch set uploaded (by STran; owner: STran):
[mediawiki/extensions/SecurePoll@master] Allow for blocking on partial blocks

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

@Prtksxna I'm finding the shared label with the sitewide/partial blocked checkboxes looks a bit confusing, since it's not clear whether it applies to all four checkboxes.

Could we just follow the existing pattern and have two separate checkboxes?

• Must not be sitewide blocked
• Must not be partial blocked

In T268800#6898079, @Tchanders wrote:

@Prtksxna I'm finding the shared label with the sitewide/partial blocked checkboxes looks a bit confusing, since it's not clear whether it applies to all four checkboxes.

You're right. We could add another label for the rest of the options, but I think your solution is better.

Could we just follow the existing pattern and have two separate checkboxes?

Yep, that works.

We agreed in a meeting with @STran and @Prtksxna that we'd not tick sitewide blocked by default in this task

Change 667979 merged by jenkins-bot:
[mediawiki/extensions/SecurePoll@master] Allow for blocking on partial blocks

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

There are two new options in Special:SecurePoll/votereligibility.

If Must not be sitewide blocked is checked, sitewide blocked users are blocked from voting and see: Sorry, you cannot vote in this election if you are currently blocked from editing. Partial blocked users are not blocked.

If Must not be partial blocked is checked, partially blocked users are blocked and see: Sorry, you cannot vote in this election if you are currently partially blocked from editing.

Admins should be careful to note that if only Must not be partial blocked is checked, then sitewide blocked users will not be blocked. I don't know a circumstance where we would want this. Perhaps we could make it so, if this option is checked, then Must not be sitewide blocked is automatically checked, to prevent admin error.

I tested for database, system and composite blocks. Note that a composite block made up of partial and sitewide blocks (e.g. a partial user + a sitewide IP block) will count as sitewide, and the user will not be blocked by the Must not be partial blocked option.

It should also be noted that on https://vote.wikimedia.org the $wgBlockDisablesLogin is true, which means if you are blocked (either partial or sitewide) you will not be able to login to vote anyway. So, I am not sure how useful these new options will be on votewiki. I did my testing with $wgBlockDisablesLogin set to false.

There are two new properties in the securepoll_properties table corresponding to the two new checkboxes. The previous not-blocked property (if it is already set for an election) will continue to block sitewide and partially blocked voters. It will be removed when the admin edits the voter eligibility form.

Test environments:

• (mainly) Local docker SecurePoll 2.0.0 (91aab5c) 07:30, 24 March 2021.
• https://vote.wikimedia.beta.wmflabs.org SecurePoll 2.0.0 (df1d4cc) 12:16, 24 March 2021.

Thanks @dom_walden.

Admins should be careful to note that if only Must not be partial blocked is checked, then sitewide blocked users will not be blocked. I don't know a circumstance where we would want this. Perhaps we could make it so, if this option is checked, then Must not be sitewide blocked is automatically checked, to prevent admin error.

We talked about this in Estimation and figured we could keep it the way it is -- just in case there is a scenario where partially blocked users need to blocked that we don't know of. If we hear otherwise from the community, we could switch it up.