- v1.0.0-latest-prod
Mappings for customer address fields have been added to CustomerSpecification, and the example import file for customer imports has been updated to include them.
CustomerServices needs to be updated to 1.8.3 in order to actually honor those address fields.
DefaultIndexNotificationService has been modified to not assume a tight coupling between Import.type and BatchIndexableType.
This greatly improves extensibility.
Various methods in DefaultIndexNotificationService and CustomizedImportBatchItemCompletionRepository which previously accepted BatchIndexableType as a parameter have been deprecated and replaced with similar methods that take a String for the value instead.
For backwards compatibility, the deprecated methods are still honored by default.
A new ImportBatchIndexableTypeMapping concept has been introduced, with default implementations CustomerImportBatchIndexableTypeMapping and ProductImportBatchIndexableTypeMapping.
This mechanism enables extensions to directly specify which batch indexable type should be used for a given import without needing to override DefaultIndexNotificationService for each new implementation.
Fixed a bug where sandboxes were being created for imports even when the specification was marked as non-sandbox discriminated.
Initialization of sandbox-related fields has been moved out of DefaultImportManager.generateImportFromRequest()/DefaultImportManager.initializeContextFields(), and is now in a new method DefaultImportManager.initializeImportingSandboxFields(), which is called at a later step.
All sandbox-related fields will only be honored from the import request if the specification supports sandbox discrimination. If it does not, then the system will force-set the values to match a production import.
Fix broken hydration in vendor lookup metadata by using a new API endpoint in VendorServices (fetch vendor by vendor ref). This new endpoint is only available starting in VendorServices 1.6.3, so it is recommended to update to that version. If VendorServices is not updated, then the lookups will continue to behave as they do currently - they will not be any more broken than they are today.
Design around the 'parent entity ID' concept in ImportServices has changed in this release.
Previously, the behavior was to honor the parentEntityId field in the ImportRequest if provided, and if not available, GlobalImportSpecifications could define a dedicated 'parent entity ID header' in the file which DefaultImportManager would get the value from.
The value would only be sourced from the first row of the file.
With the new changes, the concept of a 'parent entity ID' header in the file is deprecated.
Going forward, parentEntityId will only be sourced from the value in the ImportRequest and nowhere else.
From a code perspective, the 'parent entity' concepts have been deprecated/decoupled from GlobalImportSpecification.
This greatly simplifies UX and reduces user and developer confusion.
Details on how the new configuration works and can be used are provided in this documentation.
(soft breaking change) SkuInventoryImportSpecification is now a GlobalImportSpecification and will now fail if parentEntityId is not supplied in the import request
Despite technically being a 'breaking' change, it should not have any effect on most clients:
Most clients will not have customized this behavior
This validation is aligned with expectations that are already implicitly present. For example, the inventory import grid action already sends the parent information in requests.
Introduce a new ImportRequestParentEntityLookupContributor admin metadata concept to allow parent entity ID to be supplied in imports submitted from the central import maintenance screen.
Introduce default implementations of ImportRequestParentEntityLookupContributor for all out-of-box imports that currently leverage the 'parent entity ID' concept
Update example files for the following imports to clarify parent entity ID requirements: customer segment member, campaign code, offer code, standard/sale/contract price data
Introduce new metadata message properties to support all the new fields (import.fields.parent-entity-id.*, etc)
Introduce a new parentEntityIdRequiredInRequest() method to ImportSpecification, and deprecate the various parent entity related methods in GlobalImportSpecification.
Update the DefaultImportManager and DefaultImportValidator implementations to honor the deprecated methods for backwards compatibility, and also introduce logic to support the new method.
Add and clarify Javadocs for all relevant methods/fields
Update import details view metadata to surface the parent entity ID field and all importing context fields