Change Details

NOTE: Remove sections that are not needed. Instead, leave the section and write NOT NEEDED as its content. **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. ====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) ====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`) ====Gherkin scenarios==== NOTE: This are all drafts and we will refine them 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_event_id, cewa_page_id, cewa_page_title - And "cewa_id" is the primary key and auto-increments - And "cewa_page_title" is stored as varbinary with max length 255 [] Scenario: cewa_event_id references campaign_events.event_id - Given the worklist articles table has been created - Then the "cewa_event_id" column has a foreign key to "campaign_events.event_id"

NOTE: Remove sections that are not needed. Instead, leave the section and write NOT NEEDED as its content. **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_event_id` (unsigned bigint) - `cewa_page_prefixedtext` (varbinary(512)) - `cewa_wiki` (varchar(64)) - `cewa_user_id` (unsigned int) * 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. ====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) ====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 `cewa_event_id` for per event 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`) ====Gherkin scenarios==== NOTE: This are all drafts and we will refine them ==== Questions ===== 1 - Do we plan to show the username of who added the article to the list? - If yes, we will need to store the username. 2 - For delete should it be hard or soft delete? 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_event_id, cewa_page_id, cewa_page_title - And "cewa_id" is the primary key and auto-increments - And "cewa_page_title" is stored as varbinary with max length 255 [] Scenario: cewa_event_id references campaign_events.event_id - Given the worklist articles table has been created - Then the "cewa_event_id" column has a foreign key to "campaign_events.event_id"

NOTE: Remove sections that are not needed. Instead, leave the section and write NOT NEEDED as its content. **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))a_id` (PK, and `cewa_ceil_id` (unsigned bigint).auto-increment) - `cewa_page_id` (unsigned int) - `cewa_event_id` (unsigned bigint) - `cewa_page_prefixedtext` (varbinary(512)) - `cewa_wiki` (varchar(64)) - `cewa_user_id` (unsigned int) * 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. ====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) ====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_ceilwa_event_id` for invitation lisper event 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`) ====Gherkin scenarios==== NOTE: This are all drafts and we will refine them ==== Questions ===== 1 - Do we plan to show the username of who added the article to the list? - If yes, we will need to store the username. 2 - For delete should it be hard or soft delete? 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_event_id, cewa_page_id, cewa_page_title - And "cewa_id" is the primary key and auto-increments - And "cewa_page_title" is stored as varbinary with max length 255 [] Scenario: cewa_event_id references campaign_events.event_id - Given the worklist articles table has been created - Then the "cewa_event_id" column has a foreign key to "campaign_events.event_id"