Uploaded image for project: 'FOLIO'
  1. FOLIO
  2. FOLIO-1716

Uniquely identify backend API validation errors

    XMLWordPrintable

Details

    • Core: Platform
    • GBV

    Description

      It seems we have started using code as part of validation error in order to:

      • make decisions based upon the presence of a specific validation error in the client
      • facilitate localization of validation error messages in the client

      See https://github.com/folio-org/raml/blob/raml1.0/schemas/error.schema

      Is this intended to be the standard approach?

      Does the UI currently use some of the existing examples?

      If it is intended to be the standard approach, I believe there are some decisions we could need to make.

      Potential Decisions

      • Should all validation error messages be expected to have a unique code? (and if so, should this be part of the definition of done for backend stories?
      • How should these codes be named?
      • Are codes owned by interfaces or implementing modules?
      • How do we avoid naming conflicts between modules?
      • How does a client know what the set of potential unique errors are?
      • If used for localisation, how does a client map parameterised errors to messages?

      TestRail: Results

        Attachments

          Issue Links

            has to be done before

            Bug - A problem which impairs or prevents the functions of the product. UIU-977 renewal failure messages are not internationalized

            • P4 - lowest priority level, nice-to have things that require future discussion and design
            • Open
            relates to

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-1146 Internationalize back-end failure messages

            • P2 - normal priority level, must be included in the current development cycle
            • In progress

            Task - A task that needs to be done. FOLIO-671 Respond with descriptive information in consistent JSON on bad requests and server errors

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UIREQ-211 Make Request Policy Effective At Request Creation

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Bug - A problem which impairs or prevents the functions of the product. UIREQ-603 Internationalize back-end failure messages

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-476 Blocked patron can successfully place a request

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Task - A task that needs to be done. FOLIO-1965 API design for deletion prevention

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Activity

              People

                Unassigned Unassigned
                marcjohnson Marc Johnson
                Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases