In T339979#9006841, @ifried wrote:

Two notes, after discussing this ticket with @Daimona:

• This restriction only applies to scenarios in which participants have registered for an event. If no participants have registered for the event, there is no restriction on changing the end date of an event that has already ended. I have updated the AC with this information.
• I think the current language displayed to users is a bit confusing. I would recommend the following rewriting of the text, and I want to know what other people think of the proposed changes (i.e., is the language more clear?):
  • "If you change the end date to a past date, the event will be closed and you will receive a summary of participant responses. This action cannot be undone."
  • "The event date and time cannot be changed in order to protect participant data."

SGTM

cc @gonyeahialam since you wrote the original language, what do you think of my proposed changes? Do they look good to you? I tried to simplify the text (see my comment above) so it is easier for users to understand, but I want to make sure that I am not missing any context.

I see that Gregory shared his comments above, so the language is finalized and will be added to the AC.

Change 941858 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Implement restriction of not being able to change the end date of events

https://gerrit.wikimedia.org/r/941858

Change 943572 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Implement restriction of not being able to change the end date of events backend

https://gerrit.wikimedia.org/r/943572

Change 946923 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Introduce class EventAggregatedAnswersStore

https://gerrit.wikimedia.org/r/946923

Change 946923 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Introduce class EventAggregatedAnswersStore

https://gerrit.wikimedia.org/r/946923

Hi @gonyeahialam I am finishing the implementation of this task, and I remember that we decided on one of our design sync engineering meeting to change the text below:

If you change the end date to a past date, the event will be closed, and you will receive a summary of participant responses. This action cannot be undone.

To:
If you change the end date to a past date, the event will be closed and you will receive a summary of participant responses. This action cannot be undone. This is only applicable if participants have provided answers to the participant questions.

is it accurate?

In T339979#9104871, @cmelo wrote:

Hi @gonyeahialam I am finishing the implementation of this task, and I remember that we decided on one of our design sync engineering meeting to change the text below:

If you change the end date to a past date, the event will be closed, and you will receive a summary of participant responses. This action cannot be undone.

To:
If you change the end date to a past date, the event will be closed, and you will receive a summary of participant responses. This action cannot be undone. This is only applicable if participants have provided answers to the participant questions.

is it accurate?

Yes.
Is there any reason why you bolded some parts of the warning? I believe warning messages are bold by default.

In T339979#9106591, @gonyeahialam wrote:

In T339979#9104871, @cmelo wrote:

Hi @gonyeahialam I am finishing the implementation of this task, and I remember that we decided on one of our design sync engineering meeting to change the text below:

If you change the end date to a past date, the event will be closed, and you will receive a summary of participant responses. This action cannot be undone.

To:
If you change the end date to a past date, the event will be closed and you will receive a summary of participant responses. This action cannot be undone. This is only applicable if participants have provided answers to the participant questions.

is it accurate?

Yes.
Is there any reason why you bolded some parts of the warning? I believe warning messages are bold by default.

Thanks @gonyeahialam, I just bold some parts of it to be more clear here on phab what is the change on the message, I will remove it to avoid any missunderstanding.

Change 951169 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add new TimeFieldsEnhancer to handle time fields

https://gerrit.wikimedia.org/r/951169

Given the new acceptance criteria:
Organizers can change the start and end date of an event to be a date in the past after the event ends, but they cannot change it to be a date in the future after the event ends

We are no longer disabling the date fields anymore, but we will still show an error message in case the organizer tries to change the end date to be in the future.

This also means that we no longer need this message, or should change its text to inform that:
The end event date end time cannot be changed to a date in the future .... :

@gonyeahialam could you update the prototypes to reflect it please, thank you!

In T339979#9165859, @cmelo wrote:

Given the new acceptance criteria:
Organizers can change the start and end date of an event to be a date in the past after the event ends, but they cannot change it to be a date in the future after the event ends

We are no longer disabling the date fields anymore, but we will still show an error message in case the organizer tries to change the end date to be in the future.

This also means that we no longer need this message, or should change its text to inform that:
The end event date end time cannot be changed to a date in the future .... :

@gonyeahialam could you update the prototypes to reflect it please, thank you!

I would do that @cmelo. Where can I read the details/rationale behind this decision? This will help me craft the error message.
Also, the 2nd and last AC bullet points seem to be contradicting each other. I think the 2nd AC should be removed.
2nd AC: Organisers would be prevented from changing the event date of an event that has already ended
Last AC: Organizers can change the start and end date of an event to be a date in the past after the event ends, but they cannot change it to be a date in the future after the event ends

In T339979#9169451, @gonyeahialam wrote:

In T339979#9165859, @cmelo wrote:

Given the new acceptance criteria:
Organizers can change the start and end date of an event to be a date in the past after the event ends, but they cannot change it to be a date in the future after the event ends

We are no longer disabling the date fields anymore, but we will still show an error message in case the organizer tries to change the end date to be in the future.

This also means that we no longer need this message, or should change its text to inform that:
The end event date end time cannot be changed to a date in the future .... :

@gonyeahialam could you update the prototypes to reflect it please, thank you!

I would do that @cmelo. Where can I read the details/rationale behind this decision? This will help me craft the error message.
Also, the 2nd and last AC bullet points seem to be contradicting each other. I think the 2nd AC should be removed.
2nd AC: Organisers would be prevented from changing the event date of an event that has already ended
Last AC: Organizers can change the start and end date of an event to be a date in the past after the event ends, but they cannot change it to be a date in the future after the event ends

Thanks @gonyeahialam, I updated the AC, so this decision is based on the assumptions below:

• Organizers should not be blocked from changing dates to past, since this is not an issue for protecting PII
• Organizers may need to set past dates if an event occurs earlier than planned, and they forgot to update the registration dates

@cmelo

Here is the new error message copy:
"Past event dates can't be updated to the future to ensure participant data safety."

@gonyeahialam & @cmelo, what do you think of the following update to the copy (see below). Do you think it's a bit more clear to readers? Let me know what you think!

"Past event dates cannot be updated to a future date in order to protect participant data."

In T339979#9175099, @ifried wrote:

@gonyeahialam & @cmelo, what do you think of the following update to the copy (see below). Do you think it's a bit more clear to readers? Let me know what you think!

"Past event dates cannot be updated to a future date in order to protect participant data."

This appears more verbose and longer.

Yeah, I hear you, @gonyeahialam. I was basically trying to do a few things to improve the sentence, which were:

• change from "can't" to "cannot" (since "can't" is a bit informal)
• change from "the future" to "future date," since I thought it was a bit more clear
• change "ensure participant data safety" to "protect participant data" since I found it a bit more accurate & clear

Do you agree with any of the choices I made above?

If yes, what do you think of this rewritten version (see below)?:

"Past event dates cannot be changed to future dates to protect participant data."

In T339979#9180881, @ifried wrote:

Yeah, I hear you, @gonyeahialam. I was basically trying to do a few things to improve the sentence, which were:

• change from "can't" to "cannot" (since "can't" is a bit informal)
• change from "the future" to "future date," since I thought it was a bit more clear
• change "ensure participant data safety" to "protect participant data" since I found it a bit more accurate & clear

Do you agree with any of the choices I made above?

If yes, what do you think of this rewritten version (see below)?:

"Past event dates cannot be changed to future dates to protect participant data."

Yes. This is better. It combines the strengths of the two above.

In T339979#9181903, @gonyeahialam wrote:

In T339979#9180881, @ifried wrote:

Yeah, I hear you, @gonyeahialam. I was basically trying to do a few things to improve the sentence, which were:

• change from "can't" to "cannot" (since "can't" is a bit informal)
• change from "the future" to "future date," since I thought it was a bit more clear
• change "ensure participant data safety" to "protect participant data" since I found it a bit more accurate & clear

Do you agree with any of the choices I made above?

If yes, what do you think of this rewritten version (see below)?:

"Past event dates cannot be changed to future dates to protect participant data."

Yes. This is better. It combines the strengths of the two above.

SGTM

@Daimona suggests we disable future dates in the calendar picker instead and show a notice message explaining why always. This prevents the user from making the error in the first place.

In T339979#9183092, @gonyeahialam wrote:

@Daimona suggests we disable future dates in the calendar picker instead and show a notice message explaining why always. This prevents the user from making the error in the first place.

My question is: If the user enters the dates directly without using the calendar picker what happens?
Perhaps we turn the notice into an error message.

In T339979#9183116, @gonyeahialam wrote:

In T339979#9183092, @gonyeahialam wrote:

@Daimona suggests we disable future dates in the calendar picker instead and show a notice message explaining why always. This prevents the user from making the error in the first place.

My question is: If the user enters the dates directly without using the calendar picker what happens?
Perhaps we turn the notice into an error message.

In that case, the field outline becomes red. If you try and submit the form, you get a predefined error message. This can be tested on beta by manually entering a date in the past (the only difference is in the wording of the error message when the date is in the past vs future). I'm not sure if we would be able to replace the predefined error message in this scenario. Maybe we could have our notice remain a notice, in addition to the predefined error?

In T339979#9184328, @Daimona wrote:

In T339979#9183116, @gonyeahialam wrote:

In T339979#9183092, @gonyeahialam wrote:

@Daimona suggests we disable future dates in the calendar picker instead and show a notice message explaining why always. This prevents the user from making the error in the first place.

My question is: If the user enters the dates directly without using the calendar picker what happens?
Perhaps we turn the notice into an error message.

In that case, the field outline becomes red. If you try and submit the form, you get a predefined error message. This can be tested on beta by manually entering a date in the past (the only difference is in the wording of the error message when the date is in the past vs future). I'm not sure if we would be able to replace the predefined error message in this scenario. Maybe we could have our notice remain a notice, in addition to the predefined error?

If the field becomes red without a corresponding error message it will not be clear why it turned red. That's why I suggest we show an inline error message. We don't need to wait till form submission to show an error message since we already know that there is an error beforehand.

In T339979#9188099, @gonyeahialam wrote:

In T339979#9184328, @Daimona wrote:

In T339979#9183116, @gonyeahialam wrote:

In T339979#9183092, @gonyeahialam wrote:

@Daimona suggests we disable future dates in the calendar picker instead and show a notice message explaining why always. This prevents the user from making the error in the first place.

My question is: If the user enters the dates directly without using the calendar picker what happens?
Perhaps we turn the notice into an error message.

In that case, the field outline becomes red. If you try and submit the form, you get a predefined error message. This can be tested on beta by manually entering a date in the past (the only difference is in the wording of the error message when the date is in the past vs future). I'm not sure if we would be able to replace the predefined error message in this scenario. Maybe we could have our notice remain a notice, in addition to the predefined error?

If the field becomes red without a corresponding error message it will not be clear why it turned red. That's why I suggest we show an inline error message. We don't need to wait till form submission to show an error message since we already know that there is an error beforehand.

But it will show an error message: the predefined one defined by the date widget. And we would also show the "Past event dates cannot be changed ..." notice next to it. I guess what I was saying is, maybe we don't need to turn the notice into an error if the field already has the predefined error message.

@Daimona The predefined error message shows when you submit the form and not when the field turns red immediately after you enter a future date.
Also, the pre-defined error message is for when you input an earlier date. I don't think there is one for when you input a future date

In T339979#9188410, @gonyeahialam wrote:

@Daimona The predefined error message shows when you submit the form and not when the field turns red immediately after you enter a future date.

Yes, you're right, and I think showing the message immediately could be a potential improvement for MW core's date widget. However, given that:

• We already have an error message showing (after you submit the form)
• You already see a notice informing you that future dates cannot be selected
• You have to enter the date manually for this scenario to happen
• The field turns red
• It may not be easy to turn the notice into an error

Could we just leave it as a notice for now, to keep things simpler?

Also, the pre-defined error message is for when you input an earlier date. I don't think there is one for when you input a future date

There is one:

In T339979#9188485, @Daimona wrote:

In T339979#9188410, @gonyeahialam wrote:

@Daimona The predefined error message shows when you submit the form and not when the field turns red immediately after you enter a future date.

Yes, you're right, and I think showing the message immediately could be a potential improvement for MW core's date widget. However, given that:

• We already have an error message showing (after you submit the form)
• You already see a notice informing you that future dates cannot be selected
• You have to enter the date manually for this scenario to happen
• The field turns red
• It may not be easy to turn the notice into an error

Could we just leave it as a notice for now, to keep things simpler?

Also, the pre-defined error message is for when you input an earlier date. I don't think there is one for when you input a future date

There is one:

Okay, we can work with this.
Is the current copy the default copy or did you write it?

In T339979#9191852, @gonyeahialam wrote:

Okay, we can work with this.
Is the current copy the default copy or did you write it?

That is the "default" error message used by the date widget. I put "default" in quotes because we can't really change it AFAICT.

Change 943572 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Implement restriction of not being able to change the end date of events backend

https://gerrit.wikimedia.org/r/943572

@ifried @cmelo @VPuffetMichel Sorry, but as I was reviewing this patch I found myself staring at the AC multiple times and I'm still not sure if I understood them correctly. Given the time already spent on it, I want to make sure the AC are clarified ASAP before they cause more troubles (e.g., in QA). Here are a couple ambiguities I spotted:

Organizers can change the start and end date of an event to be a date in the past after the event ends, but they cannot change it to be a date in the future after the event ends

What do "past" and "future" refer to? The current time, or the current end date of the event? I'm assuming the former, but this has confused me in code review, and I think @cmelo was confused too because it took a while for the both of us to notice that the implementation was assuming different meanings in different places.

To clarify, this is about the following scenario. Suppose I have an event that ended on September 10, and today is September 26. Then:

• We all agree that I'm not allowed to change the end date to be September 27 (i.e., after the current time).
• We also agree that I can set it to September 5 (i.e., before the current end date).
• But can I set it to September 20, i.e., in the future relative to the current end date, but in the past relative to the current date?

Again, we believe that the answer to the last question should be yes, but it would be nice to state this explicitly.

The text for the first message below should be shown even if there are no participants or no answers for the event.

First, I want to confirm that this refers to the «If you change the end date to a past date» text, given that "first below" is a highly volatile concept when the task description gets rewritten a bunch of times.

Second: why is this the case? The message clearly states «This is only applicable if ...», and that's how it works in practice, i.e., the action can be undone if there are no answers. Then why are we always showing this message? The lack of a written rationale makes me wonder if this part of the AC is outdated or something like that.

Last but not least: I personally do not feel 100% confident approving this patch, because I'm not confident that I understand all the AC (and that I can therefore verify if they are met). Combining this with the above, I guess my final question would be: can we please rewrite the AC in gherkin? I feel there's too much complexity in this task for it to have unstructured and vague AC.

Change 962065 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] editeventregistration: Move code from index.js to TimeFieldsEnhancer.js

https://gerrit.wikimedia.org/r/962065

Second: why is this the case? The message clearly states «This is only applicable if ...», and that's how it works in practice, i.e., the action can be undone if there are no answers. Then why are we always showing this message? The lack of a written rationale makes me wonder if this part of the AC is outdated or something like that.

We decided to always show the message because a participant can answers a question in the meantime the organizer clicks on edit.

I mean, the organizer wants to change the end date to be today:
the organizer choose today's date, if we do not show the message and let's say the organize leaves for a coffee or something (of course this is an edge case), and in the meantime a participant answers a question, than the organizer clicks on edit, this means the organizer will not be able to do it again because now there is one answer, but the organizer was not aware of that.

I am not saying that we should or not always show it, but just pointing why we took the decision to always show it.

In T339979#9211735, @cmelo wrote:

Second: why is this the case? The message clearly states «This is only applicable if ...», and that's how it works in practice, i.e., the action can be undone if there are no answers. Then why are we always showing this message? The lack of a written rationale makes me wonder if this part of the AC is outdated or something like that.

We decided to always show the message because a participant can answers a question in the meantime the organizer clicks on edit.

OK, I see, it is indeed an edge case but it makes sense.

I am not saying that we should or not always show it, but just pointing why we took the decision to always show it.

Yup, just to be clear, I'm not saying that we should change the AC. It's just that the lack of a rationale did not make it clear whether this was intentional or just a leftover.

Hey @Daimona & @cmelo,

Yup, this is easily confusing! Here are some notes:

• The "past" and "future" should be in relation to the current time.It can sometimes be in relation to both the current time and current event end date (but not in all scenarios). I provide further explanation below:
  • Scenario 1 - during the event: Let's say today is October 5, and the event will end in October 10. The organizer tries to change the event to end on October 4. This is the past in relation to the current date and the end date of the event, and this action would trigger the first message ("If you change the end date to a past date...").
  • Scenario 2 - after the event: Let's say today is October 20 and an event ended on October 10. The organizer tries to change the event end date to October 30. This date is both a future date in relation to the end of the event and the current date. However, the reason it is a problem to make the change is because October 30 is in the future in relation to the current date. If the organizer tried to change the end date to a date that is in the future in relation to the end of the event but not in relation to the current date (for example, to October 15), this would not be a problem, since the event would still have ended, so registration would be closed and no new participant data could be collected as a result.
• I think this text is confusing, since "past" and "future" are not defined: "Past event dates cannot be changed to future dates to protect participant data." We can rewrite it to something like: "The event has ended, so you cannot change the event dates to future dates. This restriction protects participant data." This is lengthier, but perhaps more helpful in actually conveying the behavior to organizers. What do you all think? Curious to hear other opinions, especially from @gonyeahialam.
• You ask: "But can I set it to September 20, i.e., in the future relative to the current end date, but in the past relative to the current date?" In this scenario, yes, I think the organizer should be able to set the end date to September 20 when the current date is September 26. This is because registration would still be closed, so new people could not join and thereby change the participant data. Meanwhile, there may be valid reasons to change the date to a later date. For example, maybe the event did in fact go on longer and the organizer wants the contributions in the Dashboard to track the full period of the event. In this case, there is no likelihood of abuse (though correct me if I am missing something!).
• Sorry, I'm a little confused by what you mean when you say "first below." Can you clarify?
• Yes, the "This is only applicable if..." is always shown. I think the current text is okay for now, since it is also an edge case in general to want to change the end date to a past date (so this message should not come up very often for good actors).
• My day is ending, but I can work on rewriting the task in gherkin next week. Before I do, though, I want to hear your responses to what I wrote to ensure we are all on the same page.

In T339979#9212429, @ifried wrote:

• You ask: "But can I set it to September 20, i.e., in the future relative to the current end date, but in the past relative to the current date?" In this scenario, yes, I think the organizer should be able to set the end date to September 20 when the current date is September 26. This is because registration would still be closed, so new people could not join and thereby change the participant data. Meanwhile, there may be valid reasons to change the date to a later date. For example, maybe the event did in fact go on longer and the organizer wants the contributions in the Dashboard to track the full period of the event. In this case, there is no likelihood of abuse (though correct me if I am missing something!).

I agree, and that's how Claudio and I interpreted this AC.

• Sorry, I'm a little confused by what you mean when you say "first below." Can you clarify?

I was just referring to the following AC (emphasis mine):

The text for the first message below should be shown even if there are no participants or no answers for the event.

Given that the AC have been changed a few times, I just wanted to make sure that this sentence is still accurate.

• Yes, the "This is only applicable if..." is always shown. I think the current text is okay for now, since it is also an edge case in general to want to change the end date to a past date (so this message should not come up very often for good actors).

Sounds good to me. As I said above, what really matters to me is that the rationale for this is documented somewhere. Unsure if the AC are the best place for this, but I'd still rather have it in the task description so it doesn't get lost.

• My day is ending, but I can work on rewriting the task in gherkin next week. Before I do, though, I want to hear your responses to what I wrote to ensure we are all on the same page.

All you wrote sounds good to me, thank you! Also, no rush. And I don't think we need to be super formal in the AC definitions, but I believe the current AC are a bit confusing.

I think this text is confusing, since "past" and "future" are not defined: "Past event dates cannot be changed to future dates to protect participant data." We can rewrite it to something like: "The event has ended, so you cannot change the event dates to future dates. This restriction protects participant data." This is lengthier, but perhaps more helpful in actually conveying the behavior to organizers. What do you all think? Curious to hear other opinions, especially from @gonyeahialam.

@ifried
I agree with the updated copy

I have updated the AC to attempt at gherkin, but it is probably not perfect (or far from perfect!) gherkin. But hopefully it provides more clarity. Let me know, @Daimona.

Also, while the rewritten copy may be a bit more clear, and I see that Gregory has updated the prototype. But any updated copy would not be in the scope of this ticket, so I would need to write a new ticket. I don't think it is a high priority to update the copy since this is an edge case scenario, but we can perhaps think of doing it in a follow-up ticket if we have time.

In T339979#9232181, @ifried wrote:

I have updated the AC to attempt at gherkin, but it is probably not perfect (or far from perfect!) gherkin. But hopefully it provides more clarity. Let me know, @Daimona.

Thank you, much appreciated :) I'm sure this will be helpful because this way I can simply go through each line one by one. I'll let you know if I have any questions.

Also, while the rewritten copy may be a bit more clear, and I see that Gregory has updated the prototype. But any updated copy would not be in the scope of this ticket, so I would need to write a new ticket. I don't think it is a high priority to update the copy since this is an edge case scenario, but we can perhaps think of doing it in a follow-up ticket if we have time.

If we already have an agreed-upon copy, can it be made part of this task? If we use a message now but then change it soon after, it means translators will have pretty much wasted time on their first translation.

Ok, update to copy added to AC!

Change 962065 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] editeventregistration: Move code from index.js to TimeFieldsEnhancer.js

https://gerrit.wikimedia.org/r/962065

A small note about this AC:

• If I try change my event dates to a future date,
  • I receive an error message, which reads:
    • "The event has ended, so you cannot change the event dates to future dates. This restriction protects participant data."

and the related spec F37926073: that's not what was decided above. As per T339979#9191852 and previous comments, this message will be shown as a notice, and the actual error will be the predefined one. Like this:

(Note, the screenshot uses the older version of the copy, but that's not the point here)

Change 966580 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Update error message for changing dates of past events to the future

https://gerrit.wikimedia.org/r/966580

Change 966580 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Update error message for changing dates of past events to the future

https://gerrit.wikimedia.org/r/966580

Change 951169 abandoned by Cmelo:

[mediawiki/extensions/CampaignEvents@master] Add new TimeFieldsEnhancer to handle time fields

Reason:

work will be done on another patch

https://gerrit.wikimedia.org/r/951169

In T339979#9258973, @Daimona wrote:

A small note about this AC:

• If I try change my event dates to a future date,
  • I receive an error message, which reads:
    • "The event has ended, so you cannot change the event dates to future dates. This restriction protects participant data."

and the related spec F37926073: that's not what was decided above. As per T339979#9191852 and previous comments, this message will be shown as a notice, and the actual error will be the predefined one. Like this:

I've boldly gone ahead and updated the AC. I've also clarified another couple sentences.

Change 941858 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Implement restriction of not being able to change the end date of events

https://gerrit.wikimedia.org/r/941858

@vaughnwalters In addition to the AC, I would suggest testing this with different time zones (left and right of UTC), to make sure that the definition of "past" is consistent with that. I've tested it as best as I could but I might well have missed something.

• Given that I am an organizer,
  • and my event is ongoing or yet to begin,
  • and I am on the edit event page,
  • and if I try to change the end date to an event to a past date
    • ✅ I will see a message that warns me of what will happen, which reads:
      • ✅ "If you change the end date to a past date, the event will be closed and you will receive a summary of participant responses. This action cannot be undone. This is only applicable if participants have provided answers to the participant questions."
      • 
  • And if I proceed to make the change,
    • ✅ the change to the dates can be made
    • and if my event has participant responses,
      • ✅ then the "response statistics" tab should be shown
        • 
        • ❌ while it currently does display if there are participant responses, the "Response statistics" tab shows even if there are no participant responses.
        • 

• Given that I am an organizer,
  • and my event has ended,
    • and my event has participant responses,
    • and I am on the edit event page,
    • ✅ I see a notice below the end date field which reads "The event has ended, so you cannot change the event dates to future dates. This restriction protects participant data."
    • 
      • If I try change my event dates to a past date,
        • ✅ the action is permitted
        • 
      • ✅ Future dates must be disabled in the calendar date picker
      • 
      • If I try change my event dates to a future date by manually typing the time and submit the form
        • ✅ Alongside the notice mentioned above, I see an error message informing me that the chosen time is after the latest allowed time
        • ✅ and I am not allowed to make the change.
        • 

One more thing to note, this warning is styled differently in the comp than in the build, but this discrepancy was approved in T339979#9191852

comp	build

I have updated the AC to allow the display of the Response Statistics tab, even if there is no data to display. This is because, when I see the example as shown in the comment above, I think it can be useful for the organizer to understand why they do not see data in this tab, as they may use the feature for multiple events and may expect to see the data due to having access to data in the Response Statistics tab in other events.

In T339979#9296284, @ifried wrote:

I have updated the AC to allow the display of the Response Statistics tab, even if there is no data to display. This is because, when I see the example as shown in the comment above, I think it can be useful for the organizer to understand why they do not see data in this tab, as they may use the feature for multiple events and may expect to see the data due to having access to data in the Response Statistics tab in other events.

And if I proceed to make the change,
✅ then a change to the dates can be made,
✅ and the "response statistics" tab should be shown

with responses	without responses

With the updated AC this ticket looks good and I am sending it to design sign off. See also the rest of the testing at T339979#9288359