[COMMS-938] Allow to search for "#<semantic WP ID>" by judithroth · Pull Request #24662 · opf/openproject

judithroth · 2026-08-07T12:42:06Z

Ticket

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

What are you trying to accomplish?

Searching for "#PROJ-11" should lead to the same result as searching for "PROJ-11".

Merge checklist

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

Copilot

Pull request overview

Enables hash-prefixed semantic work package searches such as #PROJ-11.

Changes:

Strips the hash when filtering and ranking semantic identifiers.
Adds coverage for hash-prefixed searches and exact-match ranking.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
`app/models/queries/work_packages/filter/typeahead_filter.rb`	Parses optional hash prefixes before identifier filtering.
`app/models/queries/work_packages/selects/exact_match_select.rb`	Uses the normalized identifier for ranking.
`spec/models/queries/work_packages/filter/typeahead_filter_spec.rb`	Tests hash-prefixed filtering.
`spec/models/queries/work_packages/selects/exact_match_select_spec.rb`	Tests hash-prefixed exact-match ranking.

github-actions · 2026-08-10T10:31:37Z

Warning

Flaky specs

rspec ./spec/features/activities/work_package/activities_spec.rb[1:5:2: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 #24662, linked for reference only):

- `rspec ./spec/features/activities/work_package/activities_spec.rb[1:5:2:1]`

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

dombesz · 2026-08-10T13:35:25Z

+    if (match = part.match(/\A(#)?(#{Projects::Identifier::SEMANTIC_FORMAT.source}-?\d*)\z/i))
+      conditions << work_package_identifier_condition(match[2])


I wonder why we need to capture the #? It does not seem to be used anywhere.

Suggested change

if (match = part.match(/\A(#)?(#{Projects::Identifier::SEMANTIC_FORMAT.source}-?\d*)\z/i))

conditions << work_package_identifier_condition(match[2])

if (match = part.match(/\A#?(#{Projects::Identifier::SEMANTIC_FORMAT.source}-?\d*)\z/i))

conditions << work_package_identifier_condition(match[1])

👀 Eagle eyes! Thanks a lot for this comment. Together with your feedback here and after sleeping a night over it, I now implemented it the following way:

If the instance is in semantic mode, searching by a semantic identifier with or without "#" works

If the instance is in classic (numeric) mode, searching by a semantic identifier only works when prefixed with "#"

This is the same (but reverse) like in semantic mode, where searching for a number only searches by the ID if prefixed with "#". It should mainly help to keep the search fast by not including search results that are probably not wanted and also keep the search results understandable.

Thanks for pointing it out!

github-actions · 2026-08-10T23:13:18Z

Deploying openproject with ⚡ PullPreview

Field	Value
Latest commit	`226d9bc`
Job	`deploy`
Status	✅ Deploy successful
Preview URL	https://pr-24662-comms-938-allow-to-ip-2-28-16-107.my.opf.run:443

View logs

github-actions · 2026-08-11T11:44:29Z

Warning

Flaky specs

rspec ./spec/features/activities/work_package/activities_spec.rb[1:5:2: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 #24662, linked for reference only):

- `rspec ./spec/features/activities/work_package/activities_spec.rb[1:5:2:1]`

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

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

…sh-prefixed https://community.openproject.org/wp/COMMS-938 This has two advantages: 1. It's easier to understand since it works the same way in classic identifier mode: Only when the number is prefixed with a hash the ID is searched 2. Otherwise in classic identifier mode the WorkPackageSemanticAlias table would be hit for every string that starts with a letter, which is unnecessary and makes the search even slower

thykel

🚀 🚀

judithroth requested a balanced review from Copilot August 7, 2026 12:42

Copilot started reviewing on behalf of judithroth August 7, 2026 12:42 View session

Copilot AI reviewed Aug 7, 2026

View reviewed changes

Comment thread app/models/queries/work_packages/filter/typeahead_filter.rb Outdated

judithroth force-pushed the implementation/comms-938-allow-to-search-for-semantic-wp-id branch from c9fd54e to 1a7404b Compare August 10, 2026 09:43

Base automatically changed from implementation/comms-926-implement-and-use-exact-matching-order-for-work-package-sequence-numbers to dev August 10, 2026 10:09

judithroth force-pushed the implementation/comms-938-allow-to-search-for-semantic-wp-id branch 2 times, most recently from a6669fb to c0b2ecc Compare August 10, 2026 10:12

judithroth marked this pull request as ready for review August 10, 2026 11:25

judithroth requested review from a team and dombesz August 10, 2026 11:25

dombesz approved these changes Aug 10, 2026

View reviewed changes

thykel added the pullpreview label Aug 10, 2026

judithroth requested a review from dombesz August 11, 2026 08:47

judithroth force-pushed the implementation/comms-938-allow-to-search-for-semantic-wp-id branch 4 times, most recently from c97a537 to d740bc2 Compare August 11, 2026 11:24

judithroth force-pushed the implementation/comms-938-allow-to-search-for-semantic-wp-id branch 4 times, most recently from a14a857 to dd87aab Compare August 12, 2026 08:44

judithroth added 2 commits August 12, 2026 11:00

[COMMS-938] Allow to search for "#<semantic WP ID>"

944a6a5

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

judithroth force-pushed the implementation/comms-938-allow-to-search-for-semantic-wp-id branch from dd87aab to 226d9bc Compare August 12, 2026 09:00

thykel approved these changes Aug 12, 2026

View reviewed changes

judithroth merged commit b227d10 into dev Aug 12, 2026
13 of 14 checks passed

judithroth deleted the implementation/comms-938-allow-to-search-for-semantic-wp-id branch August 12, 2026 10:47

github-actions Bot locked and limited conversation to collaborators Aug 12, 2026

github-actions Bot removed the pullpreview label Aug 12, 2026

Navigation Menu

Uh oh!

[COMMS-938] Allow to search for "#<semantic WP ID>" - #24662

[COMMS-938] Allow to search for "#<semantic WP ID>"#24662
judithroth merged 2 commits into
devfrom
implementation/comms-938-allow-to-search-for-semantic-wp-id

judithroth commented Aug 7, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

github-actions Bot commented Aug 10, 2026

Uh oh!

dombesz Aug 10, 2026

Uh oh!

judithroth Aug 11, 2026

Uh oh!

github-actions Bot commented Aug 10, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 11, 2026

Uh oh!

thykel left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

		if (match = part.match(/\A(#)?(#{Projects::Identifier::SEMANTIC_FORMAT.source}-?\d*)\z/i))
		conditions << work_package_identifier_condition(match[2])

Uh oh!

Conversation

judithroth commented Aug 7, 2026

Ticket

What are you trying to accomplish?

Merge checklist

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

github-actions Bot commented Aug 10, 2026

Uh oh!

dombesz Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

judithroth Aug 11, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 10, 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 Aug 11, 2026

Uh oh!

thykel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

github-actions Bot commented Aug 10, 2026 •

edited

Loading