CMS: Events recurrence - if field_datetime_range_timezone[0][interval] field is set to 1, does not display to users on Node Edit

[jilladams]

Status

[2024-09-18] [Dave] Identified 2 upstream Module issues that would resolve this. I don't think it's worth trying to have one of our Drupal engineers try and push the suggested fixes through the upstream process, given that this is not a priority defect for our team. [2024-08-19] [Fran] We would like UX folks to evaluate to determine if help text or ? should be done for this issue. [2024-04-23] Since this behavior is confusing to editors, I'm (Fran) moving this to next Refinement to ask Jordan Wood to evaluate.

Describe the defect

In the CMS, a recurring event can be created with no value specified in "Repeat every: [# of]" field (field_datetime_range_timezone[0][interval] ).

On an event with recurrence that has been previously created, in the edit view, the field_datetime_range_timezone[0][interval] field is empty.

When this field is left empty, Event will save, and recurrence will assume field_datetime_range_timezone[0][interval] = 1.

Additional Information

1. Although Swirt indicated the code might be fragile and he doesn't feel it's actually worth pursuing, Jill (and Fran) feel that maybe we could add help text or something that says an empty value will be set to 1? I think you're right that it's not a deep problem, but it is very confusing to come edit a node you did not create, and try to figure out exactly what's happening. Would like UX to evaluate.
2. This missing recurrence appears to have possibly broken content release on 9/19/24: https://dsva.slack.com/archives/CT4GZBM8F/p1726766045895619?thread_ts=1726762852.899099&cid=CT4GZBM8F

To Reproduce

Steps to reproduce the behavior: To create an event in this state:

1. https://staging.cms.va.gov/node/add/event
2. Specify title, start/end day & time
3. Click "Make recurring"
4. Change days to weeks
5. Select M for Monday
6. Set Until to a future date several weeks from now.
7. Save
8. In the preview of the new node, see that Content > Date & Time list of recurrences has created occurrences 1x / week til the end date.

To view a live event in this state:

1. Go to https://prod.cms.va.gov/node/46932/edit
2. Under Date and time: Repeat every [ # of ] (field-datetime-range-timezone-0-interval) is empty
3. Weeks (field_datetime_range_timezone[0][repeat]) is set
4. Click "Edit event series" button to see that recurrences are set to weekly. (With some recurrences canceled.)

Expected behavior

EITHER:

1. The form should not save with an empty field-datetime-range-timezone-0-interval, OR
2. When no value is set, we populate field-datetime-range-timezone-0-interval with the value 1, to make the recurrence pattern clear to editors in future

Screenshots

Edit screen:


Recurrence:


[swirtSJW]

I don't think this one is actually a problem starting with

results are what I would expect

I don't think we want to get into requiring or forcing the data. That could give undesired results.

[swirtSJW]

Looking through the smartdate module issue queue I am not seeing any other reports suggesting "Repeat every" needs a required or forced value.

The logic for conditional fields and display can be a bit fragile in general. I'd prefer to avoid tinkering with it too much unless it is clearly needed.

[jilladams]

Maybe we could add help text or something that says an empty value will be set to 1? I think you're right that it's not a deep problem, but it is very confusing to come edit a node you did not create, and try to figure out exactly what's happening. (Curious @suzanne-gray 's opinion there, as CMS UX guidance. Or loop anyone else who should opine.)

[davidmpickett]

Our issue title here is misleading. It is not possible to submit the form with an empty value. The value defaults to 1. However, the behavior of the dropdown field if the value is set to 1 is to display "# of" instead of 1.

This is true even if you change the value to 1 and save

When you edit the event again, this drop down seems like it is unset, even though it is set to 1.

[davidmpickett]

@FranECross @jilladams @mmiddaugh

• I just commented on an upstream issue in the module to note that we also find this confusing and would like this fixed.
• Another upstream issue where this is documented
• Because the the Smart Date module controls this entire widget interface, we can't easily insert help text per subfields. If we tried to add help text it would show up at the top of the whole field, and not down where the confusing drop-down field actually is.

• Any work we'd do to override the default module behavior locally on our Durpal instance would be tech debt. This problem should be addressed at the root.
• I suggest we leave this in the backlog to close at a future date if the module gets updated
• We could have a Drupal engineer try to push through the upstream fix through the pipeline, but not sure that would be a great use of their time and capacity

[Agile6MSkinner]

Thank you for getting to the bottom of this. Per conversation with @mmiddaugh and @EWashb in helpdesk sync today, this resulted in a content build failure. @omahane or @davidmpickett, can we pursue the solution in this drupal issue?

[davidmpickett]

@Agile6MSkinner Can you provide more specifics on the Content Build failure? I don't see how this could issue could create a failure since it is purely a user-facing display issue

[Agile6MSkinner]

I can't, and in fact there's a chance I'm misspeaking there. @EWashb could you elaborate?

[jilladams]

~@Agile6MSkinner I think I'd mentioned that during planning but I was wrong. I was thinking of the issue where you could end up saving an event with an empty Location field (#17426 ) and that broke things.~

~In this case, recurrence is actually getting set, per Dave's note, it's just a weird UX. Looking over his notes, does seem like if @FranECross wants to pursue us fixing the underlying issue and upstreaming it to the module maintainers, we could, but agree that trying to inject better help text is prob not the best way forward, given the limitations of where it would appear.~

~I am wrong, this issue did break content-build, in Erika's linked Slack thread below.~

[davidmpickett]

Moving back to backlog

[EWashb]

failure

The context is in this thread:

https://dsva.slack.com/archives/CT4GZBM8F/p1726762852899099

Cc @Agile6MSkinner

[jilladams]

After reviewing that thread with DaveP, we determined the Event that broke prod was not a recurring event. That means this issue is not related to the prod outage and so far remains just an editor clarity / UX issue.

We've cut a new ticket, #19284 to track the Events related issue that led to the outage yesterday.