Recurrence Rules End Date does not include event occuring on the end date #156
Comments
|
Is this a new problem or prexisting?
We use ical4j (a java library) to handle all recurrences and the
standards make some statements which are in some cases ambiguous.
It could be a ui issue in that we may end up with a date/time which is
before the last date. Also having the end-date selection be essentially
a search of the occurrences would also help.
If it is a preexisting issue I'd prefer to implement a good solution -
with your input - rather than a quick fix.
…On 11/4/22 11:18, Kyle Cook wrote:
Background
The recurrence rules function in the events form allows user to set
the end date of a recurring event series. Bedework is set to consider
the series to end on 11:59 p.m. of the date prior to the end date.
While logic would suggest an "end date" not include events on the
ending date, and technical conventions may require this, my users do
not interpret it thus.
Example: 1st Thursday Book Club occurs on first thursday of months of
March April May, 2023. User sets begin date to Thursday, March 2; end
date to Thursday, May 4.
|every month(s) on the first Thurepeating until 2023-05-04|
Expected
Based on repairing this error for users, I observe most users expect
the end date to include events occuring on the end date (May 4). This
convention is consistent with their company's enterprise calendar
recurrence setting which includes events scheduled on the end date.
Proposed Fix
At least on the Add Event forms, when user selects an end date to a
series, events that fall on this day should be included in the series.
—
Reply to this email directly, view it on GitHub
<#156>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAW2MBRMKG5ARADROVZNUVTWGUSK3ANCNFSM6AAAAAARXJCWWM>.
You are receiving this because you are subscribed to this
thread.Message ID: ***@***.***>
|
|
Kyle - I understand how this may be misunderstood by the user: they want
to set the "last day" an event occurs and don't really understand
"last-day + 1", right? I've also experienced end-user confusion about
this for all-day events that don't recur.
Mike - this is a UI issue, and probably one that could be configurable
in the admin client (so that existing deployments that are accustomed to
the original behavior can remain as they are or opt in). The back-end
storage could remain exactly as it is - but if the admin client is set
to use the behavior where end-date is inclusive, the end date saved by
an event edit form would be converted to "end-date +1" prior to storage
and then "end-date -1" when it's retrieved for editing back in the form.
I expect this would only be used for end date settings for recurring or
all-day events.
The calendar front-end, downstream clients, and all else would behave as
they always have.
Arlen
…On 11/4/22 1:36 PM, Mike Douglass wrote:
Is this a new problem or prexisting?
We use ical4j (a java library) to handle all recurrences and the
standards make some statements which are in some cases ambiguous.
It could be a ui issue in that we may end up with a date/time which is
before the last date. Also having the end-date selection be essentially
a search of the occurrences would also help.
If it is a preexisting issue I'd prefer to implement a good solution -
with your input - rather than a quick fix.
On 11/4/22 11:18, Kyle Cook wrote:
>
>
> Background
>
> The recurrence rules function in the events form allows user to set
> the end date of a recurring event series. Bedework is set to consider
> the series to end on 11:59 p.m. of the date prior to the end date.
> While logic would suggest an "end date" not include events on the
> ending date, and technical conventions may require this, my users do
> not interpret it thus.
>
> Example: 1st Thursday Book Club occurs on first thursday of months of
> March April May, 2023. User sets begin date to Thursday, March 2; end
> date to Thursday, May 4.
>
> |every month(s) on the first Thurepeating until 2023-05-04|
>
>
> Expected
>
> Based on repairing this error for users, I observe most users expect
> the end date to include events occuring on the end date (May 4). This
> convention is consistent with their company's enterprise calendar
> recurrence setting which includes events scheduled on the end date.
>
>
> Proposed Fix
>
> At least on the Add Event forms, when user selects an end date to a
> series, events that fall on this day should be included in the series.
>
> —
> Reply to this email directly, view it on GitHub
> <#156>, or unsubscribe
>
<https://github.com/notifications/unsubscribe-auth/AAW2MBRMKG5ARADROVZNUVTWGUSK3ANCNFSM6AAAAAARXJCWWM>.
> You are receiving this because you are subscribed to this
> thread.Message ID: ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#156 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAUE7Y7DT63HG7QOQ3XF2ULWGVCRDANCNFSM6AAAAAARXJCWWM>.
You are receiving this because you are subscribed to this
thread.Message ID: ***@***.***>
|
|
I'd missed the date-only issue - yes for date only it's routine for a UI
to set the end date to date+1 the user sets.
What I'd been considering is to just present the occurrences to the user
as a list once they type the year adn narrow it down as they type - it
would work for date-time occurrences as well and probably minimizes
input errors.
For now the major issue is whether or not this is a pre-existing issue -
if pre-existing it should probably wait till after we get the system
upgrade at Nashville in place - also I just realized this came in on the
bedework issues - not the nashville issues so that probably answers the
question.
…On 11/4/22 13:51, Arlen Johnson wrote:
Kyle - I understand how this may be misunderstood by the user: they want
to set the "last day" an event occurs and don't really understand
"last-day + 1", right? I've also experienced end-user confusion about
this for all-day events that don't recur.
Mike - this is a UI issue, and probably one that could be configurable
in the admin client (so that existing deployments that are accustomed to
the original behavior can remain as they are or opt in). The back-end
storage could remain exactly as it is - but if the admin client is set
to use the behavior where end-date is inclusive, the end date saved by
an event edit form would be converted to "end-date +1" prior to storage
and then "end-date -1" when it's retrieved for editing back in the form.
I expect this would only be used for end date settings for recurring or
all-day events.
The calendar front-end, downstream clients, and all else would behave as
they always have.
Arlen
On 11/4/22 1:36 PM, Mike Douglass wrote:
> Is this a new problem or prexisting?
>
> We use ical4j (a java library) to handle all recurrences and the
> standards make some statements which are in some cases ambiguous.
>
> It could be a ui issue in that we may end up with a date/time which is
> before the last date. Also having the end-date selection be essentially
> a search of the occurrences would also help.
>
> If it is a preexisting issue I'd prefer to implement a good solution -
> with your input - rather than a quick fix.
>
> On 11/4/22 11:18, Kyle Cook wrote:
> >
> >
> > Background
> >
> > The recurrence rules function in the events form allows user to set
> > the end date of a recurring event series. Bedework is set to consider
> > the series to end on 11:59 p.m. of the date prior to the end date.
> > While logic would suggest an "end date" not include events on the
> > ending date, and technical conventions may require this, my users do
> > not interpret it thus.
> >
> > Example: 1st Thursday Book Club occurs on first thursday of months of
> > March April May, 2023. User sets begin date to Thursday, March 2; end
> > date to Thursday, May 4.
> >
> > |every month(s) on the first Thurepeating until 2023-05-04|
> >
> >
> > Expected
> >
> > Based on repairing this error for users, I observe most users expect
> > the end date to include events occuring on the end date (May 4). This
> > convention is consistent with their company's enterprise calendar
> > recurrence setting which includes events scheduled on the end date.
> >
> >
> > Proposed Fix
> >
> > At least on the Add Event forms, when user selects an end date to a
> > series, events that fall on this day should be included in the series.
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <#156>, or unsubscribe
> >
>
<https://github.com/notifications/unsubscribe-auth/AAW2MBRMKG5ARADROVZNUVTWGUSK3ANCNFSM6AAAAAARXJCWWM>.
> > You are receiving this because you are subscribed to this
> > thread.Message ID: ***@***.***>
> >
>
> —
> Reply to this email directly, view it on GitHub
>
<#156 (comment)>,
> or unsubscribe
>
<https://github.com/notifications/unsubscribe-auth/AAUE7Y7DT63HG7QOQ3XF2ULWGVCRDANCNFSM6AAAAAARXJCWWM>.
> You are receiving this because you are subscribed to this
> thread.Message ID: ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#156 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAW2MBTVY5FUKBRZBZ63HYTWGVEJJANCNFSM6AAAAAARXJCWWM>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
This is a pre-existing issue present on current Nashville prod, and Nashville eventsdev. So, not specific to the present upgrade process. This has been an issue for a long time (years). Not urgent to fix on project before deploying next version on Nashville. Should wait. Added to Bedework Issues instead. I am noticing a trend that more users are having trouble interpreting that range-picker than in past years. Although I've always pointed it out while showing the interface in training. Of four users who added recurring events today, three made this entry error. |
|
Another recurrence related issue - Yale asked that we suppress the
no-end-date option as their major problem was users selecting that adn
then they'd have to go back and fix it for them.
By default that is on so the option has gone - I think it's still
visible for admins. Do you want it left in that state for nashville?
…On 11/4/22 15:09, Kyle Cook wrote:
This is a pre-existing issue present on current Nashville prod, and
Nashville eventsdev. So, not specific to the present upgrade process.
This has been an issue for a long time (years). Not urgent to fix on
project before deploying next version on Nashville. Should wait. Added
to Bedework Issues instead.
I am noticing a trend that more users are having trouble interpreting
that range-picker than in past years. Although I've always pointed it
out while showing the interface in training. Of four users who added
recurring events today, three made this entry error.
—
Reply to this email directly, view it on GitHub
<#156 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAW2MBX7X2VXDEPNBL5SQEDWGVNQBANCNFSM6AAAAAARXJCWWM>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
We also have problem with users leaving the default 'forever'. Is this option you refer to as
|
|
On 11/4/22 16:07, Kyle Cook wrote:
We also have problem with users leaving the default 'forever'. Is this
option you refer to as |no-end-date|?
That's the one
…
Screen Shot 2022-11-04 at 3 05 20 PM
<https://user-images.githubusercontent.com/5504002/200065190-10946e05-3237-451b-a28e-f1b8133fb298.png>
—
Reply to this email directly, view it on GitHub
<#156 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAW2MBRYW7MUEMBLFCSYUXDWGVUHJANCNFSM6AAAAAARXJCWWM>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Affirmative to disabling this option for all users. We never want to have users able to select 'forever' |
|
To original issue: I believe we were able to address this in the UI before--by adding a value of +1 somewhere in the settings. I can't locate this option now. However, our users are once again running into the problem while using the Users identify this repeat completion date as the last occurrence of the series, instead of the end of the logical date range during which the series repeats (the day after). Our users' behavior replicates functionality of Outlook calendar's use of End Date, their UI describes this as |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
The recurrence rules function in the events form allows user to set the end date of a recurring event series. Bedework is set to consider the series to end on 11:59 p.m. of the date prior to the end date. While logic would suggest an "end date" not include events on the ending date, and technical conventions may require this, my users do not interpret it thus.
Example: 1st Thursday Book Club occurs on first thursday of months of March April May, 2023. User sets begin date to Thursday, March 2; end date to Thursday, May 4.
every month(s) on the first Thurepeating until 2023-05-04Expected
Based on repairing this error for users, I observe most users expect the end date to include events occuring on the end date (May 4). This convention is consistent with their company's enterprise calendar recurrence setting which includes events scheduled on the end date.
Proposed Fix
At least on the Add Event forms, when user selects an end date to a series, events that fall on this day should be included in the series.
The text was updated successfully, but these errors were encountered: