Uploaded image for project: 'ui-inventory'
  1. ui-inventory
  2. UIIN-2322

No error message when trying to save a value with 'null'; e.g. as seen in Statistical code field on an holdings, instance, and item record



    • Bug
    • Status: Closed (View Workflow)
    • P3
    • Resolution: Done
    • None
    • 9.3.0
    • Prokopovych - Sprint 158, Prokopovych - Sprint 159, Prokopovych - Sprint 160, Prokopovych - Sprint 161
    • Prokopovych
    • Orchid (R1 2023) Bug Fix
    • !!!ALL!!!
    • Incomplete/missing requirements



      Several data properties, in Inventory (instance, holdings, item) and maybe in more apps (but this has not been investigated further), here properties with value 'null' can be saved, without an error message is displayed.

      E.g.: When editing an item record if the use clicks on 'Add statistical code' a null statistical code is added to the item record. If the user does not remove this code nor selects an option form the dropdown the save fails silently in the background.

      The save response returns with code 422 with the following payload:

               "message":"elements in list must match pattern",
               "code":"elements in list must match pattern",

      Steps to Reproduce:

      1. Log into some FOLIO environment as User X
      2. Open an item record in edit mode.
      3. Click on 'Add statistical code'; do not select and option
      4. Click on "Save and close'

      Expected Results:
      A toast should appear indicating that the statistical code can not be blank. 
      The statistical code field should be in error. Red box with an error message below.

      Actual Results:
      The request fails silently in the background and the item stays on the edit screen.

      Additional Information:
      zburkeZak_Burke added a comment (2/6/2023)
      Anya Arnold: while the problem may be a "wider issue with FOLIO", there is not a "one stop shop" fix. Essentially, any given request may succeed or fail, and the problem is that some request-handlers do not check the response status to make sure it is successful. IOW, the "problem" is not with particular code but with a particular pattern.

      That is the case here in src/Item/EditItem/EditItem.js and src/Item/CreateItem/CreateItem.js: both use the useItemMutation hook but fail to either (a) pass an onError callback to the hook or (b) provide a catch clause when calling mutateItem.
      Interested parties:
      tomt92 enettifee Anya N. Arnold

      TestRail: Results


          Issue Links



                mpk35 Michal Kuklis
                tomt92 Thomas Trutt
                Charlotte Whitt Charlotte Whitt
                0 Vote for this issue
                7 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases