Where do we stand with this? If we're ever going to change the routing, we should probably do it soon.

In T204631#4596902, @Samwilson wrote:

Another next step is to move the repo to the Wikimedia org on Github. Who can do that?

We could offer a checkbox "Use subject page instead of talk page", for each category. How does that sound?

I was just talking about Phabricator tags, as everything tagged with Event Tools would conceivably also need the Grant-Metrics tag. Just makes it harder to manage, is all.

One thing I overlooked:

This was done as part of T194703, T194707, and T194704. Going to close this since the code is the only thing to review and it's part of the other tasks. Hope that's okay!

This has been deployed

@Niharika Done!

Deployed

Also note https://tools.wmflabs.org/sql-optimizer is a thing, which uses some hacky workarounds. Some queries still can't be explained, though, such as those with UNIONs.

In T194703#4594810, @Niharika wrote:

I found a few more issues. Would you prefer I create bug tickets for those?

In T141704#4594564, @Krinkle wrote:

@MusikAnimal Was that message shown within the wiki interface? I would expect that to correlate with an "ERROR"-level message in the logs, but it seems it only correlates with INFO-level messages.

Officially up for code review! https://github.com/wikimedia/grantmetrics/pull/115

@jmatazzoni What I have for category support is now on https://tools.wmflabs.org/grantmetrics-test Give it a try! See T194703#4585030 for details.

the system would determine the IP address of the event location, and the code would work only from that IP address

Or, would it make more sense to put Event Tools a subproject of Grant-Metrics? (https://phabricator.wikimedia.org/project/subprojects/3009/)

This is amazing! I'm awed by your browser prototypes. You've basically done all the frontend coding! ;)

Thanks! So if I understand correctly, externallinks isn't going anywhere, correct? Am I safe to start using it again on the replicas?

I'm going to merge with T201659. After that discussion, and seeing this report, I think it makes more sense to show percentages relative to all editors. Will try to get this implemented soon.

A rough demo is now on https://tools.wmflabs.org/grantmetrics-test. Feel free to give it a try!

No API. Python-urllib should normally be OK but with XTools we saw abuse. I just copied the things we were blocking there.

I blocked Googlebot and the usual other web crawlers to the lighttpd configuration:

The ability to auto-include redirects is a commonly requested feature (T163621, T200256, for example). I built Redirect Views for this purpose, but currently you can only look up one page at a time. Tools like Massviews process thousands of pages. For this we'd need pageviews for the target page + redirects to be precomputed and provided by the API, as doing it programatically would be much too slow and inefficient.

The overflow: auto CSS rule hides the autocompletion dropdown :(

One possible issue... it might not be obvious that you have to hit Submit after removing participants, too. For that I propose graying out the item:

In T204168#4578658, @Niharika wrote:

The green icons make it look like those usernames are saved, when they may not have been (say you added those at the same time as the invalid one, you must fix the invalid one first and re-submit).

Agreed. In this design (looking at second screenshot), will the ones that were correct in the input be saved automatically or should they be represented differently? In other words do we still have three states:

• Saved
• Unsaved but correct
• Unsaved and incorrect

I inadvertently deployed this along with T201437 and T200541. The deploy script just pulls from master, so this code went with it. If there are any concerns, let us know and we'll get a fix out ASAP! Gonna leave this in the Product/QA column for now.

Deployed

Deployed!

Same issue as T203339, I assume. Somehow some of the production cache files went missing. This was fixed by force-clearing the cache again (which in turn regenerates all those files). I could have sworn I checked all the APIs after T203339, hopefully I didn't -- meaning it is a one-off issue and not persistent.

See also T192724, probably could be closed as a duplicate. My suggestion was something that resembles XTools, with a clear +/- diff format:

If you do use Symfony, be sure to use Symfony Flex, too: https://symfony.com/doc/current/setup/flex.html

This comment is assuming Event Tools is the same as Grant-Metrics, which I think we've more or less confirmed?

my proposal is to compromise by validating that the category title exists in either the category or page table

Got this on enwiki when attempting to delete https://en.wikipedia.org/wiki/File:Dr._Richard_Pierzchajlo,_Head_Shot,_2017.jpg

The UI I'm currently building matches the behaviour of the participants form. When I have something to show (soon!), I'll be sure to put it up on staging and have you all review it.

I wonder if we could bundle this work in with some of the Event Tool work?

For the record, XTools allows users to opt-in to restricted statistics by creating User:<username>/EditCounterOptIn.js on the said wiki, or User:<username>/EditCounterGlobalOptIn.js on Meta to apply to all wikis. This is in addition to a list of wikis that have consensus to always show these stats, which currently only includes English Wikipedia.