Combined diff of relevant commits: https://github.com/wikimedia/grantmetrics/compare/d6df759d79726f14eef3c586cdf8d92393330174...d38b8b71d47b5ff4d7b252adc18061527a0ac593

Deployed to Toolforge. Give it a go! Validations and such should all be there.

Actually, I see all the mocks are recording the event wikis as en.wikipedia, and not enwiki as Grant Metrics is currently doing. I can change that behaviour pretty easily. It allows you to enter in any format and it will normalize it to the preferred format (which I assume is the domain without the .org). Follow-up commit soon to come!

@MusikAnimal Couple of things for this task:

• We should add some placeholder text so people know the right format for adding a wiki, date and time.
• Time is not optional. We can take out that checkbox. I'm sorry I overlooked that in the mock.
• The Delete and Settings icons in front of the events are always visible (not just visible on hover). This fix will also be need to be made for the Programs page. Can you also space them out a little from the event/program name?

I've updated the mock https://commons.wikimedia.org/wiki/File:Grant_metrics_2b_-_Create_new_event.png. New tasks I'll be making off of this -

• Checkboxes for "All wikipedias", "Commons" and "Wikidata". For now, we only need to worry about "All wikipedias" (the other two can be disabled while we figure out how the metrics calculation will work). About how we should store this in the DB, I think storing "allwiki" in ew_dbname should work and we can introduce logic to interpret it as all wikipedias instead of adding a row for every wikipedia every time someone checks that. It'll be fairly frequent, I think. I'll add a task to add the checkboxes and the logic for them.
• I'll add a task to add a date selector.
• I'll add a task to add a time selector.
• I'll add a task to implement wiki autocompletion. We're only dealing with wikipedias for now so this should be fine.

How do these sound?

I set it up locally and it seems to work fine except for two things - Clicking "Add wiki" doesn't do anything. Console error is ReferenceError: Can't find variable: setupAddRemove. And the date input boxes remain disabled even after I check the "Enable date/time" checkbox. Is there a step I'm missing?

Sounds good!

In T179549#3822782, @Niharika wrote:

• The Delete and Settings icons in front of the events are always visible (not just visible on hover). This fix will also be need to be made for the Programs page. Can you also space them out a little from the event/program name?

...

I set it up locally and it seems to work fine except for two things - Clicking "Add wiki" doesn't do anything. Console error is ReferenceError: Can't find variable: setupAddRemove. And the date input boxes remain disabled even after I check the "Enable date/time" checkbox. Is there a step I'm missing?

Try php bin/console assetic:dump

Checkboxes for "All wikipedias", "Commons" and "Wikidata". For now, we only need to worry about "All wikipedias" (the other two can be disabled while we figure out how the metrics calculation will work). About how we should store this in the DB, I think storing "allwiki" in ew_dbname should work and we can introduce logic to interpret it as all wikipedias instead of adding a row for every wikipedia every time someone checks that. It'll be fairly frequent, I think. I'll add a task to add the checkboxes and the logic for them.

Yeah, I like putting allwikipedia or allwikivoyage, etc. as the ew_dbname. Getting the list of Wikipedias, for instance, isn't that hard: SELECT dbname FROM meta_p.wiki WHERE family = 'wikipedia';. For all wikis we can just have no EventWiki association.

Since they are individual wikis, do we need checkboxes for Commons and Wikidata?

• I'll add a task to add a date selector.
• I'll add a task to add a time selector.

I recommend allowing for the browser's built-in date/time selector, like we do now. The work is already done, it's localized, and mobile-friendly.

I just realized however that amazingly desktop Safari still hasn't implemented HTML5 input type=date and type=time. I would weigh out developer and translator burden versus browser support, since Safari usage is very low. A custom datepicker means we need to add all those i18n messages, etc. The backend should be able to interpret common formats they'd enter as free-form text, but as you say there should at least be some placeholder text for an example.

In T179549#3823325, @MusikAnimal wrote:

I would weigh out developer and translator burden versus browser support, since Safari usage is very low. A custom datepicker means we need to add all those i18n messages, etc.

We could use Date Range Picker! This is the same library that Pageviews Analysis uses, so it's comprehensively translated, we'd just need to import the messages. This library is pretty neat because it validates clientside, e.g. making sure the start date is before the end date.

The only problem is I'm not sure how well it will play with the Symfony form system that we're using. It's certainly doable but probably won't be easy, so maybe we can sidestep for now until the more high-priority tasks are complete.

In T179549#3826914, @MusikAnimal wrote:

In T179549#3823325, @MusikAnimal wrote:

I would weigh out developer and translator burden versus browser support, since Safari usage is very low. A custom datepicker means we need to add all those i18n messages, etc.

We could use Date Range Picker! This is the same library that Pageviews Analysis uses, so it's comprehensively translated, we'd just need to import the messages. This library is pretty neat because it validates clientside, e.g. making sure the start date is before the end date.

The only problem is I'm not sure how well it will play with the Symfony form system that we're using. It's certainly doable but probably won't be easy, so maybe we can sidestep for now until the more high-priority tasks are complete.

Sounds good. I didn't see the date/time pickers because I'm on Safari.

Assetic:dump fixed my issues!

We can skip having checkboxes for Commons and Wikidata BUT know that Commons and Wikidata cannot be used in conjunction with Wikipedias, not yet at least. So it'd need some JS hackery to ensure Wikidata/Commons cannot be added to the textbox once a wikipedia has been. I thought doing this using checkboxes would be simpler and more intuitive.

Daterangepicker is live! Give it a try :)