nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Problem displaying properties of custom space type

ero

Hi,

I defined some custom space type (my:customspace with parent type cm:folder).

Problem:
When I customize web client UI to display my:customspace custom properties, I'm unable to force web client to display parent cm:folder properties in the same order as its parent type.

For some space created as cm:folder, properties are displayed by web client in following order:
NameTitleDescription CreatorCreated DateModifierModified Date

For some space created as my:customspace, properties are displayed by web client in following order:
CreatorCreated DateModifierModified DateNameTitleDescription

Note:
My <config evaluator="node-type" condition="my:customspace"> is declared at first place in web-client-config-custom.xml as follows:
      <property-sheet>
        <show-property name="cm:name"/>
        <show-property name="cm:title"/>
        <show-property name="cm:description"/>
        <show-property name="app:icon" show-in-view-mode="false" display-label-id="icon" component-generator="SpaceIconPickerGenerator"/>
      </property-sheet>

How are managed priorities to display properties in web client UI?
Why "cm:auditable" aspect properties are they displayed before custom space properties (Name) type and "cm:titled" aspect properties (related to "app:uifacets" aspect) displayed after?

Thank's for help.

Find more posts tagged with

Comments

ero

I forgot to say that

<show-property name="app:icon" show-in-view-mode="false" display-label-id="icon" component-generator="SpaceIconPickerGenerator"/>
</property-sheet>

doesn't work!

It displays only one (default) folder icon (folder as been created with "star" icon) !!

Thank's

gavinc

Hi,

The order is determined by the order the config files are loaded and the order of the property sheet elements inside each config file.

As the web-client-config-custom.xml file is loaded last (this is how we can provide the override capabilities) any properties defined in here will appear last. As you've pointed out cm:auditable properties appear first, this is becuase they are defined in web-client-config-properties.xml which gets loaded before web-client-config-custom.xml.

We will probably add a way to include parent properties in the future but at the moment only exact matches for "node-type" are used.

One way you can get around this is to load a custom config file containing the properties before any of our files. To do this you will need to override the spring bean definition for the config service, have a look at: http://wiki.alfresco.com/wiki/Web_Client_Configuration_Guide#Multiple_Config_Files

As for the second issue, I think it is due to the fact that you haven't supplied a list of icons for your custom folder/space type.

In web-client-config.xml you'll find a section beginning:

<config evaluator="string-compare" condition="cm:folder icons">‍

This has a list of the icons to show when creating spaces, if you copy this section and paste it in your web-client-config-custom.xml and change cm:folder to be my:customspace i.e.

<config evaluator="string-compare" condition="my:customspace icons">‍

Is this what you meant? or do you have a different issue?

ero

Hi Gavin,

Thank's for information.
I understand what you say but I can't understand why cm:titled aspect properties (cm:title and cm:description) are not managed like e.g. cm:auditable aspect properties.
We find <show-property name="description" or "title"/> everywhere in XML config file.
Are they or not related to cm:titled aspect ?
If not, where are they coming from?
If yes, how can you explain that these aspect properties are mixed with type properties in "node-type" <property-sheet> sections ?
Why not define only one <property-sheet> for cm:titled aspect ?

Regards.

gavinc

Ok, good question.

When content and folders are created outside of the web client i.e. via CIFS, WebDAV or FTP, the titled aspect is not added by default.

This means when the client encounters nodes that have been added this way the title and description properties are missing. As there is no aspect either if the properties were defined in a config section for cm:titled they would never get found.

Therefore, title, description and app:icon are all registered against the base node type so that we can use the new property sheet attribute "ignore-if-missing", this will always force the properties to show and hence when the user presses OK the properties get set and the titled aspect added.

However, you're right we could also specify them in a config section for cm:titled, that would at least make the properties appear first for subtypes as in your scenario.

gavinc

We have added the cm:titled aspect property configuration to web-client-config-properties.xml. This means that you should now see the name, title and description fields at the top of the property sheet when you have a custom type.

However, they still remain in the 'node-type = content' section to cover the CIFS/FTP scenario I mentioned above.

In the future we'll support inheritance lookups for property configuration so you won't need to re-define properties for super types again for all your custom types.

kevinr

We have added the cm:titled aspect property configuration to web-client-config-properties.xml. This means that you should now see the name, title and description fields at the top of the property sheet when you have a custom type.

In the future we'll support inheritance lookups for property configuration so you won't need to re-define properties for super types again for all your custom types.

Due to the fact that inheritance lookups are not working for Aspect and Node Type config matches, this change does not actually fix the problem ERo mentions. I now have fixed the Aspect config evaluator class to correctly match inherited aspect types which solves your issue correctly - this will be available in the next 1.3 drop.

Thanks,

Kevin