Allow custom mapping of request fields to Aeon fields

[ctgraham]

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

Mapping of fields from the ASpace data object to the Aeon form fields is currently hardcoded:

request_broker/process_request/routines.py

Lines 289 to 306 in 75070e5

	parsed.update({
	"CallNumber_{}".format(request_prefix): i["resource_id"],
	"GroupingField_{}".format(request_prefix): i["preferred_instance"]["uri"],
	"ItemAuthor_{}".format(request_prefix): i["creators"],
	"ItemCitation_{}".format(request_prefix): i["uri"],
	"ItemDate_{}".format(request_prefix): i["dates"],
	"ItemInfo1_{}".format(request_prefix): i["title"],
	"ItemInfo2_{}".format(request_prefix): "" if i["restrictions"] == "open" else i["restrictions_text"],
	"ItemInfo3_{}".format(request_prefix): i["uri"],
	"ItemInfo4_{}".format(request_prefix): description,
	"ItemInfo5_{}".format(request_prefix): i["restricted_in_container"],
	"ItemNumber_{}".format(request_prefix): i["preferred_instance"]["barcode"],
	"ItemSubtitle_{}".format(request_prefix): i["parent"],
	"ItemTitle_{}".format(request_prefix): i["collection_name"],
	"ItemVolume_{}".format(request_prefix): i["preferred_instance"]["container"],
	"ItemIssue_{}".format(request_prefix): i["preferred_instance"]["subcontainer"],
	"Location_{}".format(request_prefix): i["preferred_instance"]["location"]
	})

Some assumptions are obvious, like creators to ItemAuthor or dates to ItemDate. Others are arbitrary, however, including all of ItemInfo1 to ItemInfo5. Additionally there may be disparity in whether ItemTitle should represent the object's title or the collection's title.

Describe the solution you'd like

Move this mapping into configuration, preferably with a link to, or duplication of, the ASpace schema as a reference. An example of mapping could be:

ItemVolume=preferred_instance.container
ItemDate=dates

Describe alternatives you've considered

n/a

Additional context

I'm not currently clear on the implications of this with respect to the Grouping/Concatenate/FirstValue settings here:

request_broker/process_request/routines.py

Lines 186 to 205 in 75070e5

	self.request_defaults = {
	"AeonForm": "EADRequest",
	"DocumentType": "Default",
	"GroupingIdentifier": "GroupingField",
	"GroupingOption_ItemInfo1": "Concatenate",
	"GroupingOption_ItemDate": "Concatenate",
	"GroupingOption_ItemTitle": "FirstValue",
	"GroupingOption_ItemAuthor": "FirstValue",
	"GroupingOption_ItemSubtitle": "FirstValue",
	"GroupingOption_ItemVolume": "FirstValue",
	"GroupingOption_ItemIssue": "Concatenate",
	"GroupingOption_ItemInfo2": "Concatenate",
	"GroupingOption_CallNumber": "FirstValue",
	"GroupingOption_ItemInfo3": "FirstValue",
	"GroupingOption_ItemCitation": "FirstValue",
	"GroupingOption_ItemNumber": "FirstValue",
	"GroupingOption_Location": "FirstValue",
	"GroupingOption_ItemInfo5": "FirstValue",
	"UserReview": "No",
	"SubmitButton": "Submit Request",

This also doesn't currently consider other Aeon fields which are sourced from request data, not from ASpace data:

request_broker/process_request/routines.py

Lines 248 to 251 in 75070e5

	"WebRequestForm": "DefaultRequest",
	"RequestType": "Loan",
	"ScheduledDate": request_data.get("scheduledDate"),
	"SpecialRequest": request_data.get("questions"),

These might be considered standard enough not to require configuration settings.

This also might mean moving logic like "" if i["restrictions"] == "open" else i["restrictions_text"] to the get_data method, rather than the parse_items method.

[ctgraham]

I do have a couple of customizations found in non-ASpace data, specifically:

Variability in the default DocumentType (we use "Manuscript"):

request_broker/process_request/routines.py

Line 188 in 75070e5

"DocumentType": "Default",

and in the selected WebRequestForm (we use "GenericRequestManuscript"):

request_broker/process_request/routines.py

Line 248 in 75070e5

"WebRequestForm": "DefaultRequest",

So, request_defaults, reading_room_defaults, and duplication_defaults should probably be considered for localization, either in this issue, or in a new issue.

[helrond]

I think the challenge with mapping is that, as you noted in another issue, the request data is being compiled from the return of get_data rather than the raw ASpace response, which means there are some significant internal that come into play before any potential mapping. Most of these (restrictions, restrictions_text, restricted_in_container) are probably fairly generalized, but there are some specific rules around preferred_instance which might be good to look at...not sure how well those translate across instances. If we need to do some additional configuration there let's open another issue.

I would also suggest making the localization of request defaults a separate issue so we can make sure we've got all the bases covered there.

I think we will want to make the concatenation settings configurable too, either by having a CONCATENATE_FIELDS or FIRST_VALUE_FIELDS config (or both). What we do with that config is another question:

• Tweak the default setters to use that config.
• Move the logic of concatenating/taking first values to this app, rather than relying on Aeon to do it (which we will need to do anyway if we want to submit request via the Aeon API).

[helrond]

Actually, thinking about it more, there is definitely logic which produces the restrictions field which may be particular to the RAC's use cases. So that should be considered in this issue as well.

[ctgraham]

The get_preferred_format function is another instance where institutional preference might differ. For example, our reading room requests would preference materials in the opposite order:

• physical manuscript
• microform
• digital object