In T364353#9813629, @VPuffetMichel wrote:

Then it seems useful for an organizer to create events and hide them until they are ready to show them to everyone. (a different twist on the "draft" proposal Emanuele mentions above)

In T364353#9813496, @VPuffetMichel wrote:

We should probably not use a live wiki for testing events moving forward. It adds complexity like what we are dealing with in this task.

In T356679#9812384, @gonyeahialam wrote:

This looks good, the only challenge is that users will enter the same information twice.

In T356679#9810015, @ifried wrote:

For the MVP, could we then have the following 2 fields:

• Event name (required, whether or not there is an event page on the wiki)
• Event page (optional, and only for those events that have an event page on the wiki)

This way, we can get the event name to use in Special:MyInvitationLists, but we would simplify the process of asking for the specific event page by restricting it to event pages on the wiki for MVP. If we would want to collect the URLs of event pages off the wikis in the future, we could consider it, post-MVP, but it is of probably limited value, so it would not need to be considered for the MVP. Let me know if this sounds good/makes sense!

In T363865#9810121, @vaughnwalters wrote:

Thinking about this more - I see what you mean and see how this is working as expected. It is def confusing to me though.

In T363865#9809658, @vaughnwalters wrote:

If I search from May 17 2024 , then dates that start after that date display in the list. For example, test events starting in 2099 April 12 will display in the list and they should be filtered out.

In T356679#9806282, @ifried wrote:

• 1 field for event name of event and 1 for URL?

In T355128#9809125, @gonyeahialam wrote:

Following the default would look like this, which we can go with:
Design specs

There is no endpoint at the moment, so we would have to create one first.

@vaughnwalters Just a quick note from working on T365181: I would recommend testing pagination thoroughly (number of pages, first/prev/next/last page, no duplicated or skipped results, ...). I've done some testing for that patch, but there's a decent change I may have missed something because the whole thing is quite tricky.

Seems like two of the errors have fixed themselves in the meantime, and only the last one remains:

In T363863#9801366, @gonyeahialam wrote:

Latest Design
Show a max of 2 organizers and show the number of remaining organizers not shown. Can wrap to the next line if the usernames are long.

Decision from today's design + engineering meeting: we will use the same spacing (@spacing-125 = 20px) on both desktop and mobile between the day and the rest of the card, to avoid excessive blank space as can be seen in F51815230 and F51815313.

Hm. I would like to add real type hints to WikiMap and related class, because there are a lot of methods that are documented to only accept string, but don't have a type hint, and therefore their failure states may not be obvious. This is an example of that. Interestingly though, this warning is only emitted in PHP 7.4: starting with PHP 8, array_key_exists accepts more types than just string for its first parameter. I looked at a bunch of methods that could end up being called when WikiMap::getWiki is called across WikiMap, *SiteStore, and SiteConfiguration classes. They all seem to have one thing in common: the $wiki parameter is documented as a string, and the code only expects it to be a string. But yet, everything that those methods do with the wikiID parameter (array_key_exists, str_replace, string concatenation, array offset access, etc.) seems to work just fine with a boolean, as PHP just does some type juggling and doesn't emit any notices. There's nothing I could find that would throw an error or even emit a notice (at least in PHP 8.1), and the implicit cast from false to '' probably doesn't alter the correctness of the code. All in all, this means I didn't find any strong enough reason to add type hints, and that I'll stick with the CampaignEvents fix for now.

Yeah, just to clarify, my comment was only in response to the switch from WebRequest to Session. But indeed, it does not address the bug above, which seems to be due to the order of execution.

Alternatively, would it be possible to set a static flag in one of the ConfirmEdit classes? In theory, it doesn't even need to be static as long as the class in question is obtained through the service container. Something like AbuseFilter's own EditRevUpdater::$logIds. Another thing is that this could live all within the ConfirmEdit extension, and the property might be read in triggersCaptcha directly, without using a hook.

In T356508#9793132, @cmelo wrote:

I did a bunch of tests using the Sitematrix API, and other related APIs I found to get the list of wikis, here are my findings:

Now ready for a final round of QA, just making sure that there are no regressions related to database access in a multi-wiki setup.

In T348281#9790527, @Jdforrester-WMF wrote:

In T348281#9714738, @Daimona wrote:

This should be ready now, the only thing left to do is the deployment of the two remaining config changes. I'm removing myself as assignee as I'll be OOO for the rest of the week and most of next week.

Anything I can do to help move this along? Would be lovely to have T343098's tree closed.

In T361029#9790519, @gonyeahialam wrote:

Re option 2: usernames are typically user page links. Also, I think the original request was to add user talk and contribs links; those could use the standard user tool links format

@Daimona Something like this?

In T364695#9788686, @Volker_E wrote:

While I see the WCAG guidelines as guiding principles, as in 4.49:1 vs 4.5:1 is not a fail in my opinion, I assume that we could change the color slightly to also make automated tests not chew up on this every time it's encountered. cc: @DTorsani-WMF

(We discussed this a couple days ago. Another option to explore is using the main stash to store JSON blobs instead of having a dedicated schema. Semi-persistence should be fine, as the invitation lists are not critical, and are only relevant for a short period of time anyway. There might be a few technical details to hash out though, such as any size limits, and whether the main stash would be suitable in general.)

In T361029#9780822, @gonyeahialam wrote:

So these are my design options to improve the invitation list management, with a preference for Option 1 for the MVP.

Option 1	Option2
Combination of Idea 1 and 2a	Combination of Idea 1 and 2b

In T364353#9779353, @ifried wrote:

@Daimona Thanks for providing this feedback! This is helpful. Can you explain a bit more about how the new status could work? I'm a bit confused by this. Thanks!

In T361029#9779124, @gonyeahialam wrote:

What other forms? Almost every other form we have has post-submit validation, the main exception being the "Message participants" feature.

@Daimona I am referring to showing a warning message post validation. It is only error messages we do this for. Warning messages do not prevent form submission.

In T361029#9778918, @gonyeahialam wrote:

The standard input field for pages takes the page name, not the URL

Are you referring to the Event page URL? You mean you can just input the page name instead of the URL. If so, would it work for pages of different namespaces (e.g event pages not in the Event names space)

This could be way harder than it sounds, basically boiling down to the question of how to detect a test event in a robust way (that doesn't depend on language or project conventions). It could maybe be generalized to a new status (in addition to "open" and "closed") which, when set, has the effect of excluding an event from AllEvents and similar lists.

In T361029#9768968, @gonyeahialam wrote:

Current design

Fixed by r1023884?

In T363906#9765595, @Tchanders wrote:

This could be captured by changing af_hidden from a bool to a bitfield, and should be fairly backwards compatible if public=0 and private=1.

Since we now have follow-up tasks for all of the above, and those tasks have been discussed and prioritized, should we close this task here?

• should use a new column, eg. af_protected that takes a running list of user rights which are required to view the filter/logs

Discussed today. Decision: we will work on this, but it is not considered a blocker. The idea is to show a limited number of organizers (maybe just 1), and then explicitly say that there are more organizers. Users can see the full list by opening the event. @gonyeahialam to explore design options.

Discussed today. Decisions: we will do this now, before widely sharing the event list page. We will consider adding an inline notice to ongoing events in the UI, and possibly a way for users to filter them out. However, that will be done in another task and is not considered a blocker.

Discussed today, see notes at T363867#9763832.

Discussed today at backlog refinement. Decision: we are not considering this a blocker for the time being. We will need to do more research and decide if we actually want to do this and how. Some options we considered:

• Show the time zone but not the time (using the event time zone)
• Show time + time zone using the same rule as EventDetails (online -> user time zone, in-person -> event time zone). Problem: it might be confusing.
• Show time + time zone using the user time zone everywhere. Do not display the time zone for each event. Just display it once, maybe as a form field.

This very much is a real problem, and the proposed solution is T277470: Ignore (most) of LocalSettings.php when running PHPUnit (fix surprise test failures). I think that would be pretty much equivalent to this task here, so maybe it can be closed as duplicate?

In T355128#9719899, @vaughnwalters wrote:

1. The div with id="StatsPanel" should not have 20px of padding on the left. It should instead be left aligned with the menu bar above it.

In T361029#9758051, @gonyeahialam wrote:

@Daimona What are the accepted ways to separate the article titles in the text input fields? Note: Some articles have commas in their names.

In T363284#9745832, @vaughnwalters wrote:

@zeljkofilipin The documentation that I mentioned in our meeting was for setting up a wikifarm, not explicitly setting up central auth. But check out this comment from @Daimona as I think it is what you will need to get central auth working.

In T363573#9748647, @Ladsgroup wrote:

We probably should actually fix the gitlab part before running it again

Lol, my first conflict in gitlab.