I am using Alfresco Community 5.2. I used Alfresco Maven SDK 3.0 to generate AMPs for the repository tier and share UI tier. I did customization in the share config custom XML, etc.
I have one base type, say A, which has the cm:content as its parent. Then the custom type A has 7 subtypes. This hierarchy is defined in the model xml.
Now in the try-out alfresco tomcat while doing customization, I see type A as one of the options, when I click on the uploaded image and click "Change Type". But in this try-alfresco-tomcat, I still do not see my other subtypes in the Change Type options.
Should I do anything special for the subtypes as opposed to the main custom type?
Then, in the Community 5.2 Alfresco Server, even after applying the generated AMPs, neither the base type nor any of the sub types I could see in the options of the Change Type control.
Is there anything else that I need to do besides putting the AMPs in the appropriate folders and do applyamps.bat.
To see the change type option for your custom types, you have to add config like this in share config custom:
<config evaluator="string-compare" condition="DocumentLibrary">
<types> <type name="cm:content"> <subtype name="demo:yourCustomTypeA"/> <subtype name="demo:yourCustomTypeB"/> ...... </type> <type name="demo:yourCustomTypeA"> <subtype name="demo:yourCustomTypeB"/> </type> <type name="demo:yourCustomTypeB"> <subtype name="demo:yourCustomTypeA"/> </type> ......... </types> </config>
See a discussion here on similar topic: https://hub.alfresco.com/t5/alfresco-content-services-forum/specialize-type/m-p/302889#M21866
Now, just by ading the config you will start seeing the option to change the type in Change Type menu. But it will not work unless you customize the the Change Type webscript.
Here you have find a complete step by step process to do that:
https://javaworld-abhinav.blogspot.com/2020/06/change-type-of-custom-content-types.html
demo:yourCustomTypeA, is the parent of demo:yourCustomTypeB, and has cm:content as its parent
demo:yourCustomTypeB is not the parent of demo:yourCustomTypeA
In the model definition, I have this way
<types> <type name="demo:yourCustomTypeA"> <title>Base Document Type</title> <parent>cm:content</parent> <associations/> <mandatory-aspects> <aspect>demo:yourCustomAspect</aspect> </mandatory-aspects> </type> <type name="demo:yourCustomTypeB"> <title>Board Meeting Agendas</title> <parent>demo:yourCustomTypeA</parent> <properties/> <associations/> </type> </types>
This is the configuration for "string-compare" in the share-config-custom.xml
<config evaluator="string-compare" condition="DocumentLibrary"> <aspects> <visible> <aspect name="demo:yourCustomAspect"/> </visible> <addable></addable> <removeable></removeable> </aspects> <types> <type name="cm:content"> <subtype name="yourCustomTypeA" /> <subtype name="yourCustomTypeB" /> </type> <type name="demo:yourCustomTypeA"> <subtype name="demo:yourCustomTypeB"/> </type> <type name="demo:yourCustomTypeB"> <subtype name="demo:yourCustomTypeA"/> </type> </types> </config>
My question is -
Why would we have to say A's subtype as B, and B's subtype as A?
Would not saying A's subtype as B sufficient?
I have a rule defined at a folder folderB, which would specialize the type of the document that gets created in this folder to yourCustomTypeB.
What happens is, when I do edit properties on a document in folderB, I only see the properties that belong to the aspect yourCustomAspect, and not of type cm:content. For example, I am not seeing name, title or description properties at all to edit.
I could not reason out how and why this is happening
Only for the base type demo:yourCustomTypeA, I have "node-type" config defined in the share-config-custom.xml
I thought defining for the parent would be used for sub type.
Should I define "node-type" separtely for demo:yourCustomTypeB as well?
<config evaluator="node-type" condition="demo:yourCustomTypeA"> <forms> <!-- Default form configuration for the cm:content type --> <form> <field-visibility> <show id="cm:name"/> <show id="cm:title" force="true"/> <show id="cm:description" force="true"/> ... </field-visibility> <appearance> <field id="cm:name"> <control> <control-param name="maxLength">255</control-param> </control> </field> <field id="cm:title"> <control template="/org/alfresco/components/form/controls/textfield.ftl"/> </field> ... </appearance> </form> <!-- Document Library pop-up Edit Metadata form --> <form id="doclib-simple-metadata"> <field-visibility> <show id="cm:name"/> <show id="cm:title" force="true"/> <show id="cm:description" force="true"/> ... </field-visibility> <edit-form template="../documentlibrary/forms/doclib-simple-metadata.ftl"/> <appearance> <field id="cm:name"> <control> <control-param name="maxLength">255</control-param> </control> </field> <field id="cm:title"> <control template="/org/alfresco/components/form/controls/textfield.ftl"/> </field> ... </appearance> </form> <form id="doclib-inline-edit"> <field-visibility> <show id="cm:name"/> <show id="cm:content" force="true"/> <show id="cm:title" force="true"/> ... </field-visibility> <appearance> <field id="cm:name"> <control> <control-param name="maxLength">255</control-param> </control> </field> <field id="cm:title"> <control template="/org/alfresco/components/form/controls/textfield.ftl"/> </field> </appearance> </form> </forms> </config>
You don't have to do that, as mentioned earlier type/subtype mapping depends on content model definition. In this case this would be ideal case:
<config evaluator="string-compare" condition="DocumentLibrary"> <aspects> <visible> <aspect name="demo:yourCustomAspect"/> </visible> <addable></addable> <removeable></removeable> </aspects> <types> <type name="cm:content"> <subtype name="yourCustomTypeA" /> </type> <type name="demo:yourCustomTypeA"> <subtype name="demo:yourCustomTypeB"/> </type> </types> </config>
A suggestion, i would recommed to not to create very deep nesting. That "may" cause performance issues while searching. 1-2 level is ok.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.