MODEXPW-638 - Resolve PO and PO line custom fields in the order email export - #749
Open
markusweigelt wants to merge 8 commits into
Open
MODEXPW-638 - Resolve PO and PO line custom fields in the order email export#749markusweigelt wants to merge 8 commits into
markusweigelt wants to merge 8 commits into
Conversation
Turn the raw refId-to-value maps on purchase orders and PO lines into template-ready custom-field tokens, resolving select option-ids to labels via a cached definitions lookup targeted at mod-orders-storage. Degrade gracefully to an unresolved-token-free email when the interface is absent.
Point the submodule at the commit that exposes customFields on the purchase order and PO line schemas, and track branch MODEXPW-638.
The custom-fields interface is interfaceType:multiple, so the gateway routes it on the exact versioned module id. Resolve that id per tenant from entitlements (scoping cross-tenant responses via the tenant name) instead of a hardcoded value, and make the definitions cache tenant-aware.
# Conflicts: # folio-export-common
The custom fields services, clients, DTOs and their tests ended without a trailing newline, producing "No newline at end of file" markers in every diff. Whitespace only, no behaviour change.
The merge from master had reset the submodule pointer to a commit without customFields, so OrderEmailContextMapper no longer compiled. Point it back at the branch commit that exposes the map on purchase order, composite purchase order and PO line.
The entry named a permission mod-orders-storage does not define (orders-storage.custom-fields.collection.get) and sat on the _tenant handler, which does not cover Kafka-triggered jobs. The permission belongs to the token minted by mod-data-export-spring.
The lambda held three invocations that could throw, so a failure would not prove result.put was the source of the UnsupportedOperationException.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MODEXPW-638 - Resolve PO and PO line custom fields in the order email export
Purpose
Order email templates could not reference PO / PO-line custom fields. The records carry them only as a raw
refId→ value map, where selects store bare option-ids (opt_3) — unusable in a template, since neither the field's display name nor the option's label is present. This makes custom fields available as resolved tokens (order.customFields.<refId>/orderLine.customFields.<refId>) with names and option labels filled in.Approach
OrderEmailContextMapperfeeds the raw maps from the purchase order and each PO line through the newCustomFieldsService, which pairs values with their definitions: select option-ids become{ id, label }, checkboxes stay boolean, textbox/date/number become strings, multi-value fields land invalues[]. Hidden fields (visible: false), unknown refIds and null values are dropped, so templates never see unresolved tokens.CustomFieldDefinitionServicefetches and caches definitions perentityType(purchase_order,po_line), so a job makes at most two calls. Values themselves ride the existing/purchase-orders+/po-linesfetch: no extra HTTP per order.OrdersStorageModuleIdResolverderives the versioned mod-orders-storage module id per tenant from the entitlements API (scoping cross-tenant responses via the tenant name) andCustomFieldsClientsends it asX-Okapi-Module-Id. The definitions cache is tenant-aware.custom-fields.collection.getadded to the module's modulePermissions.OrderEmailContexttree, the null/empty policy note and the example payload document thecustomFieldsshape for template authors.Depends on
folio-org/folio-export-common#112