Content
View differences
Updated by Judith Roth 5 days ago
**As** a user of OpenProject who is accustomed to the [work package attributes in CKEditor](https://qa.openproject-edge.com/wp/JTP-18)
**I want to** be able to create something similar in documents / BlockNote
**Acceptance criteria**
* There is a new slash command "work package attribute"
* When invoked, the user sees a dialog with the following fields:
* Typeahead-search for the work package
* search by id, identifier or subject (like in the "link work package" dialog)
* reuse existing search result dropdowns
* A select for the available values
* attributes and custom fields of the work package
* this depends on the selected work package and needs to change if the work package changes
* Checkboxes for 1. value 2. label (could also be a select with the 3 options if that would be more user-friendly)
* at least one must be selected, but also both can be selected at once.
* Value is preselected.
* After selecting everything in the dialog and confirming, a new custom inline element block is inserted in the document
* It shows, according to the selection, either a label, a value or "label: value"
* It has a context menu for changing what it shows (label/value/label+value) - tdb: Should it also be able to change the attribute from a context menu?
**Technical notes**
* Like always, we first build a simple variant and then improve it (improvement steps: Show user avatar, render status with dot, render priority with dot, render type with big letters and color)
* We already have styles for status and type, they should be reused
* You can see examples for work package attributes / expansions in CKEditor [here](https://qa.openproject-edge.com/wp/JTP-18)
* We also need a "relative" addressing variant, where we do not save the work package id, but get it from a context (so this is usable in templates). Compare with `workPackageValue:priority` (renders as workPackageValue:priority ) - this will be a separate implementation step (and we still need to discuss how to achieve this) (e.g. additional checkbox or value in the search results dropdown that is only available in certain cases) dropdown)
**Permissions and visibility considerations**
* _To whom is this feature visible?_
* _When is it not visible?_
**Translation considerations**
* _Key terms and phrases in the key languages_
**Out of scope**
* <br>
_Set the_ **To be informed/consulted teams** _field to include all teams necessary to be informed of the changes._
**I want to** be able to create something similar in documents / BlockNote
**Acceptance criteria**
* There is a new slash command "work package attribute"
* When invoked, the user sees a dialog with the following fields:
* Typeahead-search for the work package
* search by id, identifier or subject (like in the "link work package" dialog)
* reuse existing search result dropdowns
* A select for the available values
* attributes and custom fields of the work package
* this depends on the selected work package and needs to change if the work package changes
* Checkboxes for 1. value 2. label (could also be a select with the 3 options if that would be more user-friendly)
* at least one must be selected, but also both can be selected at once.
* Value is preselected.
* After selecting everything in the dialog and confirming, a new custom inline element
* It shows, according to the selection, either a label, a value or "label: value"
* It has a context menu for changing what it shows (label/value/label+value) - tdb: Should it also be able to change the attribute from a context menu?
**Technical notes**
* Like always, we first build a simple variant and then improve it (improvement steps: Show user avatar, render status with dot, render priority with dot, render type with big letters and color)
* You can see examples for work package attributes / expansions in CKEditor [here](https://qa.openproject-edge.com/wp/JTP-18)
* We also need a "relative" addressing variant, where we do not save the work package id, but get it from a context (so this is usable in templates). Compare with `workPackageValue:priority` (renders as workPackageValue:priority ) - this will be a separate implementation step (and we still need to discuss how to achieve this) (e.g. additional checkbox or value in the search results dropdown that is only available in certain cases)
**Permissions and visibility considerations**
* _To whom is this feature visible?_
* _When is it not visible?_
**Translation considerations**
* _Key terms and phrases in the key languages_
**Out of scope**
* <br>
_Set the_ **To be informed/consulted teams** _field to include all teams necessary to be informed of the changes._