In T310207#8035516, @Daimona wrote:

I just realized that it wouldn't be possible to close a registration whose event page is on another wiki from the special page (you'd have to visit Special:EditEvent on the other wiki). I've created T311582 to track that, and I propose not to do that for V0. So for V0 the user flow would be:

• Click "close registration"
• User is brought to Special:EditEvent
• They see an error informing them that the registration must be edited on another wiki (the error includes the wiki name)
• They can the browse to Special:EditEvent on the other wiki to make the change

There's a lot of space for improvements here, but we can't do much better for V0 given the time constraints. @ifried What do you think?

In T308574#8029404, @ifried wrote:

@cmelo Would adding user_name column to the ce_participants be a separate ticket, and do you imagine it would be a large amount of work? If yes, perhaps we can estimate it separately and it can be worked on shortly after other V0 tickets are completed. If it's a smaller amount of work, we can see if we can include it in V0. I'll await engineering input before we consider next steps.

There is an issue to display the Date and time as is it on the wireframes, I am sending below the link with the format options we have available at the moment:
https://www.mediawiki.org/wiki/Manual:WfTimestamp#:~:text=wfTimestamp()%20(part%20of%20GlobalFunctions,RFC%202822%20format%20and%20more.

We just find a blocker on how to implement the search on the participants list, as we do not save the user_name on the ce_participants table on our central database (just the user id), we don't have a way to filter by username, adding a user_name column to the ce_participants seems to be the best option for the moment to solve this. The feasible options we have at the moment in my opinion seems to be:

• Add a user_name column to the ce_participants
• Remove this feature from V0 and check later if there is a better way to do it.

Hi there @gonyeahialam, @ifried, @vyuen, @Daimona this is the task we discuss last sprint planning, about how are we going to handle the "Back" links, please let me know if the description provided is enough for us to decide what to do.

In T308574#7993532, @Daimona wrote:

In T308574#7992451, @cmelo wrote:

Thanks @Daimona, I am adding the (h1) element manually

Right, but technically that is not the "page title" that MW core defines as such, and I'm wondering if there could be issues with that. I really don't know if there are going to problems in practice. One thing we could do is put the link below the title for now and then, for the long term, patch MW core so that it's possible to add a backlink above the page title.

Changes done, I also change some other error messages that also uses 'Physical' instead of 'In person'
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CampaignEvents/+/804447/2/i18n/en.json

In T308574#7990825, @Daimona wrote:

In T308574#7990250, @cmelo wrote:

@Daimona, I was able to do option one by hiding the default header of the page, because the page title is added by default even if I don't pass any text for that, so I added this css to hide the h1 element because if not it will add a border on the page. Do you think this can be a problem?

Wouldn't this result in a page without a title (h1) element? I believe the rendering of the h1 element is up to each skin, and it may be modified in the process, so I'm unsure what would happen if we pass a bogus title. In general, if MW does not let us suppress the page title, I don't know if it's a good idea to forcibly hide it.

Hi @gonyeahialam, I was able to make it looks more like the wireframes, I am adding screenshots of the old and new vector with two option:

In T308574#7985021, @gonyeahialam wrote:

@cmelo We can use the search on the fly for JS and search with a button for no-JS.

Hi @ifried, @gonyeahialam, @Daimona, @vyuen, I was wondering if we should add a search button, rr it should be like: After type at least 3 characters, we apply the search?
I am asking this because if we add the button, it will work for noJS users.

This was created by mistake, it is the same as the subtask below:
https://phabricator.wikimedia.org/T309981

In T308280#7951537, @Daimona wrote:

In T308280#7951314, @cmelo wrote:

This is the link of our schema:
https://app.dbdesigner.net/designer/schema/0-untitled-4bdd90b6-afb6-45ff-b6af-f0bac3537e85

I'd rather not use that link because it's outdated. Now that it exists, I believe that the JSON file should be the ultimate source of truth.

I think we should add timestamps for the ce_organizers table, like:

• created_at
• updated_at
• deleted_at

This can be useful on v1 when we add the feature to add and remove organizers.

If we plan to use this information, yes.

HI @ifried thanks, yes I agree we should work on the "delete registration special page".
What do you think @Daimona?

Hi all, this is the link of the new spreadsheet with the fields we currently have for V0, I added some references to where the data will be displayed, so we can check on the wireframes if we are missing some data, it is on the column called "Where do we use this data?":
https://docs.google.com/spreadsheets/d/1nY5ITmFLzFeeh1CUbaCR66rZ3xHV-PuCm6okuaDNQAg/edit#gid=0

In T306014#7851129, @Daimona wrote:

In T306014#7850860, @gonyeahialam wrote:

@Daimona seems you had some concerns earlier with this?

The only concern I have is that we should not pre-generate the link; instead, there should be a button to generate the link, and when that is clicked, we do generate the link and provide another button to copy it. There are mainly two reasons for this:

1. Depending on how often people would use short links, we may end up creating short links that are rarely used, thus wasting space
2. The process of generating a short link is tied to the user performing the action; this is used e.g. to prevent blocked users from creating short links, and for rate limiting. We cannot do that without asking the user first.

These are really good points, I totally agree, thanks Emanuele.

Hi there, I remember we decided to create a separate task to add the actions to the menu, and I also don't think they would be difficult to implement, and I think they are important features for V0.

I think we should do it different, we could redirect the user to the wiki of the event page, this way we do not need to worry about interwiki, would be something like:

For V0 we will save have just the country and a free text for the event address.

We decide to deploy it to Patchdemo and to beta cluster.

In T304843#7867828, @cmelo wrote:

In T304843#7824377, @Daimona wrote:

One thing I'd like to point out. While it's not a hard dependency, our extension uses CentralAuth quite a bit for global user data. Hence, if we want to build an environment that resembles what we'll have in production, we don't just need a single wiki, we need a wiki farm with CentralAuth. This is already the case for the beta cluster, and while it should be entirely possible to do that in a custom VPS instance, it could take some time to get everything working. Patchdemo, OTOH, does not support wiki farms at all, AFAICS.

Thanks Emanuele, I agree, I am checking VPC and toolforge options, and it seems that they are not a good option for what we need.

In T304843#7824377, @Daimona wrote:

One thing I'd like to point out. While it's not a hard dependency, our extension uses CentralAuth quite a bit for global user data. Hence, if we want to build an environment that resembles what we'll have in production, we don't just need a single wiki, we need a wiki farm with CentralAuth. This is already the case for the beta cluster, and while it should be entirely possible to do that in a custom VPS instance, it could take some time to get everything working. Patchdemo, OTOH, does not support wiki farms at all, AFAICS.

This is great, thank you so much @Ragesoss

Hi @gonyeahialam, thanks for the information provided.

Hi @Nananadia93, I am sorry I don't if I got it, what do you mean by section?

Hi @Daimona, thanks, I agree, since seems that this will be provided in the future, I am ok by using a hard limit for now on the API side.

Talking to Bryan he shared with me some useful information on how we can request for a "New VPC project" I am taking a look at it.

In T303642#7800289, @Daimona wrote:

In T303642#7799720, @cmelo wrote:

In T303642#7796784, @Daimona wrote:

The user must be soft deleted

Oh, I didn't notice this. @cmelo do we need soft deletion for V0? The schema we created doesn't seem to support that.

Hi @Daimona, yes we need to create a new field into the database, I think it should be a deleted_at (timestamp)

That's a good point, but is it needed?. @ifried do we need to know when a participant has unregistered from an event?

I will have a meeting with Stephane next week to try pathcdemo.

For the "Connect with other organizer" I was wondering if we have the users location/address available, since this seems to be PII and we would need this information to calculate the distance from one user to another.
Also I am not sure, but it could impact performance, because we would need to get the location of all the organizers, and calculate the distance of each one, to get the list of organizers near the user.

Implementing our own messaging system will be really a huge work.
I am curious to know more about "Distribution List" and "Social Media"

• I also think that the menu should not be on the left side.
• On the calendar, I was wondering if we will allow the user to select only the actual month or they will be able to see the next/previous months?
• What is the participants documentation, that the organizer will be able to send?

• I like how it looks like!
• What is "Gold contributor"?
• I agree with Vanessa that would be better to change the labels from "Organizer/Participant" to "Organizing/Participating" on the events.
• I would like to point out that any SPA features may not be possible to implement because we need to refresh the page almost each time a user does an action, so for example
  • if the user select an option on the select input filter it will not automatically filter, we would need a "Filter" button so the user can click on it and the entire page will be reloaded

I like option 1.

In T303642#7796784, @Daimona wrote:

The user must be soft deleted

Oh, I didn't notice this. @cmelo do we need soft deletion for V0? The schema we created doesn't seem to support that.

In T303639#7799673, @Daimona wrote:

Thinking about this again, I agree with the comments above. However, number of seats or automatic closing are not V0, so for now I'd stick with disallowing the unregistration only if the event has ended (but not if it's closed). What do y'all think?

In T303718#7794247, @Daimona wrote:

@cmelo To confirm, are we talking about a new database field (e.g. event_deleted ∈ {0, 1}), or changing the status of the registration (i.e. event_status)? And if it's the former, do we need it for V0?

https://www.mediawiki.org/wiki/Extension:CampaignEvents/Api#Edit_an_event_registration

Thanks for the context Emanuele, I also prefer option 1, and I am working on this, thank you!

In T301692#7788656, @Daimona wrote:

In T301692#7788647, @gonyeahialam wrote:

• Icons in the text fields (URL and address): are they important?
  • Engineering notes: This is currently not possible, but the needed core change should be relatively easy to write, so we can do that if design thinks this is important for V0.

• Design answer: Icons are especially important for the input fields that do not have labels on top (URL and Address).

Note that these fields do have labels. I guess it may be possible to remove the labels, but I think that's bad for accessibility.

Hi @Daimona, yes I agree with you, the participant can not register in this two cases.

I think the site map is really good and easy to understand, I also like option 1 better.