Page Comparison

...

Users need to be able to apply different kinds of overrides in multiple steps. Specifically, override of patron blocks will be added (

...

Endpoints (1-5) should return a full list of blocks that have to be overridden in order for action to be completed. When checking for blocks these processes shouldn't fail immediately when they find the first block. They should check for all blocks instead and include the results in the response. Typically, in case of an error the response structure looks like this:

{
  	"errors" : [ {
    		"message" : "Error message",
    		"parameters" : [ {
      			"key" : "key-1",
      
			"value": "value-1"
		}, {
			"key": "key-2",
			"value": "value-12"
    		}],
		"overridableBlock": {
			"name": "patronBlock",
			"missingPermissions": [
				"circulation... ]
  } ]override-patron-block",
				"circulation.override-item-limit-block"
			]
		}
	}
}

An error needs to be added to the errors field with parameter array containing:

...

overridable error will contain a new property overridableBlock with following properties:

• name - the name of the block, currently one of: "patronBlock", "itemLimitBlock", "itemNotLoanableBlock"
• missingPermissions - array of missing Okapi permissions required to override the block. The user might not have these permissions, but they may want to request permission escalation (

  Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key UXPROD-2645

  ) based on this information.

Non-overridable errors will not contain this new property.

If response contains overridable errors only, the client will know that requested action can be completed by overriding corresponding blocks. Presence of non-overridable errors in the response indicates that there is no point in trying to override the blocks.

Expect a list of blocks that user wants to override

...