Consolidate 25 historical 2.x migrations into one end-of-2.8 schema

CHANGELOG.md

@@ -4,6 +4,10 @@ All notable changes to this project will be documented in this file.
 
 ## [Unreleased]
 
+- Consolidated 25 historical 2.x Doctrine migrations into a single end-of-2.8 schema migration;
+  upgraders run `doctrine:migrations:rollup` (see `UPGRADE.md` step 3).
+- Restored three deprecated `Template` properties (`icon`, `resources`, `description`) as
+  write-only fields; scheduled for removal in 3.1.
 - Merged fixes from 2.7.0 into release/3.0.0.
 - Added `INSTANT_BOOK_BUSY_INTERVALS_SOURCE` to select between Graph and the slide's calendar feed as the source of busy
   intervals for InstantBook.

UPGRADE.md

@@ -73,12 +73,36 @@ Rename the following .env variables in `.env.local`:
 - From `APP_KEY_VAULT_SOURCE` to `KEY_VAULT_SOURCE`
 - From `APP_KEY_VAULT_JSON` to `KEY_VAULT_JSON`
 
-#### 3 - Run doctrine migrate
+#### 3 - Consolidate Doctrine migrations
+
+3.0 ships a single consolidated migration that represents the end-of-2.8 schema. The 25 historical
+2.x migrations have been removed from the repository.
+
+Because every upgrading database already matches that consolidated schema (via the 25 migrations it
+ran while on 2.x), there is nothing for `doctrine:migrations:migrate` to do — and running it would
+fail because of the orphaned version entries. Use `doctrine:migrations:rollup` instead, which
+truncates the `doctrine_migration_versions` table and inserts a single row marking the consolidated
+migration as already executed:
 
 ```shell
-docker compose exec phpfpm bin/console doctrine:migrations:migrate
+# Confirm the database is at the latest 2.8.x state before rolling up.
+# All 25 historical versions should appear as "migrated" / "available".
+docker compose exec phpfpm bin/console doctrine:migrations:status
+
+# Replace the 25 historical version entries with the single consolidated entry.
+# This does not run any SQL — it only rewrites the version-tracking table.
+docker compose exec phpfpm bin/console doctrine:migrations:rollup --no-interaction
 ```
 
+> **Prerequisite:** the database must be on the final 2.8.x release with every 2.x migration
+> applied. If `doctrine:migrations:status` (run while still on 2.8.x) reports any pending
+> migrations, run `doctrine:migrations:migrate` on 2.8.x first, then upgrade to 3.0 and continue
+> here.
+
+Fresh installs (no prior 2.x database) skip the rollup and run
+`doctrine:migrations:migrate` instead — it executes the single consolidated migration and brings
+the schema up in one step.
+
 #### 4 - Run template list command to see status for installed templates
 
 ```shell

config/api_platform/template.yaml

@@ -32,7 +32,7 @@ resources:
 
             ApiPlatform\Metadata\GetCollection:
                 filters:
-                    - 'entity.search_filter'
+                    - 'template.search_filter'
                     - 'entity.blameable_filter'
                     - 'created.at.order_filter'
                     - 'modified.at.order_filter'

config/services.yaml

@@ -313,6 +313,19 @@ services:
         tags: ['api_platform.filter']
         arguments: [{ title: 'partial', description: 'partial' }]
 
+    # Template-specific search filter — Template's `description` column is
+    # deprecated and slated for removal in 3.1, so it is intentionally not
+    # exposed as a queryable property here. (`#[ApiFilter]` and
+    # `#[ApiProperty]` attributes on the entity don't affect filter
+    # discovery while Template's resource is YAML-configured, so the
+    # exclusion has to live here.)
+    # TODO[3.1]: drop this and switch the GetCollection back to the shared
+    # `entity.search_filter` once the deprecated property is gone.
+    template.search_filter:
+        parent: 'api_platform.doctrine.orm.search_filter'
+        tags: ['api_platform.filter']
+        arguments: [{ title: 'partial' }]
+
     entity.blameable_filter:
         parent: 'api_platform.doctrine.orm.search_filter'
         tags: ['api_platform.filter']