This look good @ifried. We should layout the checkboxes one below the other (instead of next to each other) now that we'll have three of them.

@STran, both these decisions make sense to me, thank you.

In T271674#6837307, @Tchanders wrote:

@dom_walden I assume the Organization is only needed in the infobox as per the task description, but @Prtksxna could confirm?

In T273976#6835112, @STran wrote:

Should this filter be disabled if "All SecurePoll logs" is selected?

In T274568#6828009, @STran wrote:

So if the user does not have js enabled should they be allowed to add "User_A"? I thought so because it's a valid representation of the username but for comparison, if you try to make an account with username "user_a", it will automatically normalize it to "User A." I also thought it would be jarring to type in "User_A" and when you navigated back to the page, to see "User A" but again, create account does it out of the gate and all of our logs normalize the username as well.

In T273976#6827016, @Tchanders wrote:

@Prtksxna What should happen if 'Admin log' is selected and neither of the 'Admin type' checkboxes are checked?

Prateek saw:
िहद वराज

In T271869#6814594, @Samwilson wrote:

Actually "Pick a format".

Sorry! I was going off the Figma specs. Should we change it?

Yep, changing to just (username) in the brackets make sense. Thanks for pointing it out.

@Tchanders I was thinking it could follow the same functioning and label as Special:Log, 'From date (and earlier):'. Is there something different in SecurePollLog that would benefit from '(and later)'?

Is it alright to have a link to a mediawiki.org help page in the help text? If so, the help text could be generic like "For more information, see Help:Downloading account data". We could then give more details on single project and wiki-farm setups there.

The help text at the top might need some updating.

The election record has been encrypted, but the decryption key is available. You can choose to either tally the results present in the database, or to tally encrypted results from an uploaded file

In T272763#6787149, @ifried wrote:

@Prtksxna: What do you think of this idea? And, if we go ahead with it, do you have an image file for the Wikisource logo that you recommend we use?

In T271869#6767885, @Samwilson wrote:

Why is MOBI described as being for Calibre? I would've thought EPUB would be closer to Calibre's "default" format.

@Tchanders merging the two forms sounds like a good idea. What do you think about not adding the radio, and instead processing using the file if its uploaded, and otherwise processing whats in the database? We could have some inlineHelp with the File input to explain this.

In T271830#6748774, @Tchanders wrote:

We're hoping this won't be the case after T271824: Improve the efficiency of vote decryption during tallying - would it be OK for us to do this as a separate task if it is still a problem?
…
Similar to the above, we're hoping that it will be like a normal form submission with results loading quickly. So it would work like any form - if you leave after submitting, you'll have to go back and resubmit. As above, could we move this to a future task if still a problem?

In T271279#6747585, @Tchanders wrote:

@Prtksxna Would there be value in being able to see all the logs of any type for an election in one go? If so, could we combine the pages into one, for example by having 3 checkboxes (Voters viewed, Admin added, Admin removed) and the Target input disabled if nether Admin added/removed are checked?

Thanks for the screenshots and explanation, @STran. We aren't using the pattern of having submit button both on the top and bottom in MediaWiki. We could make it work but it might require more design and subsequently development work. I'd suggest we go with option 2.

In T271354#6745339, @Tchanders wrote:

@Prtksxna Would it be possible to make another task if we want to restyle the error? It appears in quite a few places and is currently unstyled like the standard permissions error, as per @STran's screenshot.

@STran I thinks it's alright to use the same error text. Is there a default error style we can use here? Something from HTMLForm or OOUI?

We can add a text input to enter the key and decrypt the page

@STran could you share a screenshot of the page? Would it be possible to move the button to the bottom of the form?

From the description

@Prtksxna Do you think this feature would belong on the log page or somewhere else?

Thanks @Tchanders! Yep, I think its an alright trade-off to have a jump on IP ranges.

The errors in T263442 seem like they would result in no data being available instead of partial data. In that case, replacing the entire output with the error would be good.

Yep, only the last column has on-wiki information. # of users on IP is something that comes from the IP database, as far as I know MediaWiki can't have this information. Am I missing something here?

Thanks for your input, @JJMC89! I mostly agree, and that is what the current design does too. But, I have two thoughts around this:

1. When a lot of things are unavailable we might be taking up a lot of space without adding value
2. Not available and Errors are different things and might need different treatments (also see T263442). For eg, if we think refreshing the page could help show a value we should surface that.

@cwylo based on the interviews you conducted, do you think these value/color combinations make sense?

See T269268#6675315

See T270333 for more context.

See T270306#6697621

From the description

@Prtksxna If we do this task, we will no longer have a jump on IP address rows

I can see the box and popup on Beta! F33986809 F33986807

In T266262#6723153, @HMonroy wrote:

@Prtksxna Looks like badges are in the same place as where the new Download would be in Vector. I found https://en.wikisource.org/wiki/Template:Featured. If so, where would the download button go? Are you aware of any other feature that is displayed in the same Download area? Thank you!!

In T270338#6708707, @Tchanders wrote:

Before we decide, there are a few design/product questions to consider:

• If one request succeeds but the other fails, what should we do? E.g. should we show the data for the successful one and an error for the unsuccessful one?

In T270333#6720796, @Niharika wrote:

@Prtksxna What do you think about keeping both the name and the number in the ASN field?

In T266262#6699798, @HMonroy wrote:

Rather than a saved user preference, we can store the last download preference in a session cookie. This implementation would work for any user (logged in or not).

Noting that T267402: IPInfo: Blocked users can use IPInfo introduces another kind of error.

From the description

@Prtksxna Is it correct that we prefer the second one?

I think @Samwilson's patch was merged, but I don't see the labels on the tool. I don't think this is being actively worked on at the moment, moving to backlog.

From the description

This task depends on finalising a design - tagging @Prtksxna and @Niharika

In what context will the user be looking for range IP info? Will they be coming from CheckUser?
For History and RecentChanges pages, an edit can only be linked to a single IP address, right?

From the description

Or should it be consistent with the other pages (e.g. history pages, Special:RecentChanges) and display by the user link?

This is looking great @STran! Thanks for sharing the screenshots. I'll make follow-up tasks for the padding things we talked about.