Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

We currently have a multiple approaches on when the validations should be shown on our table forms (Requisition View, Proof of Delivery View, Shipment View, Adjustment, Issue and Receiver screens). All validation are fired with a slight delay due to the debounce setting we're using. This was done to improve the performance.

...

Example: Batch Approval screen

Recap

#OptionLevel of EffortUser Benefit

Performance Impact
Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected
1Mimic what the other forms do.SmallConsistency across the whole systemNone


  • View Proof of Delivery
  • View Requisition
  • View Shipment
  • Issue
  • Receive
  • Physical Inventory
  • Adjustments
  • Batch Approval
2Make errors appear after the fields has been touched.MediumInstant error feedbackNone
  • View Proof of Delivery
  • View Shipment
  • Batch Approval
3Make errors appear after we leave  (focus on something outside) the table row.LargeWhen fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)None
  • View Requisition
  • Issue
  • Receive
  • Physical Inventory
  • Adjustments

But, this approach will also require changing how pagination shows the page errors, it now is inconsistent with this approach and might require noticeable amount of work to make it happen

4Same as 3, but also highlight the table header.LargeWhen fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)None
  • View Proof of Delivery
  • View Requisition
  • View Shipment
  • Issue
  • Receive
  • Physical Inventory
  • Adjustments

Programming approaches

Currently we have a couple of different approaches on how to deal with validations from the coding side.

...