# Feature PIR-1 - Have specific role or permission to access templated project, but membership is not instantiated on copy

Project: Project Inititation Requests
Status: closed
URL: https://community.openproject.org/work_packages/PIR-1

## Planning

| Attribute | Value |
| --- | --- |
| Date |  |
| Priority | High |
| Target versions | 17.0.0 |
| List |  |
| Roadmap |  |
| Relevance |  |

## OPEN POINTS / FEEDBACK

_No work packages_

## Features and Chunks

| ID | Subject | Type | Status | Assignee | Target versions | Spent time |
| --- | --- | --- | --- | --- | --- | --- |
| PIR-97 | Improve display of members in template projects | Feature | new |  | Wish List |  |

## Bugs and other work packages

| ID | Type | Subject | Status | Assignee | Target versions | Spent time | Module |
| --- | --- | --- | --- | --- | --- | --- | --- |
| PIR-101 | Bug | Template setting is reset after saving | closed |  | 17.0.0 |  | Modules and project features / Project settings |

## Technical Details

| Attribute | Value |
| --- | --- |
| Module | Modules and project features / Project creation, Administration / Roles and permissions / Project roles and permissions |
| Feature Flag |  |
| Requires doc change | No |
| Enterprise plan |  |

## Details

| Attribute | Value |
| --- | --- |
| Pull preview |  |
| Mockups |  |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers | Oliver Günther |
| Designer | Marc Alcobé |
| Signed off by |  |
| Interest by |  |

## Estimates and progress

| Attribute | Value |
| --- | --- |
| Work |  |
| Labor costs |  |

## Description

When using the template functionality, users able to copy or instantiate a template need to have the copy projects permission in the template project. As this is a regular membership, it prevails after a copy unless copying *all* members are explicitly unselected during instantation. It would be nice to be able to differentiate access to the template project, vs templated memberships to be copied

### **Acceptance criteria**

  - Project administrators have a way to define roles that are not copied on template instantiation

  - The project settings is expanded with a separate "Template" menu
    
      - When the project is not a template, show a toggle switch
    
      - 
        
        <img class="image_resized op-uc-image op-uc-image_inline" style="width:805px;" src="/api/v3/attachments/917661/content">

  - The switch allows the project to be toggled as a template

  - When the project is a template, show a role selection for ProjectRole
    
      - This selection is multi-select

  - Once saved, these roles will be skipped on copy of this template
    
      - This means, if a user only has these selected roles, they will NOT be copied
    
      - If a user has these roles and another role not selected here, only that other role will remain

<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/917662/content">

<br>

### **Technical notes**

Discussed option to implement this:

##### Option 1: Per-template setting for excluded roles

<br>

  - Add a store\_attribute :settings, :excluded\_role\_ids\_on\_copy, :array to Project (for templates only)

  - During copy in MembersDependentService, check if the source project has this setting and filter accordingly

**Pros:**

  - Most flexible, each template can have its own excluded roles

  - Doesn't require changes and migrations to roles

**Cons:**

  - You need to configure it per template

  - Same role can be copied from one template but not another, which might be confusing

<br>

### Alternatives

> ##### Option 1: Add a template\_role flag to ProjectRole
> 
>   - Add a boolean column (e.g., template\_only) to the roles table
> 
>   - Roles marked as template\_only: true would be excluded during project copying in MembersDependentService
> 
>   - Add validation to prevent assigning template roles to non-template projects
> 
> **Pros:**
> 
>   - A role is easily identifiable as templated, so you could show it in all global and project views
> 
>   - Implementation and contracting should be simple for the Role creation service and the member creation service
> 
> **Cons:**
> 
>   - Needs admins to set this up, less flexibility in each template
> 
>   - I could see this lead to creating duplicate roles (e.g., "Editor" and "Template Editor") with same permissions, that are hard to understand.
> 
> ##### Option 2: Global setting for roles excluded from template copy
> 
>   - Add a global setting like template\_excluded\_role\_ids (array of ints) in Settings::Definition
> 
>   - During copy, filter out roles whose IDs are in this list
> 
> **Pros:**
> 
>   - Easiest to implement, as this is just applied on template copy
> 
>   - Single place to manage this behavior
> 
>   - Works with existing role structure
> 
> **Cons:**
> 
>   - Hard for project admins to find out which roles are affected
> 
>   - Need an admin to change this
>     
>     <br>

> ##### Option 3: Per-template setting for included/excluded members
> 
>   - Select users or groups in the template that you want to include or exclude