Content
View differences
Updated by Wieland Lindenthal 21 days ago
* 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 everwhere 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)
* There is a new field active per default in any work package wp type called "Labels"
* A user should also be able also to add entirely fully new labels. While adding an entirely a fully new label we should visually indicate that this is a new label which will be added to the project.
* While typing in, a user gets a list of label suggestions based on the labels available, and a create option:
* **Matching results:**
* Order by relevance; most relevant on top
* Highlight the bit of the result that matches the input (see mockup)
* Limit to 5 so that the new action isn't too far down the list
* _\[open\] Unless we have a way to identify results by match quality, where we allow going over the limit for exact prefixes. Let's talk about this._
* **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.
* Users can filter for labels within backlog and sprints view.
* Global admin can view and manage in the global admin settings labels available in the instance
* for each label there is a link to the wp table showing all wp associated with this label
* project admins can decide to delete a certain label. When deleted by an admin the label will be removed from all wp.
* global admins can edit a label (e.g. when a typo was done)
* in case the correctly written labels already exists, we should merge the corrected and the originally correct one into one label (a warning / explanation should be shown to the user). The typo use case is a very common one.
* global admins can archive a label: a label will not be shown in autocomplete anymore. Will be still however visible within the wp already associated with this label.
<br>
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
* Users can add multiple labels to each work package
* Each label is automatically usable globally and will be shown in the autocomplete everywhere
* 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)
* There is a new field active per default in any work package
* A user should also be able
* While typing in, a user gets a list of label suggestions based on the labels available, and a create option:
* **Matching results:**
* Order by relevance; most relevant on top
* Highlight the bit of the result that matches the input (see mockup)
* Limit to 5 so that the new action isn't too far down the list
* _\[open\] Unless we have a way to identify results by match quality, where we allow going over the limit for exact prefixes. Let's talk about this._
* **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.
* Users can filter for labels within backlog and sprints view.
* Global admin can view and manage in the global admin settings labels available in the instance
* for each label there is a link to the wp table showing all wp associated with this label
* project admins can decide to delete a certain label. When deleted by an admin the label will be removed from all wp.
* global admins can edit a label (e.g. when a typo was done)
* in case the correctly written labels already exists, we should merge the corrected and the originally correct one into one label (a warning / explanation should be shown to the user). The typo use case is a very common one.
* global admins can archive a label: a label will not be shown in autocomplete anymore. Will be still however visible within the wp already associated with this label.
<br>
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