Skip to main content

​
Reference a template in another project

Checklist templates normally live in the same project as the object that uses them. To point at a template stored in a different project, prefix the template ID with the source project ID and a colon:

​
Work item templates

  1. Open Administration > Nextedy CHECKLIST in the project where the checklist is used (the consuming project).
  2. Add a configuration property in the form:
    For example, to reuse a chkApproved checklist template stored as WI-124 in project myOtherProject for the requirement type:
  3. Save the property.

​
Document (LiveDoc) templates

Use the equivalent documentTemplateId property, with the shared-project path pointing at a space/document location in the other project:
The value after the colon is the space/document name path inside the target project, not a work item ID. At resolution time, the consuming project’s documentTemplateId property is read and followed across the project boundary to the named space and document in the source project, which then acts as the checklist template source.
Cross-project document templates are not confirmed to resolveThere is a known case where a cross-project documentTemplateId pointed at a document template in another project and, although the path was configured correctly, the checklist content did not appear. No fix or root cause has been confirmed for it. The PROJECTID:TEMPLATEID syntax is documented and known to work for work item templates; treat cross-project document templates as unverified until you confirm the behavior in your own Polarion instance.

​
Verify project-level scope

Configuration properties are set per project. If you copy a document template (or an entire document type configuration) into a new project, the documentTemplateId / workItemTemplateId properties do not travel with it automatically — you must re-add the relevant nextedy.checklist.* properties in each target project.
Document templates reused across projects need per-project setupWhen document templates are reused across projects, the checklist template / document-type mapping is not automatically shared — each project that uses the reused document template needs its own nextedy.checklist._TYPEID_._FIELDID_.documentTemplateId (or workItemTemplateId) property configured in Administration > Configuration Properties. Plan for this step whenever you copy or replicate a document template between projects.

​
Combine with per-type or per-field targeting

The same property hierarchy used for local templates applies to shared templates — you can scope the pointer by type, field, or both, exactly as you would for a template inside the same project:
See Create a Checklist Template for the full property hierarchy and how type/field scoping is resolved, and Multiple Templates per Type and Reset on Type Change if you also need to vary the template by a custom field value.

​
Verification

You should now see:
  • The checklist on the consuming work item or document populated with items from the cross-project template’s source work item or document.
  • Changes made later to the source template (in the other project) reflected the next time the checklist template is (re)applied.
If the checklist stays empty after configuring a cross-project documentTemplateId, treat it as the known limitation above rather than a misconfiguration — double-check the work item case works with the same project pair before spending time debugging the document case.

​
See also