Page MenuHomePhabricator

Add worklist articles table
Open, In Progress, Needs TriagePublic

Description

NOTE: Remove sections that are not needed. Instead, leave the section and write NOT NEEDED as its content.

Background: The Worklist tab (task-7) needs to display the list of articles added to the event worklist. Data is loaded server-side (PHP), following the same pattern as the Contributions tab in EventDetails — NOT via a frontend REST API call. The table shows article title (as a clickable cross-wiki link) and date added, with pagination. The delete Actions column is NOT part of this task (it is added in T423732 ).

Type of story
  • Front end / Backend
Acceptance criteria
  • The article list is loaded server-side, no frontend REST call is made on initial page load.
  • The table displays 4 columns: Article title (clickable link to the article on its wiki, cross-wiki), Wiki of the article, Username of who added it and Date added (formatted).
  • Article title links may be cross-wiki (see T423632).
  • Pagination controls are present and replicate the pagination approach used by the Contributions tab.
  • When the worklist is empty, the table shows an empty-state message.
  • The Actions column is NOT present in this task — it is added in T423732.
  • The data loading mechanism should follow the same pattern as the Contributions tab.
Design
Messages and copy included
  • For happy path:
    • Message key: campaignevents-worklist-table-header
      • Message text: "Worklist"
      • Context: column header for the article title
    • Message key: campaignevents-worklist-table-article-column-header
      • Message text: "Page"
      • Context: column header for the article title in the worklist table
    • Message key: campaignevents-worklist-table-wiki-column-header
      • Message text: "Wiki"
      • Context: column header for the wiki of the article
    • Message key: campaignevents-worklist-table-date-column-header
      • Message text: "Added by"
      • Context: column header for the username of who added the article
    • Message key: campaignevents-worklist-table-username-column-header
      • Message text: "Date added"
      • Context: column header for the date added
    • Message key: campaignevents-worklist-empty-state
      • Message text: "No articles have been added to this worklist yet."
      • Context: empty state message shown when the worklist has no articles
  • For unhappy path: NOT NEEDED
Depends on
  • T423332 (Worklist store: persistence layer )
  • T423612 (Worklist tab shell — the table renders inside it)
  • T423632 Cross wiki investigation
  • T423606 (Worklist feature flag gating must be implemented)
Testing required?
  • Yes
  • Minimum testing to pass QA:
    • With feature flag ON: table renders articles with correct titles/dates; links are correct cross-wiki URLs; pagination works; empty state shows when needed.
    • With feature flag OFF: covered by T423612 (Worklist tab is not shown).
    • No JS errors on page load.
  • Tested end-to-end in: task-9 (this task) and task-11 (which adds the delete column to this table)
Split patches suggestion
  • Branch 1: Empty state + i18n
  • Branch 2: Table + pagination + cross-wiki links + i18n
Gherkin scenarios
NOTE: This are all drafts and we will refine them

Feature: Article list table in Worklist tab

  • Scenario: Table shows articles with title and date
    • Given the Worklist feature flag is enabled
    • And an event has articles in its worklist
    • And I am viewing the Worklist tab on the EventDetails page
    • Then I see a table with an "Article" column and a "Date added" column
    • And each row shows the article title and the date it was added
  • Scenario: Article titles are clickable cross-wiki links (see T423632)
    • Given the Worklist feature flag is enabled
    • And an event has articles from multiple wikis in its worklist
    • And I am viewing the Worklist tab on the EventDetails page
    • Then each article title in the table is a clickable hyperlink
    • And the link points to the article on its correct wiki (cross-wiki URL see T423632)
  • Scenario: Pagination controls work correctly
    • Given the Worklist feature flag is enabled
    • And an event has more articles in its worklist than fit on one page
    • And I am viewing the Worklist tab on the EventDetails page
    • Then I see pagination controls below the table
    • When I click the next page control
    • Then the next page of articles is displayed
  • Scenario: Empty state is shown when worklist has no articles
    • Given the Worklist feature flag is enabled
    • And an event has no articles in its worklist
    • And I am viewing the Worklist tab on the EventDetails page
    • Then I see the empty state message instead of a table

Details

Event Timeline

cmelo updated the task description. (Show Details)

Change #1293588 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add worklist articles table

https://gerrit.wikimedia.org/r/1293588

Notes from June 1 team meeting:

  • Message text has been updated in AC
  • People should be able to see worklist even if they are logged out because the worklist can help people decide if they want to join an event. Maybe in the future we will allow editors to hide the worklist for certain cases, but this is not required for the MVP. This is also the same behavior that we have for the Contributions tab.

Maybe in the future we will allow editors to hide the worklist for certain cases, but this is not required for the MVP.

We are storing worklists as wikipages, so this will never be possible.

(EDIT: or at least it won't be possible to hide the worklist itself. We might hide the fact that the event uses a specific worklist, but still...)

@Daimona, thanks for the clarification. From my understanding, at the Contributors Offsite, we talked about a way that we can allow privacy (at a worklist or article level) for personal worklists, correct?

@Daimona, thanks for the clarification. From my understanding, at the Contributors Offsite, we talked about a way that we can allow privacy (at a worklist or article level) for personal worklists, correct?

We did talk about it, but my understanding is that the conclusion of this conversation is that worklists themselves will always be public. What you can do if you want a private list is to create it via the ReadingLists extension (which could differentiate between "reading list" and "editing list"), and those will be private. However, that is a separate type/concept of list. It can be converted into a public worklist if users so wish, but it cannot be used as a worklist (e.g., associated to events).

@Daimona, yup, it would be a personal worklist, so not associated with an event. But, if we made it private via the ReadingLists extension, I assume we could still input whatever data/features we have in the public version (such as showing a quality score, suggested tasks, or the ability to mark progress as upcoming/in progress/done)? Anyway, I guess this is best discussed separately outside this ticket :)