[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: |
|
||||||||||||||||
| Issue links: |
|
||||||||||||||||
| Sprint: | |||||||||||||||||
| Development Team: | Thor | ||||||||||||||||
| Release: | R3 2021 Bug Fix | ||||||||||||||||
| Affected Institution: |
University of Tennessee Martin
|
||||||||||||||||
| Tester Assignee: | Charlotte Whitt | ||||||||||||||||
| Description |
|
Overview: 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
|
| Comment by Erin Nettifee [ 30/Aug/21 ] |
|
This is not related to
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. 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
|
| 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 |
| 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:
|
| 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
|
| Comment by Zak Burke [ 04/Oct/21 ] |
|
Erin Nettifee, I unassigned
|
| 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? |
| 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", 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 |
| 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 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. |