In T365629#9900683, @ifried wrote:

@gonyeahialam & @Daimona: For the event page title, can we only display the event pages in which the user is an organizer (when the dropdown appears during the time that they are filling in the field)?

Hey @ifried, I have two minor questions that came up in code review.

1. Should the two notices ("This wiki does not have invitation lists enabled" and "You are not allowed to use invitation lists") end with a full stop? This isn't very clear in the AC.
2. What should happen if a logged-out user visits the Special:GenerateInvitationList page and the feature is not enabled? Should we tell them that the feature is disabled, or should we ask them to login, and then tell them that it's disabled? I think the first, but I'd like to hear your thoughts on this.

I think a way to test this would be to 1) confirm that there's a substantial reduction in the number of queries, especially when showing many events (can be quickly seen in the debug toolbar), and 2) verify that the information shown is still correct.

Thank you. Is this ready for DBA review then?

In T365629#9890374, @gonyeahialam wrote:

With the component we are going to use for this, where they have to select form a dropdown that appears as they type, is it still possible to input the wrong event page? @Daimona

I was going through this again, and I have a few questions/thoughts:

• AIUI, "worklist" is just the list of articles. "Invitation list" is the list of users to invite, and we're also using this term to identify the combination of worklists + users. But then, shouldn't ce_worklists actually be called ce_invitation_lists? ce_worklists_articles is maybe fine, though I'm unsure about the plural in "worklists". ce_worklists_users would presumably be ce_invitation_list_users?
• Who should be able to view a given invitation list? I thought it would only be the person who created the list itself (not the event). If so, we should store the creator of the list in the ce_worklists table, else we don't know who each list belongs to.
• Thinking about indices. In SpecialMyInvitationLists, we'll need to filter by user and, optionally, wiki. So, I think we'll need a composite index on user + wiki (in this order). I don't think the application needs an index on the wiki alone, but unsure about whether it's needed for analytics. The other indices seem sufficient (I think we'll only need primary keys and the indices on invitation list IDs).
• There's also the page ID question that was discussed in code review, which should go with the DBA review.

Things we are currently checking:

• article names must be valid (i.e., no special characters that are not allowed in page titles)
• page must exist
• page must be in the mainspace

In T366354#9885784, @Daimona wrote:

@cmelo The current schema only stores the wiki of the event page, but that field might be absent.

In T365859#9886466, @ifried wrote:

Overall, what do people think? Do we think this works?: Include ongoing events within the date range

(Also: the fix should be live in... A few days I think. It needs to wait for the next l10n update. But it can be easily verified locally by updating the translation of the campaignevents-edit-field-tracking-tools message in sw.json)

There was an extra linebreak in the Swahili translation of that message. The next line was also starting with a space, which is interpreted by the wikitext parser as a literal (<pre>) section. I've fixed that. (CC @Jadnapa)

@cmelo Another thing I realized while we were discussing T356683: we need to store the wiki where the invitation list was generated. This would allow us to only display local invitation lists in Special:MyInvitationLists. The current schema only stores the wiki of the event page, but that field might be absent.

• Show events that already started and are ongoing

In T356683#9880765, @gonyeahialam wrote:

This is my current exploration for this @cmelo @Daimona @MHorsey-WMF

Discussed today. We will run three queries to get: 1) all the creators, 2) more organizers to show, 3) the number of organizers for each event. This will be done before processing individual rows (e.g., in preprocessResult). We will also use LinkBatch to run existence checks for all the user page links. The data will be stored inside the class and looked up when building the individual rows.

Ohhhhhhh I see. It seems to be caused by the AutoScroll extension I have installed. It's weird because it's the first time in a few years that I'm having this kind of issue. At any rate, it seems like I don't need that extension anymore nowadays, so I've disabled it and things are good.

This is reproducible in phan demo, and it's a known limitation. Phan does not track context-based restrictions on the union type of a property, except for property of $this. So, in your example, when the doSubStuff call is encountered, phan reads the type of the argument ($w->stuff) from the property declaration, which is nullable, and does not remember about the conditional right above. That would only be done if $stuff were a property of the current class, like in this demo. I think there's a task upstream but I can't find it; I only found a mention in https://github.com/phan/phan/issues/4611#issuecomment-968352849.

Participant questions are enabled everywhere and cannot be turned off. Is there something in particular that isn't working?

I agree -- I was sort of hinting that in my comment above («similar to the subpage navigation menu»), but I wasn't quite sure what that might look like in practice, so I didn't expand on it. One thing to keep in mind with standard subpages is that you can have an arbitrarily (?) large number of levels, and presumably that wouldn't work well with buttons, as they take up a lot of space. Still, it makes a lot of sense to somehow reuse the same logic, as we're really talking about almost identical flows.

In T310700#9867871, @JScherer-WMF wrote:

Thanks for this @Daimona! Could you add it to the Web-Team-Backlog [...]

In T365859#9863006, @gonyeahialam wrote:

@MHorsey-WMF @Daimona How do we currently handle ongoing events with closed registration? Do we still show them in the list?

In T363863#9856638, @vaughnwalters wrote:

One question @Daimona if I am on Special:AllEvents and I click on an event that is in a different wiki than the one that I am on, it will take me to the Event page on the correct wiki. But if I click on the link for the remaining organizers that should be hyperlinked to the event details page, it will take me to the event details page on the wiki that I am viewing Special:AllEvents. I think this should also take me to the correct wiki of the event.

In T365859#9856073, @gonyeahialam wrote:

To make all information about dates clear, I have made a few changes: [...]

In T366462#9856014, @Ragesoss wrote:

@Daimona yes, that sounds correct. The Dashboard should not allow changing the name (including the 'When' component) of a course after it has been connected to Event Registration. I will file an issue to make sure we get that fixed.

I see. Here's my understanding of what happened.

They created an event page and attached the PE dashboard link in the process of enabling registration.

I think "a few minutes" should work too.

In T363863#9849744, @gonyeahialam wrote:

In T363863#9831293, @Daimona wrote:

@gonyeahialam One question from T364606#9831082: should the meeting type and organizers always be on separate lines, even when there's just an organizer?

If we can easily make it responsive, yes

In T363022#9844069, @Isaac wrote:

Ok, I got a chance to take a look. Thanks to @Daimona for the very well-documented code and function graphs, @Iflorez for your notes, and @ifried for the excellent Meta overview -- this made my job far simpler! Broad feedback:

In T362897#9841785, @cmelo wrote:

Regarding the use of JSON blobs or structured storage, I think data analysis is something we want, based on what was shared about aggregate analytics, in order to be able to create reports like the ones below that will also be seen by organizers, if I understood correctly:

In T50217#9844228, @aaron wrote:

It doesn't support the speed trap thing though.

In T366199#9843289, @ifried wrote:

Thanks for bringing this up, @Daimona! I was also wondering if "closed" made sense or if we wanted another status (such as "event ended")... or to simply hide the event status.

"Closed" and "ended" are two separate concept, one is a status you can set explicitly, the other is a consequence of the event end date.

In T362897#9840362, @cmelo wrote:

• cewa_id: ID links the user to the article of the worklist

Would this be useful? Without an indication of how strong the link is (i.e., how much someone has contributed to a given article), we probably wouldn't want to use this for analytics purposes or anything.

I think this may be useful to get data like:

• Which articles retuned this user
• This user is present in how many articles on my worklist

Note that the bug is currently not reproducible with the event linked in the task description, because it has ended.

In T365873#9831288, @Astinson wrote:

So in theory you could do this with Javascript using: https://www.mediawiki.org/wiki/Template_gadgets

In T364606#9831082, @vaughnwalters wrote:

@MHorsey-WMF the figma file linked in the task description has the Meeting type and Organizer on separate lines. I think the spacing issues that existed between Meeting type and Organizer might just be solved by a different layout now?

@gonyeahialam One question from T364606#9831082: should the meeting type and organizers always be on separate lines, even when there's just an organizer?

I think we need to be clear on what we want to expose exactly. APIs in the usual sense can only be accessed via HTTP(S), so you could use them in a JS gadget, but not in a lua module. Exposing this kind of list in Lua might be doable but needs to be thought out carefully. If the goal is to let people make their own event lists, we could make Special:AllEvents transcludable instead, and allow filtering via parameters passed in the transclusion.

I've reviewed the schema again given all the conversations that happened recently, but I still feel like there's a lot I don't know and/or we haven't talked about and that makes it difficult to tell whether something would work.

Patch above has been merged, but tagged with the parent task.

@vaughnwalters This can only be tested locally by running php maintenance/run.php CampaignEvents:GenerateInvitationList. The limits on the number of articles and users should be easy to test. The one for the number of revisions would be harder, but I don't think it needs to be tested for specifically.