Wiring up actual page creation to the dialog that has been prepared
beforehand.
The commands are merely responsible for creating pages in the corresponding
wiki provider. The new CreateLinkedPageService takes care of combining
the two steps needed by the UI:
1. Creating the page
2. Linking it
The :only_changes filter re-seeked each journal's predecessor in every EXISTS
branch (~7 LATERAL lookups per row). A CTE now shadows the journals table,
exposing predecessor_id/predecessor_data_id once per row, and each branch reads
those columns instead. On a 703-journal work package this cuts the COUNT from
~1.13M to ~35K shared buffers.
This is only done to improve worst-case latency, because
we perform one additional request per result.
Local testing showed a latency above 1000ms for 50 results
and ~500ms for 20 results. I'd expect real world scenarios to
be slightly worse, because of higher network latency.
We now have two ways to fetch page infos from XWiki:
* using the canonical identifier (but through a new endpoint that will resolve stable identifiers as well)
* using the stable identifier
Since we want to store the stable identifier, the stable version is the one exposed through the XWiki registry.
The canonical form is required to fully resolve some list queries from XWiki properly.
* Use new async FilterableTreeView for global project selector
* Remove replaced angular component
* Fine tune sorting and expansion state of the new project selector
* Update primer to 0.86.1
* Add workspace information and filter results hierarchy information to project selector
* Include review feedback: Harmonize I18n keys, fix visible scope, use guarded local storage
* Add a turboFrame in the project select overlay to only load the projects when it is actually opened
* Restore BIM tab styles which were broken for a while already but the new project selector changes made it so bad that the test broke because the plus icon was overlapping the checkbox
* Clarify spec expectation
rspec ./spec/features/search/search_spec.rb:307
the search for the first work package, having 1 in the subject, led to all 1x work packages being found.
https://community.openproject.org/wp/STC-462
Two readability passes over the work package activity tab, no behaviour change. The paginator's private methods are reordered to follow their call order so the file reads top-down from `#call`, and the three activity filter modes (`:all`, `:only_comments`, `:only_changes`) — until now bare symbols duplicated across the controller, paginator, journal components and the hidden form — move into a single `WorkPackages::ActivitiesTab::Filters` module so the modes have one source of truth and can't drift apart. The diff reaches beyond the paginator into the controller, several components and a form, since that's where the symbols were scattered.
The Paginator.paginate class method bypassed the instance, discarding the
resolved_anchor state the controller reads after .call; it had no callers, so
drop it and keep the single new(...).call entry point. Extract the activity
anchor side effect into record_resolved_anchor so the intent is explicit at the
call site, and pin the server contract with a request spec asserting an
unresolvable activity anchor omits the resolved-comment value.
The work package activity tab computed a per-journal sequence_version on
every render — a ROW_NUMBER() window function over a LATERAL join — only to
stamp the legacy data-anchor-activity-id that #activity-N deep links rely on.
Nothing mints those links anymore; copy and share links use
#comment-<journal id>, which needs no extra query.
The activity number is now resolved on demand. Only a request carrying
?anchor=activity-N runs the window function, mapping the number to a journal
id the paginator exposes as resolved_anchor. The view hands that to the
client, which rewrites #activity-N to the canonical #comment-<id> and scrolls
using the comment anchor already present in the DOM. Default renders no longer
touch the window function.
References WP #68063.
rspec ./spec/features/activities/work_package/activities_spec.rb:678
The attempt is to have the frontend wait for the turbo stream response rather than a fixed timeout.
The removed wait_for seems to be non-functional.
Jan Sandbrink