[COMMS-1071] Find or create labels when the work package is saved by akabiru · Pull Request #26270 · opf/openproject

akabiru · 2026-10-23T11:29:27Z

Ticket

https://community.openproject.org/wp/81938

Alternative to [COMMS-1050] Remove unused inline-created labels #26187

What are you trying to accomplish?

Make labels typed into the form now stay local until the work package is saved. The autocompleter keeps them as pending items, the payload sends each one as a _links.labels entry with a null href and the name as title, and the label is found or created in the same transaction as the work package.

{
  "_links": {
    "labels": [
      { "href": "/api/v3/labels/130" },
      { "href": "/api/v3/labels/131" },
      { "href": "/api/v3/labels/132" },
      { "href": null, "title": "Needs triage" } // new label, created when the work package saves
    ]
  },
  "_meta": { "validateCustomFields": true },
  "lockVersion": 1
}

Screen.Recording.2026-10-27.at.6.31.34.PM.mov

What approach did you choose and why?

Creating labels is service work, so the work package create and update services find or create the named labels as the acting user inside the transaction they already open; a failed save leaves no label behind. Names are created in a stable order so that two saves introducing the same names cannot deadlock on the unique name index, and a label created concurrently under the same name is reused instead of failing the save. The model itself only refuses to save while names are still unresolved, so nothing can drop them silently.

AI involvement

Collaborative - AI generated a substantial part of the code; I reviewed and understand every line.

Merge checklist

Added/updated tests
Added/updated documentation in Lookbook (patterns, previews, etc)
Tested major browsers (Chrome, Firefox, Edge, ...)

Closes #26187

A work package can carry label names next to label ids. The names are resolved or created inside the save transaction, so an abandoned form leaves no label behind and the contract rejects names the user may not create before anything is written.

A `_links.labels` entry with a null href and a title is a label to create on save; the form endpoints echo it back without persisting.

The autocompleter keeps a new label as a local pending item and the work package payload sends it as a titled link without href.

The form echo and the contract looked a label up per name; both now match all names at once with the case folding done in Postgres.

github-actions · 2026-10-23T11:49:55Z

Deploying openproject with ⚡ PullPreview

Field	Value
Latest commit	`d8bd61e`
Job	`deploy`
Status	✅ Deploy successful
Preview URL	https://pr-26270-comms-1071-creat-ip-188-34-156-127.my.opf.run:443

View logs

github-actions · 2026-10-23T11:57:14Z

Warning

Flaky specs

rspec ./spec/features/work_packages/cancel_editing_spec.rb[1:5]

🤖 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 #26270, linked for reference only):

- `rspec ./spec/features/work_packages/cancel_editing_spec.rb[1:5]`

Treat this as a standalone task, unrelated to PR #26270. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #26270 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 create service ignored the result of its unvalidated save, so an aborted label creation needed a raise to avoid a silent success and ended in a 500. Honouring the save result turns it into the same 422 the update path gives.

Names that already exist are filtered in one query, so uniqueness and the permission lookup no longer run once per pending name on every form refresh.

A pending label and a persisted label with the same name are the same label, since the backend identifies labels by their lower-cased name.

Without a labels link on the reference the base changeset writes raw resources into the payload and the pending titles were lost.

…rk-package-save

Running the model's own validation keeps the contract in step with Label; the cap bounds how many labels one save can create.

Every item carries a name, so the href fallback could never run.

POST /api/v3/labels is hidden behind the flag, so saving a work package must not create labels or change labelings either.

Creating another aggregate's records as the acting user is service work; the model only refuses to save while names are unresolved. Names are created in a stable order so concurrent saves cannot deadlock.

API clients need the permission, length and per-request limits to handle the 422 responses.

A shared work package grants edit rights without the project-wide right to create labels, so updates and their form must reject new names.

Copying only the error symbols dropped the length limit, so rendering a too-long label name raised instead of answering with a 422.

FindOrCreateLabels says that typed names become existing or new labels; pending and resolve left the reader guessing.

Labels are now created when the work package saves, so a bad name must come back as a field error in split view, the table and the create form.

No permission is called create labels; the check is edit rights in any project, the same as POST /api/v3/labels.

Pending said nothing about what the names are for; the checks validate label names and pick out the ones that would create labels.

The label ids and names are what the next save assigns, which pending did not say.

github-actions · 2026-10-27T15:07:05Z

Warning

Flaky specs

rspec ./modules/documents/spec/features/documents/project/show_edit_document_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 #26270, linked for reference only):

- `rspec ./modules/documents/spec/features/documents/project/show_edit_document_spec.rb[1:1]`

Treat this as a standalone task, unrelated to PR #26270. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #26270 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.

Mirrors Attachments::ValidateReplacements so the work package contract does not carry label rules inline.

github-actions · 2026-10-27T16:00:27Z

Warning

Flaky specs

rspec ./modules/documents/spec/features/documents/project/show_edit_document_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 #26270, linked for reference only):

- `rspec ./modules/documents/spec/features/documents/project/show_edit_document_spec.rb[1:1]`

Treat this as a standalone task, unrelated to PR #26270. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #26270 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 are resolved on their own line, like attachments, so the save no longer reads as depending on them; the post-save steps move out to keep the method within the complexity limit.

The after_validate hook is the slot for work that needs a passed contract but no save yet, so persist stays the plain save.

Matches the server, which treats a title-only label link as a new record.

brunopagno

To me this looks pretty good. I think this is the better approach. I really appreciate the effort of making it 🙇

brunopagno · 2026-10-28T08:04:38Z

 module Labelable
  extend ActiveSupport::Concern

+  MAX_LABEL_NAMES_PER_SAVE = 50


This feels like a check we would add after something broke 😅
Maybe it's good that we're preemptive. I don't disagree with validating the amount.

Any special reason for 50?

Arbitrary limit tbh, not sure it's practical to allow 1000 labels? 😄 Happy to drop it though 👍🏾

The UI does not really allow someone to add 1000 labels. But maybe the API would. I guess it's a problem that is a bit too abstract, I would not expect users to "abuse" this system too much. But I could be wrong

In any case, I think it's fine the way it is. My initial gut feeling was to make the limit stricter, not more lenient 😅

50 is fine 👍

akabiru · 2026-10-28T12:00:38Z

Verbal Ok from Henriette on the new pattern, merging 👍🏾

akabiru added 4 commits October 23, 2026 14:26

Accept new label titles in the work package API

2b3fdc2

A `_links.labels` entry with a null href and a title is a label to create on save; the form endpoints echo it back without persisting.

Create labels on work package save instead of while typing

556e163

The autocompleter keeps a new label as a local pending item and the work package payload sends it as a titled link without href.

Pin that a new label only exists once the work package is saved

15601ea

akabiru self-assigned this Oct 23, 2026

akabiru added the DO NOT MERGE label Oct 23, 2026

github-advanced-security Bot found potential problems Oct 23, 2026

View reviewed changes

Comment thread app/models/concerns/labelable.rb Fixed

akabiru added the experiment label Oct 23, 2026

Resolve pending label names in one query

df8a4ad

The form echo and the contract looked a label up per name; both now match all names at once with the case folding done in Postgres.

akabiru added this pull request to stack #26273 October 23, 2026 11:44

akabiru mentioned this pull request Oct 23, 2026

[COMMS-1071] Create labels from the bulk edit and move forms #26272

Closed

akabiru removed this pull request from stack #26273 October 23, 2026 11:47

akabiru added the pullpreview label Oct 23, 2026

akabiru added 4 commits October 23, 2026 17:02

Check label creation permission once per work package validation

c51f055

Names that already exist are filtered in one query, so uniqueness and the permission lookup no longer run once per pending name on every form refresh.

Treat labels with the same name as one selection in the autocompleter

eef0a3d

A pending label and a persisted label with the same name are the same label, since the backend identifies labels by their lower-cased name.

Send pending labels even when the reference has no labels link

cdb2323

Without a labels link on the reference the base changeset writes raw resources into the payload and the pending titles were lost.

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

akabiru added 10 commits October 27, 2026 14:27

Merge branch 'dev' into implementation/comms-1071-create-labels-on-wo…

eb8455d

…rk-package-save

Validate pending label names through the model and cap them

bee8eb1

Running the model's own validation keeps the contract in step with Label; the cap bounds how many labels one save can create.

Compare labels by name only in the autocompleter

b87d852

Every item carries a name, so the href fallback could never run.

Ignore work package labels links while labels are disabled

0e5bbce

POST /api/v3/labels is hidden behind the flag, so saving a work package must not create labels or change labelings either.

Create labels typed into a work package in its services

9a351f9

Creating another aggregate's records as the acting user is service work; the model only refuses to save while names are unresolved. Names are created in a stable order so concurrent saves cannot deadlock.

Document limits on labels created through work package payloads

a78d740

API clients need the permission, length and per-request limits to handle the 422 responses.

Cover label creation permission on work package updates

53aef17

A shared work package grants edit rights without the project-wide right to create labels, so updates and their form must reject new names.

Keep label error options when reporting them on the work package

d61e9c5

Copying only the error symbols dropped the length limit, so rendering a too-long label name raised instead of answering with a 422.

Name the work package label step after what it does

c9913d7

FindOrCreateLabels says that typed names become existing or new labels; pending and resolve left the reader guessing.

Show rejected new label names on every labels editing surface

871a7aa

Labels are now created when the work package saves, so a bad name must come back as a field error in split view, the table and the create form.

akabiru added 3 commits October 27, 2026 17:40

State the actual rule for creating labels in the write model docs

4357e81

No permission is called create labels; the check is edit rights in any project, the same as POST /api/v3/labels.

Name the contract's label name checks after what they check

6f402eb

Pending said nothing about what the names are for; the checks validate label names and pick out the ones that would create labels.

Name the labels a work package will assign after their purpose

af507ef

The label ids and names are what the next save assigns, which pending did not say.

Validate label name replacements in their own contract concern

4697181

Mirrors Attachments::ValidateReplacements so the work package contract does not carry label rules inline.

akabiru removed DO NOT MERGE experiment labels Oct 27, 2026

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

akabiru added this to the 18.0.x milestone Oct 27, 2026

akabiru added the pullpreview label Oct 27, 2026

akabiru requested review from a team, HDinger and brunopagno October 27, 2026 15:54

akabiru marked this pull request as ready for review October 27, 2026 15:54

akabiru mentioned this pull request Oct 27, 2026

[COMMS-1050] Remove unused inline-created labels #26187

Closed

1 of 3 tasks

akabiru added 3 commits October 27, 2026 19:51

Keep the work package save as the last step when creating

abf5ab8

Labels are resolved on their own line, like attachments, so the save no longer reads as depending on them; the post-save steps move out to keep the method within the complexity limit.

Resolve label names after validation instead of inside persist

7f90120

The after_validate hook is the slot for work that needs a passed contract but no save yet, so persist stays the plain save.

Call labels without an href new records on the client

d8bd61e

Matches the server, which treats a title-only label link as a new record.

akabiru changed the title ~~[COMMS-1071] Create labels when the work package is saved~~ [COMMS-1071] Find or create labels when the work package is saved Oct 27, 2026

brunopagno approved these changes Oct 28, 2026

View reviewed changes

akabiru merged commit 0dd537b into dev Oct 28, 2026
27 checks passed

akabiru deleted the implementation/comms-1071-create-labels-on-work-package-save branch October 28, 2026 12:01

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

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

Navigation Menu

Repository navigation

[COMMS-1071] Find or create labels when the work package is saved - #26270

[COMMS-1071] Find or create labels when the work package is saved#26270
akabiru merged 26 commits into
devfrom
implementation/comms-1071-create-labels-on-work-package-save

akabiru commented Oct 23, 2026 •

edited

Loading

Uh oh!

Uh oh!

github-actions Bot commented Oct 23, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 23, 2026

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

brunopagno left a comment

Uh oh!

brunopagno Oct 28, 2026

Uh oh!

akabiru Oct 28, 2026

Uh oh!

brunopagno Oct 28, 2026 •

edited

Loading

Uh oh!

akabiru commented Oct 28, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Conversation

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

Uh oh!

Ticket

What are you trying to accomplish?

What approach did you choose and why?

AI involvement

Merge checklist

Uh oh!

Uh oh!

github-actions Bot commented Oct 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 Oct 23, 2026

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

brunopagno left a comment

Choose a reason for hiding this comment

Uh oh!

brunopagno Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

akabiru Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akabiru commented Oct 28, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

akabiru commented Oct 23, 2026 •

edited

Loading

github-actions Bot commented Oct 23, 2026 •

edited

Loading

brunopagno Oct 28, 2026 •

edited

Loading