[UICAL-132] Calendar hours displaying on wrong day of week (offset by a day) Created: 27/Jan/21  Updated: 06/Aug/21  Resolved: 24/Feb/21

Status: Closed
Project: ui-calendar
Components: None
Affects versions: None
Fix versions: 5.0.1

Type: Bug Priority: P2
Reporter: Molly Driscoll Assignee: Dmitriy Litvinenko
Resolution: Done Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Dateoffsetview.PNG     PNG File Dateoffsetview_Juniper.PNG     Microsoft Word Honeysuckle Bugfest Calendar Offset.docx    
Issue links:
Cloners
is cloned by UICAL-152 Calendar exceptions displaying on wro... Closed
Sprint: EPAM-Veg Sprint 108, EPAM-Veg Sprint 109
Story Points: 1
Development Team: Vega
Release: Q3 2020 Hot Fix #3
Affected Institution:
Chalmers, MO State, St. Michael's College, University of Tennessee Martin
Tester Assignee: Darcy Branchini

 Description   

Overview: St. Michael's College (Honeysuckle) is setting up their service point calendar and reported that the hours are reflecting on the wrong days of the week. For example, Saturday's hours are showing on Sunday and Sunday's hours are showing on Monday. I am seeing this behavior replicated in the Bugfest Honeysuckle environment. I spoke to Cheryl Malmborg about this and she advised opening a support bug if @folio/calendar 5.0.0 is loaded. (It is on both St. Michael's tenant and on Bugfest. Screenshots of this behavior on Bugfest are attached for reference. I'm not sure if this is related to STCOM-779 Closed (which is listed as Closed) or if this is a new issue entirely.

Steps to Reproduce:

  1. Log into https://bugfest-honeysuckle.folio.ebsco.com/
  2. Click Settings
  3. Click Calendar
  4. Select any service point
  5. Examine the hours for each day of the week
  6. Open the calendar to add exceptions

Expected Results: The open hours will display on the appropriate day of the week.
Actual Results: The open hours are offset by a day (Sunday's hours display on Monday, Monday's hours on Tuesday, etc.)

Interested parties: Stacey Knight Kyle Banerjee Brooks Travis



 Comments   
Comment by Molly Driscoll [ 27/Jan/21 ]

Anton Emelianov can you please add St. Michael's College as an affected institution?

Comment by Molly Driscoll [ 27/Jan/21 ]

Listed as P1 because I am not aware of a workaround; please notify if priority needs adjustment.

Comment by Brooks Travis [ 28/Jan/21 ]

Sorry, Molly Driscoll. I brought this up with Cheryl in the past and I somewhat assumed it was a result of how I was populating the calendar via the APIs. Overall, the calendar UI is a mess. There's a UXPROD (https://folio-org.atlassian.net/browse/UXPROD-2657) to revise the it, but it's still in draft. Thankfully, it doesn't seem to affect the backend functionality.

Comment by Molly Driscoll [ 28/Jan/21 ]

Thanks, Brooks Travis, for the insight! St. MIke's isn't far enough along where we're able to test circulation rules, but I'm glad to hear it's not having an impact on circ behavior. With that in mind, should I downgrade the priority on this since there's no business impact or do people think this should remain P1 since there's no workaround? (This question is mostly directed at the Support SIG, cc: Kelly Drake

Comment by Marie Widigson [ 28/Jan/21 ]

A comment from a library in production. We're using the (messy) UI to populate the calendar. If it's displaying the wrong day it's very confusing and I think it should be highly prioritized.

Comment by Marie Widigson [ 28/Jan/21 ]

I added an EBSCO support case about this back in October 2020 (Goldenrod live environment) where the day appeared on the wrong day.
After a few days, without any intervention that we were aware of, the exception suddenly appeared on the correct day! This happened during the week when Sweden changed from summer time to winter/normal time, if that could have anything to do with it?

Case #4413470 FOLIO [Important] Calender exception period appears on wrong day
October 23 2020

I added an exception period Closed for next Saturday but it shows up on Friday instead.

Steps to reproduce:
In Goldenrod live environment - Settings - Calendar - Library hours.
New exception period
Valid from 10/31/2020, valid to 10/31/2020 (Choosed from calender icon)
Name Closed 20201031
Checked Main Library HB and Main Library HB Self Check
Checked Closed (All day then becamame automatically checked)
Save & Close

Expected behaviour:
To see the "All day" exception at Sat 10/31/2020

Actual behavior:
The "All day" exception shows at Fri 10/30/2020

Follow up comment on October 28th:
When checking our calendar today I saw that the exception period is now displaying on the correct day! That is very good, but strange, since we have not made any changes since this case was reported. Have any of you made any changes?

In Sweden, we changed to winter hours (normal time) this weekend, can that have something to do with it?

Comment by Zak Burke [ 28/Jan/21 ]

I don't think STCOM-779 Closed is related though it is likely the same kind of problem (0-based vs 1-based dates). That bug is specific to the <Datepicker> form component and this looks like a bug in ui-calendar that we need to bring to the attention of Holly Mistlebauer (the PO) and Maxim Didenko (the tech lead).

As Brooks Travis noted, this appears to be a UI-only bug, i.e. that data in the backend for a given service point reflects what the Settings > Calendar > Library hours > some-service-point shows and it's only the exception-calendar display that is off when you click the "Open calendar to add exceptions" button. The weekly/regular library hours calendar (click the pencil icon for a given service point) shows things correctly.

Details UI:

Sun       Mon       Tue
02:00 -   00:00 -   03:00 - 
23:30     19:30     19:30

API:

{
  "openingPeriods" : [ {
    "id" : "ae268f0b-d4e4-4419-9ce9-8888ef32ccb8",
    "servicePointId" : "a3cbfa53-3e36-4cbc-8213-85848623d73b",
    "name" : "a",
    "startDate" : "2019-03-01T00:00:00.000+00:00",
    "endDate" : "2021-07-30T00:00:00.000+00:00",
    "openingDays" : [ {
      "weekdays" : {
        "day" : "SUNDAY"
      },
      "openingDay" : {
        "openingHour" : [ {
          "startTime" : "02:00",
          "endTime" : "23:30"
        } ],
        "allDay" : false,
        "open" : true
      }
    }, {
      "weekdays" : {
        "day" : "MONDAY"
      },
      "openingDay" : {
        "openingHour" : [ {
          "startTime" : "00:00",
          "endTime" : "19:30"
        } ],
        "allDay" : false,
        "open" : true
      }
    }, {
      "weekdays" : {
        "day" : "TUESDAY"
      },
      "openingDay" : {
        "openingHour" : [ {
          "startTime" : "03:00",
          "endTime" : "19:30"
        } ],
        "allDay" : false,
        "open" : true
      }
    }, ...
Comment by Kelly Drake [ 28/Jan/21 ]

Hi all, I'm a bit concerned about the P1 ranking. P1 should indicate that the system/app is broken and there is no workaround, and which requires a hotfix. Can we pop this down to a P2? There are workarounds and they system still functions.

Comment by Kelly Drake [ 28/Jan/21 ]

PS This also occurs in the Simmons environment, but they are not currently circulating so there is no effect.

Comment by Marie Widigson [ 28/Jan/21 ]

Kelly Drake Agree that it works anyway, so for Chalmers it does not have to be P1. Just very confusing.

Comment by Molly Driscoll [ 28/Jan/21 ]

Kelly Drake, with your feedback and the feedback from Chalmers and MO State, I updated to P2. I think it should have a priority for Iris, but does not necessitate a hotfix. Resolving this will help mitigate confusion in documentation, training, and ongoing maintenance.

Comment by Kelly Drake [ 08/Feb/21 ]

Cheryl Malmborg - Do you know if any work on this is being done? Most importantly - will it be fixed in Iris?

Comment by Kelly Drake [ 08/Feb/21 ]

Cheryl Malmborg - Can you also confirm that you are the correct PO for UI-Calendar?

Comment by Cheryl Malmborg [ 08/Feb/21 ]

Kelly Drake Kelly, I am the correct PO.

Comment by Darcy Branchini [ 12/Feb/21 ]

Cheryl Malmborg, have you talked to Holly about the revised calendar UI feature and whether or not that will be prioritized anytime soon? If not (or maybe even if we will be prioritizing those UI changes), we should prioritize this bug. What's your feeling on it?

Comment by Kelly Drake [ 15/Feb/21 ]

David Bottorff - Have you had a chance to look at this and determine if it effects Chicago.

Comment by Kelly Drake [ 15/Feb/21 ]

Support SIG has confirmed that this issue is very important, possibly a P1 for the Iris libraries.  Is there any possibility for getting a dev team? Mike Gorrell and the rest of the Capacity Planning Team?

Comment by Mike Gorrell [ 15/Feb/21 ]

Cap Planning team will discuss.

Comment by Holly Mistlebauer [ 15/Feb/21 ]

Darcy Branchini:  Is there any chance this bug can be fixed in the current sprint, which is the last one before the core code freeze?  This is going to impact the summer implementers.  If we can't fit it into Iris, we will have to do a hotfix to Iris.  Thanks...

Comment by Darcy Branchini [ 15/Feb/21 ]

I'll add it to our sprint Holly Mistlebauer Mike Gorrell Kelly Drake .

Comment by Molly Driscoll [ 22/Feb/21 ]

Anton Emelianov, can you please add University of Tennessee Martin to the affected institutions list so I can add them to this bug?

cc: patty.wanninger, Ann Funkhouser

Comment by Darcy Branchini [ 25/Feb/21 ]

Dmitriy Litvinenko you mentioned that you created a release for this? Can you please add it to the Fix version on this ticket and point me to it in GitHub? I can then ask Anton to deploy it to bugfest. Thanks!
cc: Alexander Kurash

Comment by Dmitriy Litvinenko [ 01/Mar/21 ]

Fix Version/s: 5.0.1

Comment by Anya [ 01/Mar/21 ]

Support: Did this become part of the most hotfix release? 

Comment by Darcy Branchini [ 01/Mar/21 ]

Anya, once it's tested on honeysuckle, it'll be part of hotfix #3 (not released yet).

Comment by Anya [ 08/Jun/21 ]

Darcy Branchini this is still happening

Comment by Darcy Branchini [ 10/Jun/21 ]

Dmitriy Litvinenko tested this and was unable to reproduce it on Iris. What environment is this still seen on Anya? I'm still going to retest by changing timezones to see if that's related to the issue. If it is, then I'll create a new bug for that.

Comment by Molly Driscoll [ 04/Aug/21 ]

Darcy Branchini Dmitriy Litvinenko Anya, the regular calendar hours appear to display correctly, but the exceptions are still displaying a day early in both the Iris dev environment and Juniper bugfest. Should this be a new bug?

Comment by Molly Driscoll [ 04/Aug/21 ]

This is Iris and the above is Juniper

Generated at Thu Feb 08 22:21:26 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.