Allow for customization of whether request items are submittable

[ctgraham]

Is your feature request related to a problem? Please describe.

Currently, logic is hardcoded to enforce certain criteria which makes a item ineligible for submission:

request_broker/process_request/routines.py

Lines 88 to 112 in 75070e5

	def is_submittable(self, item):
	"""Determines if a request item is submittable.
	Args:
	item (dict): request item data.
	Returns:
	submit (bool): indicate if the request item is submittable or not.
	reason (str): if applicable, a human-readable explanation for why
	the request is not submittable.
	"""
	submit = True
	reason = None
	if not any(value for value in item["preferred_instance"].values()):
	submit = False
	reason = "This item is currently unavailable for request. It will not be included in request. Reason: Required information about the physical container of this item is not available."
	elif item["restrictions"] == "closed":
	submit = False
	reason = "This item is currently unavailable for request. It will not be included in request. Reason: {}".format(item.get("restrictions_text"))
	elif "digital" in item["preferred_instance"]["format"].lower():
	submit = False
	reason = "This item is already available online. It will not be included in request."
	elif item["restrictions"] == "conditional":
	reason = "This item may be currently unavailable for request. It will be included in request. Reason: {}".format(item.get("restrictions_text"))
	return submit, reason

Specifically:

• Closed/Conditional access
• Digitized version available
• No preferred instance available

all map to submit = false. We would like patrons to be able to ask for anything, with mediation by staff to negotiate the best method of delivery, if one exists.

Others might have differing interest, such as allowing for conditional restrictions, but disallowing closed restrictions.

Describe the solution you'd like

For each criteria, allow the submit flag to be configurable.

Describe alternatives you've considered

There might be cause for some form of configurable rules-based processing where someone could define their own business logic for certain data conditions. This simpler approach can work for now.

Additional context

This may relate to a DIMES feature request to soften the warning message if an item comes with restrictions_text, but a submittable status.

[helrond]

I've been waiting for this one :)

This is one of those areas where functional requirements were entirely based on local requirements, and I anticipated that this area of the application would need to be addressed.

We would like patrons to be able to ask for anything, with mediation by staff to negotiate the best method of delivery, if one exists.

This makes it sounds to me like you want to disable behavior in DIMES, rather than tweaking Request Broker logic AND that some of our assumptions about retrievable formats may not be all that generalized (see my comment on #228). I still think it makes sense to give some thought to the is_submittable logic in this app, all I'm saying is this might be worth considering on a broader scale.

Are there any other reasons you might not want something to be submitted that we'd want to include in the is_submittable method or do you always want people to submit and then have your staff sort it out?

[ctgraham]

Currently, A&SC would like patrons to always be able to submit requests and have staff sort it out. I reserve their right in the future to re-evaluate that decision; for example, the millionth time we get asked to view a fragile material in the reading room which we have already digitized.

[helrond]

Do you have an opinion on simply adding a boolean config that overrides is_submittable in its entirety, rather than a whole bunch of configs which override specific behavior within is_submittable? I'm just trying to weigh the pros and cons of a whole bunch of new configs in service of use cases we can only guess at.

[ctgraham]

Here is a new consideration we have been discussing recently in the ULS.

We would like to maintain informational restrictions notes at the collection level describing restrictions in the collection. Specific restricted items would have their own access restrictions flag and note.

So, we would hope for is_submittable to be able to be configured to return only the "restricted_in_container" text as the reason not the whole "restrictions" text. That is, we would not display the full concatenation of all restrictions to the end user in DIMES, but only the restrictions which apply to the items in the container of interest.