Change Details

**Background**: The worklist feature requires a dedicated DB table to store articles associated with invitation lists. This task creates the `ce_worklist_articles` table via an abstract schema change in `db_patches/abstractSchemaChanges`, following the existing CampaignEvents DB patch conventions and generating SQL for each supported DB engine. ====Type of story==== * Backend ====Acceptance criteria==== * The migration creates the `ce_worklist_articles` table with the expected columns used in CampaignEvents: `cewa_id` (PK, auto-increment), `cewa_page_id` (unsigned int), `cewa_page_title` (varbinary(255)), and `cewa_ceil_id` (unsigned bigint). * The schema follows the existing naming and format conventions in `db_patches/abstractSchemaChanges` and is reflected in generated SQL under `db_patches/mysql`, `db_patches/postgres`, and `db_patches/sqlite`. * The table is created successfully on a clean MediaWiki install and on update via `update.php`. * No data is inserted by this migration — schema only. ====Design==== * NOT NEEDED ====Error messages and copy included==== * For happy path: NOT NEEDED * For unhappy path: NOT NEEDED ====Are there dependencies (on someone else or learning something new)?==== * NOT NEEDED ====Depends on==== * NOT NEEDED ====Testing required?==== * Yes * Minimum testing to pass QA: The table schema is verified end-to-end by the frontend tasks that exercise the full add/list/delete flow. * Tested end-to-end in: task-8 (Worklist tab — add article form) and task-9 (article list table) ====messages(i18n)==== * NOT NEEDED ====Technical details==== * Use an abstract schema JSON patch in `db_patches/abstractSchemaChanges` as source of truth, then generate DB-specific SQL files (do not hand-edit generated SQL files). * Keep the table schema aligned with current CampaignEvents conventions for worklist articles (`cewa_*` field naming). * `cewa_page_title` stores mainspace page title for redlink handling. * Add index `ce_worklist_articles_ceil_id` on `cewa_ceil_id` for invitation list lookups. * Ensure `src/Hooks/Handlers/SchemaChangesHandler.php` registers the table creation with `addExtensionUpdateOnVirtualDomain( ..., 'addTable', 'ce_worklist_articles', "$dir/$dbType/patch-add-ce_worklist_articles.sql", ... )` so `update.php` applies it in the CampaignEvents virtual domain. ====Split patches suggestion==== * Branch 1: DB migration file only (schema definition for `ce_worklist_articles`) ====API documentation==== * NOT NEEDED ====Gherkin scenarios==== ```gherkin Feature: Worklist articles DB table schema Scenario: Table exists with all required columns after migration Given a MediaWiki instance with the CampaignEvents extension installed When the DB migration for the worklist articles table is applied Then the table "ce_worklist_articles" exists in the database And it has columns: cewa_id, cewa_page_id, cewa_page_title, cewa_ceil_id And "cewa_id" is the primary key and auto-increments And "cewa_page_title" is stored as varbinary with max length 255 Scenario: Index on invitation list ID supports list-based queries Given the worklist articles table has been created Then an index named "ce_worklist_articles_ceil_id" exists And the index contains the "cewa_ceil_id" column ```

**Background**: The worklist feature requires a dedicated DB table to store articles associated with invitation lists. This task creates the `ce_worklist_articles` table via an abstract schema change in `db_patches/abstractSchemaChanges`, following the existing CampaignEvents DB patch conventions and generating SQL for each supported DB engine. ====Type of story==== * Backend ====Acceptance criteria==== * The migration creates the `ce_worklist_articles` table with the expected columns used in CampaignEvents: `cewa_id` (PK, auto-increment), `cewa_page_id` (unsigned int), `cewa_page_title` (varbinary(255)), and `cewa_ceil_id` (unsigned bigint). * The schema follows the existing naming and format conventions in `db_patches/abstractSchemaChanges` and is reflected in generated SQL under `db_patches/mysql`, `db_patches/postgres`, and `db_patches/sqlite`. * The table is created successfully on a clean MediaWiki install and on update via `update.php`. * No data is inserted by this migration — schema only. ====Design==== * NOT NEEDED ====Error messages and copy included==== * For happy path: NOT NEEDED * For unhappy path: NOT NEEDED ====Are there dependencies (on someone else or learning something new)?==== * NOT NEEDED ====Depends on==== * NOT NEEDED ====Testing required?==== * Yes * Minimum testing to pass QA: The table schema is verified end-to-end by the frontend tasks that exercise the full add/list/delete flow. * Tested end-to-end in: task-TBD (Worklist tab — add article form) and task-TBD (article list table) ====messages(i18n)==== * NOT NEEDED ====Technical details==== * Use an abstract schema JSON patch in `db_patches/abstractSchemaChanges` as source of truth, then generate DB-specific SQL files (do not hand-edit generated SQL files). * Keep the table schema aligned with current CampaignEvents conventions for worklist articles (`cewa_*` field naming). * `cewa_page_title` stores mainspace page title for redlink handling. * Add index `ce_worklist_articles_ceil_id` on `cewa_ceil_id` for invitation list lookups. * Ensure `src/Hooks/Handlers/SchemaChangesHandler.php` registers the table creation with `addExtensionUpdateOnVirtualDomain( ..., 'addTable', 'ce_worklist_articles', "$dir/$dbType/patch-add-ce_worklist_articles.sql", ... )` so `update.php` applies it in the CampaignEvents virtual domain. ====Split patches suggestion==== * Branch 1: DB migration file only (schema definition for `ce_worklist_articles`) ====API documentation==== * NOT NEEDED ====Gherkin scenarios==== ```gherkin Feature: Worklist articles DB table schema Scenario: Table exists with all required columns after migration Given a MediaWiki instance with the CampaignEvents extension installed When the DB migration for the worklist articles table is applied Then the table "ce_worklist_articles" exists in the database And it has columns: cewa_id, cewa_page_id, cewa_page_title, cewa_ceil_id And "cewa_id" is the primary key and auto-increments And "cewa_page_title" is stored as varbinary with max length 255 Scenario: Index on invitation list ID supports list-based queries Given the worklist articles table has been created Then an index named "ce_worklist_articles_ceil_id" exists And the index contains the "cewa_ceil_id" column ```

**Background**: The worklist feature requires a dedicated DB table to store articles associated with invitation lists. This task creates the `ce_worklist_articles` table via an abstract schema change in `db_patches/abstractSchemaChanges`, following the existing CampaignEvents DB patch conventions and generating SQL for each supported DB engine. ====Type of story==== * Backend ====Acceptance criteria==== * The migration creates the `ce_worklist_articles` table with the expected columns used in CampaignEvents: `cewa_id` (PK, auto-increment), `cewa_page_id` (unsigned int), `cewa_page_title` (varbinary(255)), and `cewa_ceil_id` (unsigned bigint). * The schema follows the existing naming and format conventions in `db_patches/abstractSchemaChanges` and is reflected in generated SQL under `db_patches/mysql`, `db_patches/postgres`, and `db_patches/sqlite`. * The table is created successfully on a clean MediaWiki install and on update via `update.php`. * No data is inserted by this migration — schema only. ====Design==== * NOT NEEDED ====Error messages and copy included==== * For happy path: NOT NEEDED * For unhappy path: NOT NEEDED ====Are there dependencies (on someone else or learning something new)?==== * NOT NEEDED ====Depends on==== * NOT NEEDED ====Testing required?==== * Yes * Minimum testing to pass QA: The table schema is verified end-to-end by the frontend tasks that exercise the full add/list/delete flow. * Tested end-to-end in: task-8TBD (Worklist tab — add article form) and task-9TBD (article list table) ====messages(i18n)==== * NOT NEEDED ====Technical details==== * Use an abstract schema JSON patch in `db_patches/abstractSchemaChanges` as source of truth, then generate DB-specific SQL files (do not hand-edit generated SQL files). * Keep the table schema aligned with current CampaignEvents conventions for worklist articles (`cewa_*` field naming). * `cewa_page_title` stores mainspace page title for redlink handling. * Add index `ce_worklist_articles_ceil_id` on `cewa_ceil_id` for invitation list lookups. * Ensure `src/Hooks/Handlers/SchemaChangesHandler.php` registers the table creation with `addExtensionUpdateOnVirtualDomain( ..., 'addTable', 'ce_worklist_articles', "$dir/$dbType/patch-add-ce_worklist_articles.sql", ... )` so `update.php` applies it in the CampaignEvents virtual domain. ====Split patches suggestion==== * Branch 1: DB migration file only (schema definition for `ce_worklist_articles`) ====API documentation==== * NOT NEEDED ====Gherkin scenarios==== ```gherkin Feature: Worklist articles DB table schema Scenario: Table exists with all required columns after migration Given a MediaWiki instance with the CampaignEvents extension installed When the DB migration for the worklist articles table is applied Then the table "ce_worklist_articles" exists in the database And it has columns: cewa_id, cewa_page_id, cewa_page_title, cewa_ceil_id And "cewa_id" is the primary key and auto-increments And "cewa_page_title" is stored as varbinary with max length 255 Scenario: Index on invitation list ID supports list-based queries Given the worklist articles table has been created Then an index named "ce_worklist_articles_ceil_id" exists And the index contains the "cewa_ceil_id" column ```