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.