[dfriquet]

Ticket

https://community.openproject.org/wp/SE-690

Stacked on #25872.

What are you trying to accomplish?

• "Create work package" in the menu of every forum message, for members allowed to add work packages
• Hovering a message reveals a "+ Work package" button next to its menu
• The work package creation dialog opens with the topic's subject and the message's content as description
• The work package activity tab links to the originating message ("Created from forum message ")
• Created work packages hang from the thread's lifeline right after their originating message
• The topic header lists the work packages created from the topic, after the participants count

Screenshots

Message menu with "Create work package"

Card header with the button on hover

Prefilled creation dialog

Work package hanging from the lifeline after its message

Topic header listing the created work packages

Work package activity tab with "Created from forum message"

What approach did you choose and why?

• A message_work_packages join table links a work package to its originating message (one message per work package); the journal cause forum_message only serves the activity tab.
• Journal aggregation no longer folds a change without a cause into a journal that has one: before, the same user's edit right after creation wiped the cause, and a comment following a meeting cause would have inherited it.
• The activity tab now shows a creation entry's cause (except "Read-only attributes written"): within the aggregation window the cause lands on the creation journal, whose details were never shown.
• A message the user cannot see answers 404 (view_messages is public, so this is a project without the forums module).
• Left for later: inline images copied into the description keep pointing at the message's attachments.

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)

[github-actions]

Warning

Flaky specs

• rspec ./modules/bim/spec/features/bim_filter_spec.rb[1:1:1]
• rspec ./spec/features/projects/creation_wizard/wizard_from_template_flow_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 #25909, linked for reference only):

- `rspec ./modules/bim/spec/features/bim_filter_spec.rb[1:1:1]`
- `rspec ./spec/features/projects/creation_wizard/wizard_from_template_flow_spec.rb[1:1]`

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

[oliverguenther]

Quick feedback from the top of my head: I'd say the + Work package action is a bit too prominent as a button. I'd probably prefer it as an action menu.

[github-actions]

Warning

Flaky specs

• rspec ./modules/gantt/spec/features/timeline/timeline_dates_spec.rb[1:2:1]
• rspec ./spec/features/types/form_configuration_query_spec.rb[1:1:9: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 #25909, linked for reference only):

- `rspec ./modules/gantt/spec/features/timeline/timeline_dates_spec.rb[1:2:1]`
- `rspec ./spec/features/types/form_configuration_query_spec.rb[1:1:9:1:1]`

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

[dfriquet]

Quick feedback from the top of my head: I'd say the + Work package action is a bit too prominent as a button. I'd probably prefer it as an action menu.

It’s both an action menu item, and a button. The button only appears when hovering the message card. The idea behind that extra button was:

1. to put some spotlight on the forums tightly coupling with our project management system’s core feature;
2. on hover so that it does not clutter the UI showing up on every message, with the action menu item as fallback for mobile for example.

[oliverguenther]

Quick feedback from the top of my head: I'd say the + Work package action is a bit too prominent as a button. I'd probably prefer it as an action menu.

It’s both an action menu item, and a button. The button only appears when hovering the message card. The idea behind that extra button was:

1. to put some spotlight on the forums tightly coupling with our project management system’s core feature;
2. on hover so that it does not clutter the UI showing up on every message, with the action menu item as fallback for mobile for example.

I missed the hovering bit, that's perfectly fine to me then 👍

[github-actions]

Warning

Flaky specs

• rspec ./modules/boards/spec/features/board_navigation_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 #25909, linked for reference only):

- `rspec ./modules/boards/spec/features/board_navigation_spec.rb[1:1]`

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

[oliverguenther]

Smoke tested locally, LGTM 👍 Same comment as with the other PR, please document a draft for the docs (can be a separate PR all together an assigned to Maya)

[dfriquet]

Same comment as with the other PR, please document a draft for the docs (can be a separate PR all together an assigned to Maya)

@oliverguenther You can find it in the middle of a spike. It will be easily extracted if I can’t stabilize the groundwork for general availability.