[MODCR-72] Bugfest. Inconsistent date offset in Courses app Created: 01/Jul/21  Updated: 15/Nov/21  Resolved: 11/Nov/21

Status: Closed
Project: mod-courses
Components: None
Affects versions: None
Fix versions: 1.4.2

Type: Bug Priority: P2
Reporter: Molly Driscoll Assignee: Kurt Nordstrom
Resolution: Done Votes: 1
Labels: bugfest_R3.2021, support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Bugfest courses dates.PNG     JPEG File Hungarian.jpg     PNG File MicrosoftTeams-image (2).png     PNG File MicrosoftTeams-image (3).png     PNG File MicrosoftTeams-image (4).png     PNG File Skærmbillede 2021-11-11 kl. 13.08.06.png     PNG File Skærmbillede 2021-11-11 kl. 13.16.47.png     PNG File Skærmbillede 2021-11-15 kl. 13.38.36.png     PNG File Skærmbillede 2021-11-15 kl. 13.41.46.png     PNG File Skærmbillede 2021-11-15 kl. 13.43.53.png    
Issue links:
Relates
relates to MODCR-71 Expand dates in Reserves to full UTC ... Closed
relates to UICR-144 startDate and endDate do not save in ... Closed
relates to STCOM-849 Wrong day of week in day picker calen... Closed
Sprint:
Development Team: Thor
Release: R3 2021 Bug Fix
Affected Institution:
University of Tennessee Martin
Tester Assignee: Charlotte Whitt

 Description   

Overview: 
UTM is reporting a date discrepancy in their Courses app (Iris HF 1.1): https://utm.folio.ebsco.com/cr/courses/
They have assigned semester dates to the courses, but are seeing a high incidence of the dates being off by a day on the reserve items.
 However, if you edit the reserve item, the appropriate date displays in edit mode.
 The occurrence is inconsistent and sometimes varies among different reserve items on the same course.
 
This behavior is observed in Bugfest on the following record: https://bugfest-iris.folio.ebsco.com/cr/courses/3d900a4d-ebdc-4145-b26d-1914b71d79f7?sort=name 
However, the dates in the edit mode are the same as those in view mode so it's hard to tell if this is the same problem.
 
Steps to reproduce:
See following demo made by Erin Nettifee: Snapshot today: https://duke.box.com/s/liiq1qpofcshrv265oylihzvede9a284

Misc. screenshots attached.

Interested parties: patty.wanninger Anya Molly Driscoll Ann Funkhouser



 Comments   
Comment by Molly Driscoll [ 01/Jul/21 ]

Did not add repro steps because not able to consistently reproduce on Bugfest. 

Comment by Anya [ 12/Jul/21 ]

Support : there could be 2 issues - 1 stripe component or courses ...  John Coburn could you check to see if this is a date picker issue?- Thanks 

Comment by Anya [ 19/Jul/21 ]

Support - will test this when MODFEE-199 is fix - Charlotte Whitt will test after the fix... 

Comment by Anya [ 09/Aug/21 ]

Suppot : Charlotte Whitt this is a p2 - what release will this be attached to?

Comment by Charlotte Whitt [ 11/Aug/21 ]

I'm wondering if this is related with UICAL-152 Closed Calendar exceptions displaying on wrong day of week (offset by a day)
For now I'll block this ticket, and await the work being solved with UICAL-152 Closed .

Comment by Erin Nettifee [ 30/Aug/21 ]

This is not related to UICAL-152 Closed - the Courses app doesn't use that to display dates.

So, the way dates display on items is a little weird in the Courses app. You have the date from the term that displays in the accordion, and then the item inherits the dates from the term. But, in the underlying reserve, the item actually has no startDate or endDate attribute unless you have edited the item and set one.

Hopefully I can illustrate this with an example.
1) I create a course called "Intro to FOLIO" and associate it with a term labeled "Fall 2021" that has a start date of 8/1/2021 and an end date of 12/1/2021.
2) I attach item X to this course by inputting the barcode.
3) The item appears on the course pane "intro to FOLIO" and you see a start date or 8/1/2021 and an end date of 12/1/2021 for the item, BUT, if you look at the underlying data for that item X, you would NOT see an attribute of startDate and endDate.

Now, suppose I actually want that item to be available a day early. I could edit the item record and set the startDate to 7/31/2021, and then save the item. At that point, the item would display on the course with a start date of 7/31/2021, and an end date of 12/1/2021, AND if you look at the underlying JSON, at that point it has a startDate and endDate attribute.

Now, there IS a bug related to how those startDate and endDate attributes are stored, which Mark Deutsch and I went back and forth on a bit, and resulted in https://folio-org.atlassian.net/browse/UICR-144. I thought Mark had actually done it before he left the project, but I can see the jira is still open. It looks like he did work on it and there are some associated commits, but I don't know enough about github to know if it was successful or not. So, if a Support SIG dev or maybe someone with IndexData could take a look at the commits associated with UICR-144 Closed and see if they could be moved into testing, than perhaps we could see if resolving that issue resolves the display issues that UT Monroe is seeing.

Comment by Anya [ 13/Sep/21 ]

SUPPORT: There is no dev team or PO - this will be brought up to the PC (Jesse Koennecke)- as to what should be the way to address, how we support the general release of FOLIO. 

Comment by Zak Burke [ 13/Sep/21 ]

I think the problem is that we're calling formatDate on a timestamp when we should be pushing those timestamps through <FormattedUTCDate>.

Comment by Charlotte Whitt [ 13/Sep/21 ]

Hi Anya - the Thor team has assigned me as PO for the course app - for now
CC: Mike Gorrell

Comment by Zak Burke [ 13/Sep/21 ]

Molly Driscoll, I take it back; this looks like a data problem, not a code/formatter problem.

The UI is displaying the data handed to it by the coursereserves/courselistings query. In the case of "101 law forms for personal use /by Ralph Warner & Robin Leonard", that is January 22 through May 22 (query)

{
  "id" : "4d789a8a-7cbe-4c4b-916a-b67f07101e43",
  "courseListingId" : "4cbee61e-4a51-48de-8b84-e41330ed3bf9",
  "itemId" : "ab6b09f5-b6ae-4d1c-8bbe-acbd81facdae",
  "startDate" : "2021-01-22",
  "endDate" : "2021-05-22",

which is different than the course's schedule of January 23 through May 23 (query):

{
  "id" : "3d900a4d-ebdc-4145-b26d-1914b71d79f7",
  "name" : "English 101",
  ...
  "courseListingId" : "4cbee61e-4a51-48de-8b84-e41330ed3bf9",
  "courseListingObject" : {
    "id" : "4cbee61e-4a51-48de-8b84-e41330ed3bf9",
    ...
    "termId" : "1de66abe-d1dd-40a2-94a2-4aef07d37852",
    "termObject" : {
      "id" : "1de66abe-d1dd-40a2-94a2-4aef07d37852",
      "name" : "2020 Spring",
      "startDate" : "2020-01-23T00:00:00.000Z",
      "endDate" : "2020-05-23T00:00:00.000Z"
    },

I don't know how the incorrect information was stored in the first place. When adding new inventory items to an existing course, they are added without start-date and end-date fields, as expected, and correctly display the term's values for these fields. Editing the reserve and changing its dates so they override those from term again shows the data to be correctly stored and correctly formatted in the UI.

Unless we can uncover specific actions that lead to the wrong value being stored, I think this can be closed as "Cannot reproduce".

Comment by Erin Nettifee [ 13/Sep/21 ]

Zak Burke - see my comment upstream:

Now, there IS a bug related to how those startDate and endDate attributes are stored, which Mark Deutsch and I went back and forth on a bit, and resulted in https://folio-org.atlassian.net/browse/UICR-144. I thought Mark had actually done it before he left the project, but I can see the jira is still open. It looks like he did work on it and there are some associated commits, but I don't know enough about github to know if it was successful or not. So, if a Support SIG dev or maybe someone with IndexData could take a look at the commits associated with UICR-144 Closed and see if they could be moved into testing, than perhaps we could see if resolving that issue resolves the display issues that UT Monroe is seeing.

Comment by Anya [ 04/Oct/21 ]

SUPPORT: Erin Nettifee / Molly Driscoll can you confirm the storing of dates.... and if it is still an issue 

Comment by Erin Nettifee [ 04/Oct/21 ]

Anya Zak Burke Charlotte Whitt if someone can take a look at UICR-144 Closed and see if that work can get all the way pushed through, then I'm happy to look at the dates / storage issue here and see if it might be resolved. See my comment upstream.

Comment by Zak Burke [ 04/Oct/21 ]

Erin Nettifee, I unassigned UICR-144 Closed since md331 is no longer on the project, but as I commented above, I could not reproduce the date storage problem in bugfest-iris.

Comment by Erin Nettifee [ 05/Oct/21 ]

What I saw on Snapshot today: https://duke.box.com/s/liiq1qpofcshrv265oylihzvede9a284

The app does not store a timezone value on the reserve record, so I think that may be at the source of this issue

Comment by Charlotte Whitt [ 28/Oct/21 ]

Hi Kurt Nordstrom - how it it going with this ticket?
(I'm only asking because I going over all Thor team's Bugfest R3 2021 work)

Comment by Charlotte Whitt [ 11/Nov/21 ]

Manual test in FOLIO Snapshot version @folio/inventory 9.0.100000123, using Chrome.

I have verified that the properties startDate and endDate now has the Time Locale set and aligned with the Tenants choice in Settings.

"startDate" : "2021-02-01T00:00:00Z",
"endDate" : "2021-12-07T00:00:00Z",

This is looking good Kurt Nordstrom - will you provide the jira ticket with the relevant release and then we can get this ticket to be deployed to Bugfest Kiwi

CC: Oleksii Petrenko Anton Emelianov

Comment by Anton Emelianov (Inactive) [ 11/Nov/21 ]

Kurt Nordstrom, please update Fix Version field

Comment by Cheryl Malmborg [ 12/Nov/21 ]

Khalilah Gambrell I was testing on snapshot dev late in the afternoon CT. I will look again now.

Comment by Cheryl Malmborg [ 12/Nov/21 ]

Khalilah Gambrell I think what I reported as an error is actually correct. It was just very confusing to me because of the calendar style and language. I am sorry.

Comment by Charlotte Whitt [ 15/Nov/21 ]

Manual test in Bugfest Kiwi

Checking with Kurt Nordstrom, and he explains that the issue here is that the back-end really doesn't know anything about the user's timezone. So when it gets a date that is only a localdate (e.g. 2020-11-15), all it can do is turn it into a UTC string with the time set to 00:00:00Z.

Erin Nettifee Molly Driscoll
If we want the dates to actually reflect user timezones, the front end needs to be changed to provision that.
Please let me know if that's a requirement, then I can add a UICR-story for this (and have it to be scoped as Lotus work).

With theses comments I'll close this ticket for Bugfix R1 2021.

Comment by Erin Nettifee [ 15/Nov/21 ]

Charlotte Whitt I do think this should be scoped for a new feature, since it is affecting UT Martin and able to be replicated.

Comment by Molly Driscoll [ 15/Nov/21 ]

I agree with Erin Nettifee. Given the presence of locale settings for the tenant, I think the expectation is that dates/times in the tenant will adhere to whatever timezone is configured at the tenant level.

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