OBPIH-7101 fix unique expiration date validation#5143
Conversation
github-actions
bot
added
type: bug
ewaterman
added
the
warn: do not merge
| const expirationDate = item?.inventoryItem?.expirationDate; | ||
| // TODO: isSame is returning false, even if the dates are the same! I suspect it's trying | ||
| // to use local time when parsing "MM/dd/yyyy". Gotta find a way to make this default | ||
| // to UTC. This kinda sucks though, maybe we need a more general solution to this... |
There was a problem hiding this comment.
would appreciate anyone's help getting this to work cleanly.
I'm sure there's a way to treat the string as UTC by default (for the "MM/dd/yyyy" case) but then also if the string has timezone specified, use that (for the "yyyy-MM-dd'T'hh:mm:ssXXX" case). I'm just slow to figure out how to do stuff on the frontend.
That said, a part of me feels like the best solution is to modify the cycle count logic on the frontend to always work in the "MM/dd/yyyy" format for expiration dates (we can still display "dd/MMM/yyyy"). The inconsistency here is really awkward to work around. I don't see exactly where on the frontend the disconnect is happening though so I don't know where it's setting the "yyyy-MM-dd'T'hh:mm:ssXXX" format
There was a problem hiding this comment.
Note that we can't just trim off the time portion of the date/moment because it could result in the date being different.
Ex: 2000-01-01T00:00:00Z == 1999-12-31T23:00:00-01:00 so we need to be careful about how we handle this. It's why just working with MM/dd/yyyy is probably simplest. No time component at all to work with...
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #5143 +/- ##
============================================
- Coverage 8.15% 8.15% -0.01%
Complexity 945 945
============================================
Files 637 637
Lines 43133 43134 +1
Branches 10486 10486
============================================
Hits 3517 3517
- Misses 39077 39078 +1
Partials 539 539 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
ewaterman
requested review from
SebastianLib,
alannadolny,
awalkowiak and
kchelstowski
ewaterman
changed the title
| return expirationDate == null ? null : moment(expirationDate); | ||
| }); | ||
| const uniqueDates = _.uniqWith(expirationDates, (arrVal, othVal) => arrVal?.isSame(othVal)); |
There was a problem hiding this comment.
you can try to use .format on the moment date, and then put those in _.uniq
There was a problem hiding this comment.
I was doing something like that originally. It doesn't work either way because the moments are different.
Interestingly. the first time I pick a date using the datepicker, it always picks the day before I select. Then if I try again, it works. Maybe something to do with DateField.jsx? Not sure if that's related. https://jam.dev/c/7765ce91-6ee6-4c45-a5e0-978a6a54e38e
If I do something like this:
I end up with these expiration date strings being parsed in:
existing item (bin "Ph: Med Equip & Supplies")
- inventory item: "03/03/2027"
- moment as iso string: "2027-03-03T08:00:00.000Z" -> is it converting to my local time but thinking it's still UTC?? I'm UTC -8
- moment formatted as date: "03/03/2027"
new item, first time click March 3rd, 2027 (it actually picks the 2nd)
- inventory item: "2027-03-03T00:00:00Z"
- moment as iso string: "2027-03-03T00:00:00.000Z"
- monent formatted as date: "03/02/2027"
new item, second time click March 3rd, 2027 (it properly picks the 3rd)
- inventory item: "2027-03-03T16:00:00-08:00" -> this converts to my local time but it's the 4th??
- moment as iso string: "2027-03-04T00:00:00.000Z"
- moment formatted as date: "03/03/2027"
So they don't always resolve to the same day, despite appearing as if they are. I don't actually know exactly what is happening to cause the dates to be different. My best guess is it tries to parse "03/03/2027" using system local time instead of UTC.
There was a problem hiding this comment.
I fixed the first issue by defaulting to utc when parsing the string to a moment. The second issue (with the picker selecting the day before) is less obvious of a fix. I'm going to make a separate ticket to track that one though so this PR is ready for review as is.
EDIT: created https://pihemr.atlassian.net/browse/OBPIH-7114 to track the other issue
ewaterman
removed
the
warn: do not merge
awalkowiak
deleted the
bug/OBPIH-7101-cycle-count-expiration-date-validation
branch
3 participants
✨ Description of Change
Link to GitHub issue or Jira ticket: https://pihemr.atlassian.net/browse/OBPIH-7101
Description: The specific issue brought up here is triggered when an existing (non-custom) row has an expiry and you try to add a new, custom row for the same lot and expiry. The error is caused by the fact that InventoryItems use a custom date format which the frontend doesn't use when adding new rows.
InventoryItem.groovy:So when we’re validating in
useInventoryValidation.checkDifferentExpirationDatesForTheSameLot, we get rows that have the same date but in different formats, so it thinks they’re different and throws a validation error:📷 Screenshots & Recordings (optional)