Content
View differences
Updated by Wieland Lindenthal 5 days ago
**Jira-like We want to provide work package identifiers in the schema `<project identifier>-<sequence number>`. As a work package identifier contains the project identifiers** identifier — which provides some additional context — we call it a **semantic identifier**.
An admin will be able to choose if regular numeric identifiers will be used for all work packages or semantic identifiers.
The auto-incrementing sequence number which is part of every work package identifier is dependent on the project. For every project and type combination it starts with 1.
* Projects have a short name, e.g. `oD` for openDesk (1 to 10\* chars).
* Types have a short name, e.g. `CR` for Change Request (1 to 8 chars).
**Implementation steps**
1. Step 1: {projectkey}-{sequence} (Jira case)
1. `oD-2212`
2. `HR-123`
2. Step 2: custom pattern
1. `oD_CR-1`
2. `oD_D-4`
3. `oD_EPIC-35`
4. `oD_BUG-223`
**More requirements:**
* When creating a new project, I can specify a custom project key (e.g., "MKTG" for Marketing, "DEVOPS" for DevOps).
* Allow handling of The system validates that the project key size of \*2-255 characters. is unique across all projects.
* Our algorithm should calculate acronyms of maximal 10 by default. That If no custom key is also provided, the default in Jira.
system auto-generates one from the project name, based on the rules below.
* Allow usage of any 3 first characters from A to Z, digits from 0 to 9 and the underscore character. (Jira requirement)
project name (e.g., &quot;Marketing Team&quot; → &quot;MAR&quot;).
* Must start with a letter (Jira requirement)
In case this key is already taken, use 4 or more characters.
* Must be in uppercase.
* The system validates that Changing type or moving the work package to another project identifier is unique across all projects.
updates the key.
* Historical references and links remain functional after key changes.
* Administrators can edit an existing project's key through project settings.
* When changing a project key, the system displays a warning about the impact on existing work packages.
* All existing work package identifiers automatically update to use the new key (e.g., OLD-123 becomes NEW-123).
* The system performs a background re-index after key changes.
* Historical references and links remain functional after key changes.
* The numeric sequence continues incrementally regardless of key changes.
* A project identifier key can not be used twice. It is blocked also after deleting the work package, moving project or renaming the project identifier. changing type.
**Jira-like project-based work package identifiers**
* We want **Requirements to provide work package identifiers in the schema `<project identifier>-<sequence number>`. As a work package identifier contains the project identifier — which provides some additional context — we also call it a **semantic identifier**.
* An admin can choose the whole OpenProject instance to use for work packages
* regular numeric identifiers (the old way)
* project-based alphanumeric semantic identifiers. (the allow Jira way)
migrations (Step 1):**
* When project-based alphanumeric semantic work package identifiers are used, all important views, but also imports and exports, API routes, resource routes, searches, filters and other features support them.
* Moving the work package to another Allow handling of project updates the key.
* Historical references and links remain functional after key changes.
* The old numeric identifiers will remain usable at all times, e.g. in work package searches and API requests.
* The auto-incrementing sequence number which is part size of every work package identifier is dependent on the project.
* `<project identifier>-<sequence number>`, e.g.
* `OD-2212`
* `HR-123`
* For every project the sequence starts with 1. \*2-255 characters.
* Allow usage of any characters from A work package identifier can not be used twice. It is blocked also after deleting to Z, digits from 0 to 9 and the work package, renaming the project identifier or moving the work package to another project. underscore character.
The auto-incrementing sequence number which is part of every work package identifier is dependent on the project. For every project and type combination it starts with 1.
* Types have a short name, e.g. `CR` for Change Request (1 to 8 chars).
**Implementation steps**
1. Step 1: {projectkey}-{sequence} (Jira case)
1. `oD-2212`
2. `HR-123`
2. Step 2: custom pattern
1. `oD_CR-1`
2. `oD_D-4`
3. `oD_EPIC-35`
4. `oD_BUG-223`
**More requirements:**
*
* Allow handling of
* Our algorithm should calculate acronyms of maximal 10 by default. That
* The system validates that
*
* When changing a project key, the system displays a warning about the impact on existing work packages.
* All existing work package identifiers automatically update to use the new key (e.g., OLD-123 becomes NEW-123).
*
*
* The numeric sequence continues incrementally regardless of key changes.
* A project identifier
**Jira-like project-based work package identifiers**
* We want
* An admin can choose the whole OpenProject instance to use for work packages
* regular numeric identifiers (the old way)
* project-based alphanumeric semantic identifiers. (the
* Moving the work package to another
* Historical references and links remain functional after key changes.
* The old numeric identifiers will remain usable at all times, e.g. in work package searches and API requests.
* The auto-incrementing sequence number which is part
* `<project identifier>-<sequence number>`, e.g.
* `OD-2212`
* `HR-123`
* For every project the sequence starts with 1.
*