I went to go explore this bug more in a localhost environment, but I don't see anything at Special:SecurePoll/create -> "poll type" that sounds like "STV" or "droop quota". Are there some steps to reproduce missing?

oh @Novem_Linguae I'm sorry I was working on this today. You can feel free to take over. The commit that caused the issues is https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/865096.

Dang. if it would be helpful I can file another bug about this tomorrow.

Note especially that it doesn't seem that any votes at all were counted.

I think the drag and drop input is sending malformed data. Testing it against the non-js form, I expect an array like [1135, 1136, 1137, 1138] where those numbers are the id of the candidates being voted for. The drag and drop input is sending data like [1, 'A', 'A', 'A'] (where A is the name of the candidate) back which the ballot doesn't know how to process. It's keeping the A values and since there are more than 1, it's being flagged as a duplicate, hence the user error. For that reason if you vote for n-1 unique candidates, it'll successfully go through.

How should we be handling normalising IPs? I find the IP I pass to the endpoint needs to match the exact format and capitalisation of the cuc_ip column.

Looked into this ticket and have some notes:

I've been treating this as the epic for this work so there are still a few subtasks remaining around this task (rights and logging) but there isn't any technical work specific to this task anymore.

Tentatively, perhaps we should only give this right to the sysop group at the moment? We had a discussion at our last check-in meeting and as far as any of us knows, there's no other standard group cross-wikis that meet the minimum reqs and should also presumptively have this right.

The other issues should be resolved, save:

Looking into these cases, it looks like anywhere that uses canViewPrivateFilters(Logs) should be audited and an equivalent canViewProtectedVariables should be added if necessary.

Marking this as resolved, as it is being solved by T364833: Add `user_unnamed_ip` variable and the follow-up tasks that support it (restricting access to PII, communicating changes, etc)

I'm not sure how to address this issue via the copy (without overcomplicating the error message?) Open to suggestions!

I ran the following tests using accounts with no permissions (logged out), view private only, and view private + protected:

Some conversation around this happened in one of the AbuseFilter check-ins and we talked through some clarifications we thought would improve the UX:

I think T355393: Provide fallbacks when source is missing data should cover the problem that Spur doesn't have a comprehensive dataset and the implementation of the fallback mechanism with GeoLite2, as I think this ticket encompasses a different set of problems:

I had a quick chat with @kostajh regarding this and it seems to be a combination of two problems:

• We removed the MaxMind data but gated the (possible) replacements behind full access
• Spur data isn't necessarily suspicious, afaik, but it is dynamic and IPs do drop off. Kosta and I were looking into some IPs and one of the IPs used was in our historical data (via OpenSearch) but had already been considered stale and dropped in the database used by the API.

I don't think we can just add the variable without violating the policy.

The simplest thing to do here is probably to continue exposing the IP. Right now these functions check the user_name variable but that variable can be anything:

To QA this:

I was working on the other observability task and happened to notice this upon some cursory investigation. Leaving this here in case it's useful for whoever picks this up (possibly me next week). It seems like the code is sensible and should emit to express_router_request_duration_seconds.service.ipoid, as the return of app.metrics.getServiceLabel() is {service: 'ipoid' }. This isn't making it to Prometheus and looking at the values.yaml helmfile, we don't specify a Prometheus endpoint. Maybe that's what we need? config.prod.yaml suggests these values:

there could be a situation where they decided to send an IPv6 in a specific format but then not used this format when parsing the response.

In T354758#9605053, @CodeReviewBot wrote:

stran opened https://gitlab.wikimedia.org/repos/mediawiki/services/ipoid/-/merge_requests/237

Return IPs in format user uses

Chatted with Kosta 1:1 and I'm a fan of removing dependencies wherever possible and pushed up a patch implementing the IPUtils approach.

Discussed this with @kostajh @Daimona @Dreamy_Jazz @Tchanders and we came to the consensus that it would be ideal if we could just create the temporary account on the action even though there won't be any edits associated with the account, as it maintains the stance that all actions should be associated with some sort of account. We were hoping to clear this with DBAs, as it's possible that accounts added here would never be valid end users (eg. LTAs triggering filters). I am vaguely aware of some discussion of table bloat but don't know where it is specifically so I'm not sure what the constraints are.