[FOLIO-3208] UI modules do not always supply ISO-8601 dates in API requests Created: 16/Jun/21  Updated: 21/Jul/21  Resolved: 21/Jul/21

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: P1
Reporter: Zak Burke Assignee: Zak Burke
Resolution: Done Votes: 0
Labels: i18n
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to STCOR-555 export available numbering systems Closed
relates to UICHKIN-272 return dates must be ISO-8601 formatted Closed
relates to UICHKOUT-732 loan-date must be ISO-8601 formatted Closed
relates to UITEN-181 Set numbering system independent of l... Closed
relates to STCOM-860 Datepicker should always return Arabi... Closed
relates to UID-89 allow users to set numbering system i... Closed
Sprint: Prokopovych - Sprint 117, Prokopovych - Sprint 119, Prokopovych - Sprint 118
Development Team: Prokopovych
Release: R3 2021

 Description   

Overview: UI modules do not supply ISO-8601 dates if the tenant-locale is ar (Arabic).

Details: As noted on Slack, UI apps supply Eastern Arabic numerals in API requests when the tenant API is set to ar.

Steps to Reproduce:

  1. Log into folio-snapshot as a user with permission to (a) check out items and (b) use developer tools to change the session locale
  2. Visit Settings > Developer > Session locale and change the session locale to Arabic
  3. Visit Check out and attempt to charge any item to any active user

Expected Results: Successful check out
Actual Results: Failed checkout due to a 500 from circulation/check-out-by-barcode because of incorrect data in the loanDate field of the POST body:

POST /circulation/check-out-by-barcode
{
  "itemBarcode":"b612",
  "userBarcode":"789",
  "servicePointId":"7c5abc9f-f3d7-4856-b8d7-6712462ca007",
  "loanDate":"٢٠٢١-٠٦-١٦T١٣:٣٠:٢٦Z",
  "id":"02b850d2-9a7b-4ece-b352-43d8a23b90c1"
}

Invalid format: "٢٠٢١-٠٦-١٦T١٣:٣٠:٢٦Z"
java.lang.IllegalArgumentException: Invalid format: "٢٠٢١-٠٦-١٦T١٣:٣٠:٢٦Z"
	at org.joda.time.format.DateTimeFormatter.parseDateTime(DateTimeFormatter.java:945)
	at org.joda.time.DateTime.parse(DateTime.java:160)
	at org.joda.time.DateTime.parse(DateTime.java:149)
	at org.folio.circulation.support.json.JsonPropertyFetcher.getDateTimeProperty(JsonPropertyFetcher.java:92)
	at org.folio.circulation.support.json.JsonPropertyFetcher.getDateTimeProperty(JsonPropertyFetcher.java:85)
	at org.folio.circulation.domain.Loan.getLoanDate(Loan.java:247)
	at org.folio.circulation.resources.CheckOutByBarcodeResource.checkOut(CheckOutByBarcodeResource.java:215)
	at org.folio.circulation.resources.CheckOutByBarcodeResource.lambda$checkOut$12(CheckOutByBarcodeResource.java:133)
	at org.folio.circulation.support.results.Result.after(Result.java:252)
	at org.folio.circulation.resources.CheckOutByBarcodeResource.lambda$checkOut$13(CheckOutByBarcodeResource.java:133)
	at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)

It isn't clear if this is a problem with how

  1. moment is configured in src/loginServices, in which case it's an STCOR bug
  2. timestamps are created in individual apps, e.g. loanDate: moment().utc().format(), in which case it's a per-app bug and we need to file separate tickets for every instance of moment()...format()
  3. both

CC: Owen Stephens



 Comments   
Comment by Zak Burke [ 21/Jul/21 ]

Lots of work farmed out into separate projects here. Of note, STCOM-860 Closed , UICHKIN-272 Closed , and UICHKOUT-732 Closed were legit bugs causing non-Arabic/non-Latn numerals to be present in API requests. STCOR-555 Closed , UITEN-181 Closed , and UID-89 Closed are all just aimed at allowing folks to separate the numeral display (e.g. 0-9) from the locale since some folks using Arabic may not the Arabic-Hindi numerals that are a default for that locale.

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