There can be race conditions when the resource update is failing after a
type swtich and the form for the updated type needs to be fetched.
Sometimes, the old form is used (from the former type) which does not
have information on a custom field property.
In this case, a fallback is added to force fetching the form.
This solution is not ideal as an additional request is sent to the
server. Ideally, the changes to the table should only be rendered after
the schema (as part of the form) is present.
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.
Instead of raising an error, we use throw-catch based control flow
to return the same failure that would be returned if the response
had not been JSON at all.
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.
This represents XWikis default way of representing page references, but
those are susceptible to become invalid after a page or space gets renamed.
We'll also support other page references, so it's important to distinguish that
multiple reference types exist.
Making them consistent with the internal wiki view.
Essentially we have a two-level navigation on the left
and that needs to be reflected in the breadscrumbs everywhere.
The LATERAL subquery is aliased `predecessor` where it is joined rather
than inside the helper, so the relation each EXISTS clause references is
visible without reading the helper.
Fix vertical content jumps in the BlockNote editor on selection
BlockNote 0.51 puts the className we pass to <BlockNoteView>
(`block-note-editor-container`) onto BOTH the outer `.bn-container`
wrapper AND an inner wrapper that does NOT carry `.bn-container`. With
the previous selector matching by class name alone, every rule cascaded
onto both nesting levels — most importantly `display: flex`,
`flex-direction: column-reverse` and `gap: 10px`.
Two flex layouts stacked one inside the other meant that whenever the
side menu / drag handle plugin views re-rendered (which happens every
time the selection moves or the mouse leaves the editor), both layout
calcs ran and the inner wrapper's gap shifted the visible content by a
few pixels.
Tightening the selector to `.block-note-editor-container.bn-container`
restricts the rules to the outer wrapper only; the inner wrapper falls
back to defaults (`display: block`, no gap) and stops contributing to
the layout.
Refs https://community.openproject.org/wp/STC-779
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
ulferts