Skip to content

Repository files navigation

Alfresco Document Templates

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.

Enable the Document templates module in Alfresco Share

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.

Activate templates for certain content types

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}&amp;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>

Custom templated site contents

  • 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

Publishing

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.

About

No description, website, or topics provided.

Resources

Stars

4 stars

Watchers

25 watching

Forks

Releases

Packages

Used by

Contributors

Languages