# Epic FND-5 - Labels for work packages Project: Stream workspace foundations Status: in development URL: https://community.openproject.org/work_packages/FND-5 ## Detailed specification ### Motivation and background information Custom fields can only be configured globally. By allowing labels to be added by any user with edit rights gives project teams more means of customization. Labels work like tags and can be added by any project user. All labels created by any project user will exist globally and not per project. ### Acceptance criteria * Labels can be added to work packages by any project user with work package edit rights * Users can add multiple labels to each work package * Each label is automatically usable globally and will be shown in the autocomplete everywhere else  * When a user creates a new label, we preserve the case of the original label (eg. "JSON", "OpenProject", "SAFe") * No duplicates are then allowed (eg. "json", "Openproject", "SAFE" aren't allowed) * When adding a label, the autocomplete will suggest the existing label regardless of the case of search input (eg. typing "proj" will return both "OpenProject" and "New projects", typing and entering "openproject" will select the existing "OpenProject" label) * \[open\] There is a new field active per default in any work package type called "Labels" * What about existing installations? * A user should also be able to add entirely new labels. While adding an entirely new label we should visually indicate that this is a new label which will be added to the project. * \[open\] The user is able to: * **add** a label (and if it doesn't exist, **create** it) * **remove** a label * they can never directly **delete** a label * however, removing the last place a label is used effectively deletes it too (i.e, it gets removed for the list of labels in the admin settings page) * While typing in, a user gets a list of label suggestions based on the labels available, and a create option: * Use the existing dropdown component that we use for the Assignee field. * **Matching results:** * Order by relevance: * Most used labels in the project * Load 10 initially (max 5 will be visible pre-scroll) * Sort by frequency: most used to less used * Highlight the bit of the result that matches the input (see mockup) * **Create action:** * "{search input} (new label)" * Permissions * View labels: view work packages * Add/remove labels (within the work package): Edit work packages * Delete labels (from the instance): global admin * Work packages can be filtered, sorted and grouped by labels. * Labels are shown in the work package list. * Global admins can view and manage labels in _Administration → Labels_ * The list of labels is displayed in BorderBoxTable with two columns: * "Label" (name) * "Used in" * The labels are displayed in alphabetical order. * There is pagination if necessary. * The used in column shows the number of work packages tagged with that label. It is a link. * The link opens in a new browser tab with a work package table view pre-filtered with that label * Each label has a more menu with these options: * Rename (displays a modal with an input field to rename the label) * Delete (removes the label from the list) * Show a Confirmation Danger Dialog that includes the count of work packages that will be affected. * Title: "Delete this label?" * Text: "This will remove the label from {n} work packages that currently use it. Are you sure you want to delete it?" * Confirmation: "I understand that this action is not reversible." * Actions: * "Delete" (danger) * "Cancel" (secondary) * Admin users can also create new labels by clicking on the "+ Label" primary button in the subheader. * An admin-created label has the particularity that, unlike user-created ones, it is visible on the list even if no work packages currently use it. (Else it would disappear on creation). * The "Used in" column will show a hyphen ("-") instead of "{n} work packages" if it not currently used anywhere. * _Note: This implies that user-created labels and admin-created ones behave slightly differently, at least in how they're deleted; it's important to store information about who created the label._ * \[if possible\] When a new label is created, jump to the page containing that label. * Journaling at a work package level: * When a label is added or removed, it is journaled. This is also visible in the activity tab. * Added: "**Label {label name}** added by {author}" * Removed: "**Label {label name}** removed by {author}" * When a label that is currently in use is deleted by an admin * Singular: **"Label removed**: 'Frontend' was deleted" * Plural: **"Label removed**: 'Frontend', 'Backend', 'Middleware' were deleted" * This should be attributed to the admin user who made the change. * Do not show the 'Labels changed' journal entry. **Technical considerations** * Whitespace normalisation: * Strip any spaces at the start or the end * Reduce double spaces in between words to 1 space. **Further iterations; not necessary for v1** * \[open\] **Archiving:** Global admins can archive a label: * a label will not be shown in autocomplete anymore. * The more menu of a label has the option "Archive". * This marks that label as archived in the list. * Work packages that had the label will continue showing the label. * The label will not become read-only; i.e, if the work package is not locked, the user will still be able to remove it from the work package. * Journaling: * Add event for archiving: "**Label {label name}** archived by {author}"\] * Merged: "**Label {label name}** replaced with **Label {label name}** by {author}" * **Merging**: Global admins can choose to merge two labels. * Theris a "Merge with" action in the more menu of a label: this displays a modal that lets you pick which label to merge with and which of the two labels to keep * The merged label replaces both labels in work packages using either. **Migration consideration:** * in case the customer uses a label in different forms (e.g. upper case, lower case) this should be resolved during the migration ### Out of scope - Private labels: labels that users can create for themselves only visible to themselves - There is a new custom field type "labels" - Project-specific labels - changes in the backlog and board cards \#\#AGILE-414 - Users can filter for labels within backlog and sprints view. | Attribute | Value | | --- | --- | | Mockups | https://www.figma.com/design/zWgvvoc93Ee3NGzZNXth0x/Labels---Tagging?node-id=200-6170 | ## Planning | Attribute | Value | | --- | --- | | Roadmap | 2026 Q4 | | Date | | | Votes | 10 | | List | RM Jira exit, RM Jira admin | | Target versions | 18.0.0 | | Sprint | | | Backlog bucket | | | Relevance | Very Important — Required Immediately After Go-Live | ## Subitems | ID | Type | Subject | Status | Assignee | Target versions | Project | Priority | Spent time | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | COMMS-1000 | Feature | Labels API | merged | | 18.0.0 | Stream Communicator | Medium | | | COMMS-1004 | Feature | Labels for work package show page | tested | | 18.0.0 | Stream Communicator | Medium | | | COMMS-1014 | Feature | Labels for work package table + exports + Gantt charts | tested | | 18.0.0 | Stream Communicator | Medium | | | COMMS-1021 | Feature | Support labels in work package operations (copy + move + bulk edit) | tested | | 18.0.0 | Stream Communicator | Medium | | | COMMS-1022 | Feature | Support labels in journal-based operations (activity + baseline) | tested | | 18.0.0 | Stream Communicator | Medium | | | COMMS-1023 | Feature | Suport labels in auto-generated subjects | tested | | 18.0.0 | Stream Communicator | Medium | | | COMMS-1024 | Feature | Labels administration | tested | | 18.0.0 | Stream Communicator | Medium | | | COMMS-1029 | Feature | Labels for MCP server | merged | | 18.0.0 | Stream Communicator | Medium | | | COMMS-1030 | Feature | Enable Labels in production | in development | Kabiru Mwenja | 18.0.0 | Stream Communicator | Medium | | | AGILE-429 | Feature | Labels for Backlogs and Sprints | in specification | Attila Dombi | | Stream agile | Medium | | ## Bugs and other work packages | ID | Type | Subject | Status | Assignee | Target versions | Module | | --- | --- | --- | --- | --- | --- | --- | | FND-248 | Design Task | Move configuration into project settings and simplify the overview | closed | Parimal Satyal | | | ## Details | Attribute | Value | | --- | --- | | Module | | | Enterprise plan | Community (COM) | | Labels | | ## People | Attribute | Value | | --- | --- | | Assignee | OP Dev Comms Team | | Accountable | Rosanna Sibora | | Product manager | Sonita Soth | | Designer | Parimal Satyal | | Developers | OP Dev Comms Team | | Requested by | | | Interest by | Home (224196000003952096) | ## Estimates and progress | Attribute | Value | | --- | --- | | Work | 50d 0h · Σ 50d 0h | ## Description **As a** project member **I want to** quickly add labels to my work packages (without the need of getting in touch with the global admin) **So that I** can better structure my projects.