SmartEdit Nested List of Components Throwing 'catalogVersion must not be null or empty' Error

[joschong]

We are using SAP Commerce v1811. In SmartEdit (both Basic and Advanced Edit), when we click to edit a component that has a nested list of components as one of its fields, we receive 'catalogVersion must not be null or empty' errors matching the number of components in the list.

Console log:

Hybris log:

INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | ERROR [hybrisHTTP33] [10.251.144.45] [RestHandlerExceptionResolver] java.lang.IllegalArgumentException: catalogVersion must neither be null nor empty
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cms2.servicelayer.daos.impl.DefaultCMSItemDao.findByUid(DefaultCMSItemDao.java:54)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cms2.servicelayer.services.admin.impl.DefaultCMSAdminItemService.findByUid(DefaultCMSAdminItemService.java:60)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cms2.servicelayer.services.admin.impl.DefaultCMSAdminItemService.findByUid(DefaultCMSAdminItemService.java:79)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cmsfacades.uniqueidentifier.functions.DefaultCmsItemModelUniqueIdentifierConverter.findItemById(DefaultCmsItemModelUniqueIdentifierConverter.java:107)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cmsfacades.uniqueidentifier.functions.DefaultCmsItemModelUniqueIdentifierConverter.convert(DefaultCmsItemModelUniqueIdentifierConverter.java:86)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cmsfacades.uniqueidentifier.functions.DefaultCmsItemModelUniqueIdentifierConverter.convert(DefaultCmsItemModelUniqueIdentifierConverter.java:1)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cmsfacades.uniqueidentifier.impl.DefaultUniqueItemIdentifierService.lambda$4(DefaultUniqueItemIdentifierService.java:108)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at java.util.Optional.map(Optional.java:215)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cmsfacades.uniqueidentifier.impl.DefaultUniqueItemIdentifierService.getItemModel(DefaultUniqueItemIdentifierService.java:107)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cmsfacades.uniqueidentifier.impl.DefaultUniqueItemIdentifierService.getItemModel(DefaultUniqueItemIdentifierService.java:151)
INFO   | jvm 1    | main    | 2020/04/30 16:55:44.653 | 	at de.hybris.platform.cmswebservices.interceptor.CatalogVersionPermissionInterceptor.preHandle(CatalogVersionPermissionInterceptor.java:64)

This only occurs for components with fields that are lists of components with an unspecified capacity. The .jsp files for these components use a <c:forEach items="${component.components}" var="componentName"> tag for the lists. Regular nested components which take up singular slots do not throw any errors.

Additionally, it affects functionality, but only partially. Both the parent component as well as the child components in the list are accessible and editable. However, if we modify a component in the nested list and then directly after saving modify the parent component, the first change will be lost. Each change to any 'level' of the hierarchy must be followed by exiting out of all editing windows in order for the change to take effect.

Any help would be appreciated.

[former_member732335]

Hi joschong,
did you manage to resolve this issue ?
I have the same problem with v 19.05

[joschong]

Hi bogdan.zdr, I know this is long overdue but leaving the answer here for anyone else who may be curious. The issue was due to the nested list of components being implemented through a relation. We changed it to use a collectiontype instead and it resolved the issue. You lose the bidirectional reference, but in our case we didn't need it.