Page Comparison

...

Users need to be able to apply different kinds of overrides in multiple steps. Specifically, override of patron blocks will be added (https://issues.folio.org/browse/

...

1. POST /circulation/check-out-by-barcode
2. POST /circulation/override-renewalrenew-by-barcode
3. POST /circulation/renew-by-id
4. POST /circulation/requests
5. PUT /circulation/requests

...

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"
    }, ... ]
  } ]
}

Two parameters need to be added to the parameters array:

...

		}],
		"overridableBlock": {
			"name": "patronBlock",
			"missingPermissions": [
				"circulation.override-patron-block",
				"circulation.override-item-limit-block"
			]
		}
	}
}

An 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 System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc 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

...

"overrideBlocks": {
    "description": "Blocks that need to be overridden",
  
  "type": "object",
  "properties": {
    "itemNotLoanableBlock" : {
      "description": "Parameters for overriding of the 'item not loanable' block",
      "type": "arrayobject",
  "items":{
    
      "properties": {
        "dueDate": {
          "description": "Due date for a new loan",
          "type": "string",
    "enum": [
      "patron-limit",
      "item-limit",
      "item-not-loanable"
    ]
  
          "format": "date-time"
        }
      },
      "required": [
        "dueDate"
      ]
    },
    "patronBlock": {
      "description": "Parameters for overriding of the patron block",
      "type": "object",
      "properties": {
        ...
      }
    },
    "itemLimitBlock": {
      "description": "Parameters for overriding of the 'item limit' block",
      "type": "object",
      "properties": {
        ...
      }
    }
  }
}

List of the appropriate blocks and their parameters may be dependent on the endpoint.

In case when this parameter is included in the request, the server should override all of the specified blocks if the user has sufficient permissions.

Managing permissions

Each overridable action will be associated with a user permission that is required in order to override this action. These permissions need to be part of permissionsDesired rather than permissionsRequired which will allow to handle them in the code. For example, new permissions for POST /circulation/check-out-by-barcode:

"permissionsDesired": [
  "circulation.override-patron-block",
  "circulation.override-item-limit-block",
  "circulation.override-item-not-loanable-block"
]