- v1.0.0-latest-prod
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.
Fix an issue where implicit catalogs for profiles did not have the correct Catalog.type set upon creation
Various gaps in validation logic have been closed to ensure API/Admin requests cannot create invalid state
Updated MarketplaceApplicationCatalogValidator for validations on MarketplaceApplicationCatalog
Prevent assigning the same vendor catalog to a marketplace application more than once
Prevent marketplace assignment of non-product type catalogs (i.e. disallow assignment of profiles)
Metadata for marketplace catalog lookups was also updated to implicitly filter to product-type catalogs
Updated CatalogValidator for validations on Catalog
Prevent mutation of the vendorRef field on Catalog after creation
Reject assignment of parent catalogs that cannot be found in the database
Prevent vendor catalogs from being parents of other catalogs
Only allow a vendor catalog to have a non-vendor parent with mutability type REFERENCE
Ensure Catalog.type is required and immutable
Prevent the creation of non-product type vendor catalogs (i.e. disallow creation of vendor profiles)
Updated ApplicationValidator for validations on Application
Guarantee all requested isolated catalogs exist and are non-vendor catalogs
Metadata for isolated catalog lookups was also updated to implicitly filter to non-vendor catalogs
Updated the MarketplaceApplicationCatalog business domain to surface vendorRef as a read-only field.
This allows API callers to now directly see what vendor the relationship is for rather than having to look up the catalog and examine its vendor.
Updated metadata to allow creation and management of vendor catalogs through the admin
Catalog browse grid now has a vendorRef column
Catalog create form now has a field to select and set a vendor on the catalog. The same field is exposed on the edit form as read-only (since the value is always immutable).
Updated metadata to surface the vendorRef field on MarketplaceApplicationCatalog in the admin
Marketplace application catalog browse grid now has a vendor column
Marketplace application catalog edit form now has a read-only vendor field
Updated TenantVendorNotificationHandler to set newly-created vendor catalog IDs as the MD5 hex string of {vendorRef}-{tenantId}.
This replaces the prior behavior of directly using vendorRef as the catalog ID, though the logic will remain backwards compatible for existing catalogs.
These changes are necessary to account for potentially long vendorRef values.
Introduced a new readByVendorRef() method to MarketplaceApplicationCatalogService
Updated TenantVendorNotificationHandler such that on vendor archival, it will find all MarketplaceApplicationCatalog entities for it by searching on vendorRef instead of checking the catalog ID.
Now, all MarketplaceApplicationCatalog entities for a vendor will be deleted instead of just those for the system-generated catalog.
Added a new property broadleaf.tenant.vendor-notification-handler.enable-auto-catalog-marketplace-assignment to disable behavior around automatic marketplace assignment
Updated DefaultMarketplaceDiscoverer to only return a marketplace ID for automatic vendor catalog assignment if there is only one marketplace in the system.
If zero or multiple marketplaces are detected, it will return nothing.
This makes the behavior more deterministic in multi-marketplace situations.