Content
View differences
Updated by Kabiru Mwenja about 1 month ago
**As** a user of an OpenProject instance configured to use project-based work package identifiers
**I want to** use URLs containing those identifiers
**so that** I can share them with teammates or paste them into other tools, and anyone seeing the URL can tell which project the work package belongs to.
## Acceptance criteria
* URLs like `/work_packages/PROJ-42` open the correct work package in:
* Full view
* Split view
* BIM views
* The same work package can be opened by its numeric ID (e.g. `/work_packages/12345`) — nothing breaks for instances that don't use semantic identifiers
* If a project is renamed, older identifiers (e.g. `OLDNAME-42`) still resolve to the same work package
* Opening a URL with an identifier that doesn't exist shows a standard "work package not found" page (not a generic 404)
* Users only see work packages they have permission to view — typing a guessed identifier into the URL does not bypass permissions
* Links generated inside the product use the semantic identifier when the feature is enabled. Places to verify:
* Work package breadcrumb — clicking any parent/ancestor link (#74200)
* Context menus — all entries, both on the list (triggered via right-click) and on the full view (#74308)
* Opening a work package in split view via the info icon button in the list toolbar (#74309)
* Clicking another row while a split view is already open on the list (#74310)
* The "full screen" link on primerized split-screen pages — e.g. Boards, Notifications (#74311)
* The ID link shown on each work package card — e.g. on Boards (#74312)
* Clicking a notification in the notification center to open the referenced work package (#74313)
* Clicking a work package in the Backlogs view (#74314)
* ~~Text Text macro references (~~`~~#123~~` ~~in (`#123` in descriptions, comments, wiki content) — both the visible label and the target URL render with the semantic identifier (#74315)~~ (#74315)
* Copy-to-clipboard and "share" actions on the work package
* The public API accepts semantic identifiers wherever it accepts numeric work package IDs, including when referencing a parent work package
## Permissions and visibility
* **Who sees this:** all users with permission to view work packages. Using a semantic identifier in a URL does not change who can access what.
* **When it applies:** only on instances where the semantic work package identifiers feature is enabled. On other instances, URLs continue to use numeric IDs as before.
## Translations
* No new user-facing strings. Existing "work package not found" messages are reused.
## Out of scope
* Displaying semantic identifiers in the UI (covered by #73716 and #73717)
* Assigning semantic identifiers to work packages (covered by the sequence allocation feature)
* Admin settings for enabling or configuring the identifier format
* Redirecting numeric URLs to semantic URLs — both forms remain valid
**I want to** use URLs containing those identifiers
**so that** I can share them with teammates or paste them into other tools, and anyone seeing the URL can tell which project the work package belongs to.
## Acceptance criteria
* URLs like `/work_packages/PROJ-42` open the correct work package in:
* Full view
* Split view
* BIM views
* The same work package can be opened by its numeric ID (e.g. `/work_packages/12345`) — nothing breaks for instances that don't use semantic identifiers
* If a project is renamed, older identifiers (e.g. `OLDNAME-42`) still resolve to the same work package
* Opening a URL with an identifier that doesn't exist shows a standard "work package not found" page (not a generic 404)
* Users only see work packages they have permission to view — typing a guessed identifier into the URL does not bypass permissions
* Links generated inside the product use the semantic identifier when the feature is enabled. Places to verify:
* Work package breadcrumb — clicking any parent/ancestor link (#74200)
* Context menus — all entries, both on the list (triggered via right-click) and on the full view (#74308)
* Opening a work package in split view via the info icon button in the list toolbar (#74309)
* Clicking another row while a split view is already open on the list (#74310)
* The "full screen" link on primerized split-screen pages — e.g. Boards, Notifications (#74311)
* The ID link shown on each work package card — e.g. on Boards (#74312)
* Clicking a notification in the notification center to open the referenced work package (#74313)
* Clicking a work package in the Backlogs view (#74314)
* ~~Text
* Copy-to-clipboard and "share" actions on the work package
* The public API accepts semantic identifiers wherever it accepts numeric work package IDs, including when referencing a parent work package
## Permissions and visibility
* **Who sees this:** all users with permission to view work packages. Using a semantic identifier in a URL does not change who can access what.
* **When it applies:** only on instances where the semantic work package identifiers feature is enabled. On other instances, URLs continue to use numeric IDs as before.
## Translations
* No new user-facing strings. Existing "work package not found" messages are reused.
## Out of scope
* Displaying semantic identifiers in the UI (covered by #73716 and #73717)
* Assigning semantic identifiers to work packages (covered by the sequence allocation feature)
* Admin settings for enabling or configuring the identifier format
* Redirecting numeric URLs to semantic URLs — both forms remain valid