chore(release): sync main back into development - #3292
Open
github-actions[bot] wants to merge 10 commits into
Open
chore(release): sync main back into development#3292github-actions[bot] wants to merge 10 commits into
github-actions[bot] wants to merge 10 commits into
Conversation
Version1Date20260706110000's CREATE EXTENSION line was added on 2026-07-21 (commit 15d9345), after the migration had already shipped and been recorded as run on existing installations. Nextcloud runs each app+version row exactly once, so instances that migrated through the intermediate window never install pg_trgm — and every _fuzzy=true request silently degrades to unindexed ILIKE with no @self.relevance field. Confirmed on the dev-env instance: oc_migrations recorded 1Date20260706110000 as run, pg_extension had only plpgsql. Add a new migration file — a fresh app+version row — that idempotently re-runs CREATE EXTENSION IF NOT EXISTS pg_trgm with the same tolerant- failure contract as the original. Instances that already have pg_trgm installed take the "already installed" branch and log an info message. Unblocks the WOO-536 fulltext-search fuzzy path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
… (WOO-536) Addresses review #5077597717 findings: F1 (concern) — CI `quality / Features Check` was red on `docs/features.json` baseline drift (annotation: "docs/features.json is out of date — run scripts/extract-features.py to regenerate"). Regenerated via the canonical ConductionNL/.github/scripts/extract-features.py — added the "RBAC-as-Public Toggle" entry the openspec change was missing. F2 (nit) — added the `@spec openspec/changes/searchable-property-index/tasks.md#1.1` tag on both the class docblock and the postSchemaChange method docblock, matching the sibling Version1Date20260706110000. Keeps the feature-to- bootstrap traceability chain intact. F3 (nit) — happy-path log now distinguishes the no-op re-run from the actual install-by-re-run. Probes `pg_extension` before the CREATE EXTENSION call; on success emits either "already installed (no-op re-run)" (the vast majority of instances) or "installed by re-run" (the instances this PR exists to fix). Probe failure falls through — the CREATE EXTENSION statement is idempotent regardless. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…-536) CI PR check `quality / PHP Quality (phpcs)` failed on two style errors in the pg_extension probe/log-differentiation refactor: - `$result = ...` inside the nested try had equals-sign alignment drift (14 spaces before `=` vs. 1 required). - No blank line after the closing brace of the `if ($wasAlreadyInstalled === true)` block before the `return` statement. Both auto-fixed via phpcbf. Same runtime semantics; phpcs clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Resolves merge conflict on docs/features.json by regenerating the baseline against the merged tree — main's newer openspec catalog takes over (22 features vs. 27 pre-merge; the rbac-as-public-toggle archive dir was reorganised away on main during the 501-commit window since this branch was cut at 2c73432, so the extractor no longer picks up that entry). Also reformats lib/Migration/Version1Date20260901000000.php to match the new sibling shape on main (Version1Date20260706110000.php) — tab indentation, K&R braces on same line, concatenated warning string. Zero semantic change. Effective PR diff vs main is now just the new migration file, as originally intended. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fix(migration): re-run pg_trgm CREATE EXTENSION on all instances (WOO-536 unblock)
…ation filters (WOO-548)
Three methods in MagicSearchHandler emitted PostgreSQL-only
`jsonb_typeof(...)`, `to_jsonb(...::text)` and JSON containment `@>`
without a platform check:
- applyRelationsContainsFilter (single-schema path)
- applyRelationFieldFilter (single-schema, dotted-field)
- buildRelationFilterConditionsSql (multi-schema UNION path)
On MariaDB / MySQL these raise SQLSTATE[42601] or silently return an
empty set. WOO-536 Stap 5a (OpenCatalogi public search) consumes
`_relations_contains` on every document-refinement, so the defect
surfaces on every `/api/search` request on non-Postgres deployments.
Mirrors the WOO-544 pattern (openregister#3197): branch on
`isPostgresPlatform()` and keep the existing jsonb SQL on Postgres.
For the MariaDB/MySQL fallback:
- `applyRelationsContainsFilter` uses `JSON_SEARCH(..., 'one', ...)`,
which walks both array- and object-shaped relations natively.
- `applyRelationFieldFilter` / `buildRelationFilterConditionsSql`
combine `JSON_EXTRACT` on the exact path, `JSON_SEARCH` scoped to
the array-indexed `$.<field>.%` sub-path, and `JSON_CONTAINS` for
the legacy top-level-array shape.
All available on MariaDB 10.2+ / MySQL 5.7+, both mandated by the
Nextcloud platform baseline.
Tests:
- existing sibling test now pins the platform mock to Postgres so its
hard-coded jsonb assertions keep passing
- new MariaDbTest fixes the platform to MariaDB and asserts the SQL
is free of PG-only syntax + carries the expected JSON_ builtins
Ref: WOO-548, parent WOO-536
…nce doc - Add SPDX-License-Identifier + SPDX-FileCopyrightText headers on the new MariaDbTest file (year 2026), matching the 2025+ convention every other test in tests/Unit/Db/ uses (was @copyright 2024, non-machine-readable). - Lock the applyRelationsContainsFilter MariaDB fallback with a fresh test — this method is the direct consumer of the `_relations_contains` public query filter (WOO-536 Stap 5a) and had no automated MariaDB coverage. - Document the flat-dot-in-key semantic divergence between the PG and MariaDB branches of applyRelationFieldFilter: PG's `kv.key LIKE 'x.%'` matches a top-level flat key literally named `x.1`, MariaDB's `\$.x.%` is a JSON path navigator and does not. No writer produces the flat-dot-in-key shape today (verified via grep), so the two branches remain semantically equivalent for every shape produced in practice. Ref: WOO-548
…h-handler-pg-guards fix(db): guard PostgreSQL-only jsonb syntax in MagicSearchHandler relation filters (WOO-548)
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The 2.0.12 release bumped the version on main. Without this, development stays behind main and the next development -> main promotion conflicts on the version file. Version files resolve to development's side, which is the higher line, so this never moves a version backwards.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Opened by the release workflow after publishing 2.0.12 from
main.A release commits a version bump onto the branch it ran from. Without carrying
that back,
developmentfalls behindmain, and since both branches thenchanged the version file independently, the next
development -> mainpromotion conflicts on it — every time.
Version files are resolved to development's side, the higher line, so this
cannot move a version backwards. Any other conflict stops the workflow instead
of being resolved automatically.
Merge this, do not squash. A squash copies the files and discards the
relationship: the merge base would not move and the next promotion would
conflict exactly as before. A 0-file diff here is normal and is not a no-op —
recording the ancestry is the whole point.