With this addon enabled the user can when creating content choose from a set of predefined templates residing in either the data-dictionary/node-templates folder or in a special template-library site.
Built on Alfresco SDK 4.16.0 against ACS 26.1. Requires JDK 21.
Both modules build as a JAR and an AMP. Traditional Tomcat installs accept either; the Docker modules pick up the AMPs.
To bootstrap the template-library site the property template-site.disabled in alfresco-global.properties needs to be set to false.
Default values are:
template-site.bootstrap.disabled=true
template-site.path=alfresco/module/document-templates-repo/context/bootstrap/template-site/content.acp
template-site.name=template-library
template-site.preset=template-library
template-site.bootstrap.user=admin
template-site.bootstrap.user is the account the bootstrap patch authenticates
as. The site service checks permissions even when the patch runs as system, so
override this if the admin account has been renamed.
To enable the possibility to pick a template for alfresco datatypes this module needs to be enabled in share. Navigate to http://[your-host]:[port]/share/page/modules/deploy and enable the "Redpill Linpro Default Document Templates" module.
To activate a document template for a content type (for example cm:content) edit your share configuration files. See example in alfresco-document-templates-extension.xml file.
<extension>
<modules>
<module>
<id>Redpill Linpro Default Document Templates</id>
<auto-deploy>false</auto-deploy>
<version>${project.version}</version>
<configurations>
<config evaluator="string-compare" condition="DocumentLibrary">
<create-content>
<content id="content" label="create-content.document" type="pagelink" index="6" icon="text">
<param name="page">create-content?destination={nodeRef}&itemId=cm:content</param>
</content>
</create-content>
</config>
<config evaluator="model-type" condition="cm:content">
<forms>
<!-- Default Create Content form -->
<form>
<field-visibility>
<show id="cm:name" />
<show id="cm:title" force="true" />
<show id="cm:description" force="true" />
<show id="rplpdt:template" 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>
<!-- This field is used to control document templates for this type. A temporary aspect attached to the node when created and cleared by a formfilter afterwards -->
<field id="rplpdt:template" mandatory="true">
<control template="/org/redpill_linpro/alfresco/share/components/form/controls/documenttemplate.ftl" />
</field>
</appearance>
</form>
</forms>
</config>
</configurations>
</module>
</modules>
</extension>
To configure which folder to pick templates from (default is Data Dictionary/Node Templates). Edit your share-config-custom.xml file for your installation and add the following config section:
<alfresco-config>
...
<config evaluator="string-compare" condition="DocumentTemplates" replace="true">
<!-- Defaults to the Node templates directory in the data dictionary -->
<templates-folder-path>/app:company_home/app:dictionary/app:node_templates</templates-folder-path>
<!-- If the template-library site patch is activated the templates are choosen like below. -->
<templates-folder-path>/app:company_home/st:sites/cm:template-library/cm:documentLibrary/cm:document-templates</templates-folder-path>
</config>
...
</alfresco-config>
- Bootstrap the template site
- Add files, folders and/or rules to the site
- Export the site using
http://[your-host]:[port]/alfresco/s/api/sites/template-site/export - Unzip the file and add the exported acp-file to a custom location and configure it with
template-site.path=alfresco/module/document-templates-repo/context/bootstrap/template-site/content.acp
Artifacts go to the GitLab Package Registry under the alfresco-dependency
group. Two endpoints are involved and they are not interchangeable:
| Endpoint | Used for | |
|---|---|---|
| Project | /api/v4/projects/3925/packages/maven |
Publishing (mvn deploy) |
| Group | /api/v4/groups/2746/-/packages/maven |
Resolving dependencies |
The group endpoint aggregates every project below it, so a single repository
entry in settings.xml covers all packages the group will ever hold. You
publish into one project; everyone resolves from the group.
First time setup. Create a Personal Access Token with scope api, then
copy the blocks from settings.xml.example into your
~/.m2/settings.xml.
The scope must be api. write_repository covers git push over HTTPS, not
the package registry, and read_api alone only reads — a token with those two
resolves dependencies fine and then fails on deploy with insufficient_scope,
which Maven reports as a bare 400 Bad Request with no explanation.
Do not use a group deploy token either — those return 404 against the group Maven endpoint, a known GitLab bug that presents as a missing artifact.
Publishing.
JAVA_HOME=/usr/lib/jvm/java-21-openjdk mvn deploy
The target project is set by gitlab.project in the root pom.xml. It must
be the numeric project id, not the path: Maven's HTTP client decodes %2F
back into a slash before sending, so a URL-encoded project path arrives as
/projects/alfresco-dependency/alfresco-document-templates/... and GitLab
answers 400 Bad Request. The id is on the project's overview page.
GitLab uses the same URL for releases and snapshots — the version suffix decides which you get. Snapshots can be overwritten; releases cannot.
Note on browsing. Opening the Maven endpoint in a browser always returns
404 Not Found, even when packages exist. It is not an index — Maven appends
the artifact path to it. To see what is actually published, use
/api/v4/groups/2746/packages or the Packages page in the GitLab UI.