---
tags: Product
---
# Templates
The ability to create new content on Alkemio, based on a set of existing definitions, is referred to as **Templates**. Some examples of where Templates are applicable in Alkemio include:
* Aspect Types
* Canvases
* Challenge Lifecycles

The way it works is that within a given scope, typically a Challenge Hub, there are a set of Templates availalbe. Then when a user wants to create a new instance of a particular entity, they close the Template and use it as a **template** for a new entity. In the example of a Canvas Template, there is already a Canvas created that has a particular layout and is designated as a Canvas Template and the user creates a new Canvas based on that Canvas. The original Canvas Template is not mofified, and the User can then work further on the new Canvas.

Templates provide the following key benefits:
* Allowing each Hub to customize the environment
* Enabling the sharing of best practices in a systematic way.

This latter point is critical: demonstrating the vision of giving access to content to accelerate working effectively on Challenges.

## Scope
The initial scope for Template support covers:
* Aspect Templates
* Canvas Templates

Other templates types, such as Challenge Lifecycles, Community setups, Classification Tagsets etc should all be able to build upon this initial work.

Out of scope:
* managing versions of templates + the associated history

## Current Situation
The current support for Templates on Alkemio suffers from a number of issues:
* No systematic support for Platform Templates
* Templates are defined / managed in differing ways:
* A CanvasTemplate is a flag on a Canvas entity (data)
* Actor groups are defined in global UX config (config)
* The logic around what Templates are available in a given scope differs
* Canvas Templates are an aggregation of Hub, Challenge and Ops (depending on level). No support for global templates.

## Platform Templates
The platform itself should make available a set of Templates for each Template type. These are in essence global Templates that can then be made available within Challenge Hubs.

The Hub admin then chooses what Templates are available within the particular Hub.

## Design
As Templates are a core mechanism for the platform, the Templates themselves should be part of the domain model. Each Hub as such should be aware of the set of Templates that are available within the scope of that Hub. This has to be data driven.

Note:
* Each Template will be different, and as it is a core part of the domain will need its own type
* But the set of meta-data that we want to have for each Template is something that we can re-use.
* **Version**: an identifier
* **Created by**: the user that created and made available the Template


The management of Platform Templates is not part of the domain model, and could be done as a separate service. Ideally the Platform Templates should be data driven, but as this will be behind a particular facade the domain logic does not need to be aware of how the Platform templates are managed.

Note above is a logical data model, so what is shown on the api. How it is stored in the physical data model is separate.

Key choices:
* Copy on instantiation: when a Template is added to a Hub etc then it is copied (there is no reference maintained)

## Phasing
The following phases are envisaged:
* Separation of concerns: creation of an explicity service for managing Platform templates
* As part of this there needs to be a way of loading in default platform templates
* Data driven platform templates
* With an admin API to allow the adding / updating of platform templates, including thumbnail images etc

## Updates

### Server
The following functional updates are needed on the Server:
* Entity Definitions
* Add in entities in ORM for the following types:
* Templates
* AspectTemplate
* CanvasTemplate
* TemplateInfo
* Add in graphql api types for the above
* API
* Templates Management: Add mutations for adding / removing Aspect Templates on the Templates entity
* Remove the updating of the Hub Template as part of the updateHub mutation, updating related DTOs accordingly
* Business Logic:
* Default set of Templates to add to each new Hub
* Ideally have a generic approach for the management of default templates to be added
* *TBD: how to ensure each Hub always has a set of AspectTemplates?*
* Remove the AspectTemplates from the global UX config?
* Platform Templates
* TBD - how to populate the visual that is used for global templates?
* TBD - copy over values when adding to a Hub?
* Authorization: same set of mutations or different? How to reset the authorization policy on these Templates?
* Service for Platform Templates
* TBD - Should this be a separate service so it can be later isolated / managed?
* Trade off is being able to re-use the domain model in this first run through or not

### Client
The following functional updates are needed on the Client:
* Front end
* Update to only use the AspectTemplates for each Hub (no global UX config usage)
* Update to pick up the Canvas Templates from the Hub only (no custom ones per Challenge etc)
* Admin
* Add a Templates tab to Hub to allow the Hub Admin to update the set of Aspect and Canvas templates being used
* TBD: UX design for this?
* Managment of the platform templates?

### Data Migration
The following migration actions are needed:
* Platform Templates
* Definition of the global Templates entity for holding platform level Templates
* TBD - what to put in base definition and what to add via data extensions?
* TBD - for Visuals, how to add those in?
* Canvas Templates
* Remove the isTemplate field on Canvases
* Decision: manually define the set of global Canvas Templates on each environment
* Aspect Templates: to be added on a per Hub basis
* Hub has AspectTemplates: Create AspectTemplates based on the current Hub.templates string field to each Hub
* Hub does not have AspectTemplates: Create AspectTemplates equivalent to current global UX config templates