Implementation/COMMS-1048: Labels field on the work package view with inline creation by akabiru · Pull Request #25554 · opf/openproject

akabiru · 2026-09-23T20:57:15Z

https://community.openproject.org/wp/COMMS-1048

Work packages show their labels on the full and split view, and users with edit_work_packages edit them in a multi-select that searches labels on the server and saves with the field's own save/cancel controls. A pinned option at the bottom of the dropdown creates a label from the typed name and adds it to the selection. The fetching lives in a dedicated op-labels-autocompleter so other surfaces can reuse it.

Screenshots

Full view, Details group

Initial dropdown order: used in this workspace, then most used, then name

Create option pinned below the results

Split view

AI involvement

Directed – I specified the requirements and AI implemented most of it; I validated via testing rather than a full line-by-line review.

github-actions · 2026-09-23T21:02:48Z

Deploying openproject with ⚡ PullPreview

Field	Value
Latest commit	`63b316e`
Job	`deploy`
Status	✅ Deploy successful
Preview URL	https://pr-25554-comms-1048-labe-ip-167-233-236-111.my.opf.run:443

View logs

github-actions · 2026-09-24T14:04:26Z

Warning

Flaky specs

rspec ./spec/features/roles/report_spec.rb[1:2]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25554, linked for reference only):

- `rspec ./spec/features/roles/report_spec.rb[1:2]`

Treat this as a standalone task, unrelated to PR #25554. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25554 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @akabiru to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @akabiru, and request a review from @akabiru.
On every commit, set @akabiru as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

github-actions · 2026-09-28T08:13:25Z

Warning

Flaky specs

rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25554, linked for reference only):

- `rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]`

Treat this as a standalone task, unrelated to PR #25554. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25554 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @akabiru to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @akabiru, and request a review from @akabiru.
On every commit, set @akabiru as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

Labels render like the other multi-value attributes and are edited in a multi-select that searches on the server so the workspace-relevance ordering is kept. A dedicated labels autocompleter holds the fetching so other surfaces can reuse it.

The create option is pinned below the options and only offered while the typed name matches no loaded label. The created label joins the open selection and is saved with the field.

The accessible name of the field stringified the HAL resources; it now joins the names like the title does. The create-label option also stays hidden while results are still loading.

The create action is an addTag option, so arrow keys and Enter reach it. A 403 on create shows a specific message instead of the raw error.

Save/Cancel render only alongside the input, and the combobox is announced by the field name.

The API authorizes label creation, so the client no longer special-cases 403 responses.

New labels read "<name> (New label)", matches highlight in blue, and the list closes on pick so it can open either way without covering Save/Cancel.

The create option stays fixed while the list scrolls and remains a keyboard-reachable option.

The shared schema no longer treats add_work_packages as enough to edit labels, so add-only users see the field read-only.

Add-only users pick existing labels; creating new ones on the fly needs edit_work_packages in the project.

Name the permission each schema case covers and check the case-insensitive duplicate on its own.

The joined name backs the title and aria-label of every multi-value resource field, not only labels.

github-actions · 2026-10-19T13:27:42Z

Warning

Flaky specs

rspec ./spec/features/components/lookbook_accessibility_spec.rb[1:14:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25554, linked for reference only):

- `rspec ./spec/features/components/lookbook_accessibility_spec.rb[1:14:1]`

Treat this as a standalone task, unrelated to PR #25554. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25554 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @akabiru to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @akabiru, and request a review from @akabiru.
On every commit, set @akabiru as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

The option now uses ng-select's default tag template with a leading "Create label" prefix, matching the share dialog's invite option. The pinned row, its grey marked background and the keyboard scroll nudge are gone; the option is a plain last row in the list. Also refreshes the copyright headers of the labels autocompleter files to the current wording so eslint accepts them.

github-actions · 2026-10-20T05:46:38Z

Warning

Flaky specs

rspec ./spec/features/work_packages/table/queries/id_filter_spec.rb[1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25554, linked for reference only):

- `rspec ./spec/features/work_packages/table/queries/id_filter_spec.rb[1:1]`

Treat this as a standalone task, unrelated to PR #25554. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25554 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @akabiru to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @akabiru, and request a review from @akabiru.
On every commit, set @akabiru as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

HDinger

LGTM 👍 Thanks for addressing that 🙇

akabiru · 2026-10-20T16:25:37Z

One other thing I found: When a label is very long, it pushes the rest out of the field. In the example below, I have two labels selected, but I only see one:

This is probably an exisiting problem which also affects other fields, so I am fine with keeping that out of scope for this PR.

→ https://community.openproject.org/wp/FND-259

akabiru added this pull request to stack #25555 September 23, 2026 20:57

akabiru changed the title ~~implementation/comms 1048 labels field on work package view~~ Implementation/COMMS-1048: Labels field on the work package view with inline creation Sep 23, 2026

akabiru self-assigned this Sep 23, 2026

akabiru mentioned this pull request Sep 23, 2026

Feature/COMMS-1004: Labels for work package show page #25551

Closed

akabiru added the ai: Collaborative 💻 AI generated a substantial part of the code; A human reviewed and understands every line. label Sep 23, 2026

akabiru added this to the 18.0.x milestone Sep 23, 2026

github-actions Bot removed the ai: Collaborative 💻 AI generated a substantial part of the code; A human reviewed and understands every line. label Sep 23, 2026

akabiru added the pullpreview label Sep 23, 2026

akabiru added ai: Collaborative 💻 AI generated a substantial part of the code; A human reviewed and understands every line. and removed pullpreview labels Sep 23, 2026

akabiru force-pushed the implementation/comms-1048-labels-field-on-work-package-view branch from b47e919 to a6d038f Compare September 24, 2026 06:13

github-actions Bot removed the ai: Collaborative 💻 AI generated a substantial part of the code; A human reviewed and understands every line. label Sep 24, 2026

akabiru force-pushed the implementation/comms-1048-labels-field-on-work-package-view branch 2 times, most recently from 483d2b9 to 04b74a4 Compare September 24, 2026 13:39

akabiru force-pushed the implementation/comms-1048-labels-field-on-work-package-view branch from 04b74a4 to 60c6bcd Compare September 24, 2026 14:28

akabiru added ai: Directed 🪄 A human specified the requirements and AI implemented most of it; They validated via testing. pullpreview labels Sep 28, 2026

akabiru marked this pull request as ready for review September 28, 2026 08:11

github-actions Bot removed the ai: Directed 🪄 A human specified the requirements and AI implemented most of it; They validated via testing. label Sep 28, 2026

akabiru requested review from a team and HDinger September 28, 2026 08:11

akabiru added the ai: Directed 🪄 A human specified the requirements and AI implemented most of it; They validated via testing. label Sep 28, 2026

akabiru marked this pull request as draft September 28, 2026 08:49

github-actions Bot removed the pullpreview label Oct 11, 2026

akabiru force-pushed the implementation/comms-1048-labels-field-on-work-package-view branch 2 times, most recently from 3e3dc1f to bf75968 Compare October 19, 2026 12:48

Base automatically changed from implementation/comms-1047-label-creation-api to dev October 19, 2026 13:14

akabiru added 12 commits October 19, 2026 16:14

Create labels from the work package labels dropdown

d8a59b3

The create option is pinned below the options and only offered while the typed name matches no loaded label. The created label joins the open selection and is saved with the field.

Announce multi-value display fields by name

fd17056

The accessible name of the field stringified the HAL resources; it now joins the names like the title does. The create-label option also stays hidden while results are still loading.

Create labels from a keyboard-reachable dropdown option

18b9a2c

The create action is an addTag option, so arrow keys and Enter reach it. A 403 on create shows a specific message instead of the raw error.

Hide label edit controls without an autocompleter URL

fd81337

Save/Cancel render only alongside the input, and the combobox is announced by the field name.

Leave label create errors to the generic handler

05f9ee4

The API authorizes label creation, so the client no longer special-cases 403 responses.

Match the labels dropdown to the assignee autocompleter

985675b

New labels read "<name> (New label)", matches highlight in blue, and the list closes on pick so it can open either way without covering Save/Cancel.

Pin the create label option to the bottom of the dropdown

a0add9b

The create option stays fixed while the list scrolls and remains a keyboard-reachable option.

Require edit rights for labels on existing work packages

e410060

The shared schema no longer treats add_work_packages as enough to edit labels, so add-only users see the field read-only.

Offer label creation only to users who can edit work packages

02ef170

Add-only users pick existing labels; creating new ones on the fly needs edit_work_packages in the project.

Tidy the labels specs

5a54f77

Name the permission each schema case covers and check the case-insensitive duplicate on its own.

Cover version fields in the multi-value display name

229e943

The joined name backs the title and aria-label of every multi-value resource field, not only labels.

akabiru force-pushed the implementation/comms-1048-labels-field-on-work-package-view branch from bf75968 to 229e943 Compare October 19, 2026 13:14

Refresh copyright headers in the labels field files

63b316e

akabiru requested a review from HDinger October 20, 2026 07:53

akabiru added the pullpreview label Oct 20, 2026

HDinger approved these changes Oct 20, 2026

View reviewed changes

akabiru merged commit 09d9608 into dev Oct 20, 2026
24 checks passed

akabiru deleted the implementation/comms-1048-labels-field-on-work-package-view branch October 20, 2026 16:26

github-actions Bot locked and limited conversation to collaborators Oct 20, 2026

github-actions Bot removed the pullpreview label Oct 20, 2026

Navigation Menu

Repository navigation

Implementation/COMMS-1048: Labels field on the work package view with inline creation - #25554

Implementation/COMMS-1048: Labels field on the work package view with inline creation#25554
akabiru merged 14 commits into
devfrom
implementation/comms-1048-labels-field-on-work-package-view

akabiru commented Sep 23, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 23, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 24, 2026

Uh oh!

github-actions Bot commented Sep 28, 2026

Uh oh!

github-actions Bot commented Oct 19, 2026

Uh oh!

github-actions Bot commented Oct 20, 2026

Uh oh!

HDinger left a comment

Uh oh!

akabiru commented Oct 20, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Conversation

akabiru commented Sep 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Screenshots

AI involvement

Uh oh!

github-actions Bot commented Sep 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying openproject with ⚡ PullPreview

Uh oh!

github-actions Bot commented Sep 24, 2026

Uh oh!

github-actions Bot commented Sep 28, 2026

Uh oh!

github-actions Bot commented Oct 19, 2026

Uh oh!

github-actions Bot commented Oct 20, 2026

Uh oh!

HDinger left a comment

Choose a reason for hiding this comment

Uh oh!

akabiru commented Oct 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

akabiru commented Sep 23, 2026 •

edited

Loading

github-actions Bot commented Sep 23, 2026 •

edited

Loading

akabiru commented Oct 20, 2026 •

edited

Loading