Page MenuHomePhabricator

Add volunteer-facing filters to wishlist
Closed, ResolvedPublic

Assigned To
None
Authored By
HMonroy
Jul 14 2025, 10:42 PM
Referenced Files
F66753256: 2025-10-15_13-51-37.png
Oct 15 2025, 10:36 PM
F66751005: 2025-10-14_16-34-47.mp4
Oct 14 2025, 11:46 PM
F66751017: 2025-10-14_16-32-05.mp4
Oct 14 2025, 11:46 PM
F66750992: 2025-10-14_16-26-26.mp4
Oct 14 2025, 11:46 PM
F66750988: 2025-10-14_16-22-49.mp4
Oct 14 2025, 11:46 PM
F66750986: 2025-10-14_16-21-19.mp4
Oct 14 2025, 11:46 PM
F66750959: 2025-10-14_16-01-11.mp4
Oct 14 2025, 11:46 PM
F66750945: 2025-10-14_15-55-31.mp4
Oct 14 2025, 11:46 PM

Description

Figma: https://www.figma.com/design/JcTMFwbEJPpCKBiZ16Jkel/Future-of-the-Wishlist?node-id=4308-55426&t=3pXUH3SV66nNSsxM-4

User story:

A user should be able to filter wishes

Acceptance criteria:

Volunteers should be able to filter by:

  • Tag
  • Status
  • Focus Area

Users should be able to copy a link to the wishlist with filters applied, and send that link to someone, who opens to the same view

QA details:

Testing can be done for all filters through this task, as it is the parent of all filter tasks.

Subtasks:

  • introduce API changes to query for wishes for filtering
  • add form fields that groups filter (accordion) an call API on update with multiselects
  • add PHP interface to parse interface messages for stewards and components

(shouldn't be a subtask of this task):

  • add tags column to table
  • change title to include the focus area

Derived Requirement

Implement volunteer-facing filters on the Community Wishlist page that allow users to narrow down visible wishes by Tag, Status, and Focus Area.
The system should support multi-select filters, dynamically update the wishlist table when filters are applied, and allow users to share filtered views via URL links (preserving selected filters).

When a user opens a shared link containing filters, the same filter view should automatically be applied on load.

Additionally, ensure the filter form fields are grouped logically (accordion style), the API supports filtered wish queries, and the PHP interface properly parses localized interface messages for filter components.

Test Steps

Test Case 1: Verify filter by Tag

  1. Navigate to the Community Wishlist page.
  2. Expand the filter accordion and select a specific Tag (e.g., “UX Improvement”).
  3. ✅❓❌⬜ AC1: Confirm that the displayed wishes are filtered to show only those tagged with the selected tag.

Test Case 2: Verify filter by Status

  1. Open the filter accordion and select a Status (e.g., “In Progress”).
  2. ✅❓❌⬜ AC2: Confirm that only wishes with the selected status appear in the table.

Test Case 3: Verify filter by Focus Area

  1. Open the filter accordion and select a Focus Area (e.g., “Accessibility”).
  2. ✅❓❌⬜ AC3: Confirm that only wishes within the selected Focus Area are displayed.

Test Case 4: Verify multi-select filter functionality

  1. Apply multiple filters (e.g., Tag = “UI”, Status = “Open”, Focus Area = “Performance”).
  2. ✅❓❌⬜ AC4: Confirm that only wishes matching all selected criteria appear in the list.

Test Case 5: Verify filter persistence via shared URL

  1. After applying filters, copy the URL from the browser address bar.
  2. Open the same URL in a new browser tab or share it with another user.
  3. ✅❓❌⬜ AC5: Confirm that the same filters are pre-applied and the same filtered results are displayed on load.

Test Case 6: Verify removal of filters restores full wish list

  1. Clear all applied filters using the “Reset” or “Clear Filters” option.
  2. ✅❓❌⬜ AC6: Confirm that the full, unfiltered list of wishes is displayed again.

Test Case 7: Verify UI grouping (accordion structure)

  1. Observe the filter interface on the page.
  2. ✅❓❌⬜ AC7: Confirm that the filter categories (Tag, Status, Focus Area) are grouped in an accordion layout that can expand or collapse.

Test Case 8: Verify API call behavior

  1. Open the browser developer tools and monitor the network requests when filters are applied.
  2. ✅❓❌⬜ AC8: Confirm that the API call includes the selected filter parameters and returns filtered results.

Test Case 9: Verify translation and interface message handling

  1. Switch the interface language (e.g., to French or Hebrew).
  2. ✅❓❌⬜ AC9: Confirm that all filter labels and category names are properly localized based on the selected language.

Test Case 10: Regression check – verify wishlist table updates without full page reload

  1. Apply or remove a filter.
  2. ✅❓❌⬜ AC10: Confirm that only the wishlist content updates dynamically without reloading the entire page.

QA Results - Meta Beta

Event Timeline

HMonroy renamed this task from Add filters to Wish table to Add filters to wishlist.Jul 14 2025, 10:46 PM
HMonroy updated the task description. (Show Details)
JWheeler-WMF renamed this task from Add filters to wishlist to Add volunteer-facing filters to wishlist.Aug 7 2025, 9:21 PM
JWheeler-WMF updated the task description. (Show Details)

It seems like it'd be useful to filter for wishes with no tags. Has that been discussed?

Not that I'm aware of. I'm fond of the idea but not sure how the design would look in the filters accordion.

Ah sure, yeah you're right it would need a 'no tags' checkbox or something next to the tag multiselect. Not worth it for now! I'll remove the empty-array part of the API search.

Note that we accidentally broke filters on focus area detail pages with r1195788. This is fixed as part of T406719. We'll need to cherry-pick r1195821 into wmf.23.

@HMonroy Please review issues below.

Test Result - Beta|Prod

Status: ✅ PASS / ❓Need More Info / ❌ FAIL
Environment: Meta Beta
OS: macOS Tahoe 26.0
Browser: Chrome 141
Device: MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

Test Case 1: Verify filter by Tag

  1. Navigate to the Community Wishlist page.
  2. Expand the filter accordion and select a specific Tag (e.g., “Admin and patrollers”).
  3. AC1: Confirm that the displayed wishes are filtered to show only those tagged with the selected tag.

Test Case 2: Verify filter by Status

  1. Open the filter accordion and select a Status (e.g., “In Progress”).
  2. AC2: Confirm that only wishes with the selected status appear in the table.

Test Case 3: Verify filter by Focus Area

  1. Open the filter accordion and select a Focus Area (e.g., “Accessibility”).
  2. AC3: Confirm that only wishes within the selected Focus Area are displayed.

Focus area disappears in the Title and focus area column

Test Case 4: Verify multi-select filter functionality

  1. Apply multiple filters (e.g., Tag = “Admins and patrollers”, Status = “In progress”, Focus Area = “Bread”).
  2. AC4: Confirm that only wishes matching all selected criteria appear in the list.

Test Case 5: Verify filter persistence via shared URL

  1. After applying filters, copy the URL from the browser address bar.
  2. Open the same URL in a new browser tab or share it with another user.
  3. AC5: Confirm that the same filters are pre-applied and the same filtered results are displayed on load.

URL did not change

Test Case 6: Verify removal of filters restores full wish list

  1. Clear all applied filters using the “Reset” or “Clear Filters” option.
  2. AC6: Confirm that the full, unfiltered list of wishes is displayed again.

Test Case 7: Verify UI grouping (accordion structure)

  1. Observe the filter interface on the page.
  2. AC7: Confirm that the filter categories (Tag, Status, Focus Area) are grouped in an accordion layout that can expand or collapse.

Test Case 8: Verify API call behavior

  1. Open the browser developer tools and monitor the network requests when filters are applied.
  2. AC8: Confirm that the API call includes the selected filter parameters and returns filtered results.

Test Case 9: Verify translation and interface message handling

  1. Switch the interface language (e.g., Hebrew).
  2. AC9: Confirm that all filter labels and category names are properly localized based on the selected language.

So what exactly was supposed to be translated since I did not see anything

Test Case 10: Regression check – verify wishlist table updates without full page reload

  1. Apply or remove a filter.
  2. AC10: Confirm that only the wishlist content updates dynamically without reloading the entire page.

Is it supposed to update dynamically or only when you click Update

GMikesell-WMF changed the task status from Open to In Progress.Oct 14 2025, 11:48 PM
GMikesell-WMF updated Other Assignee, added: GMikesell-WMF.
GMikesell-WMF updated the task description. (Show Details)
GMikesell-WMF updated the task description. (Show Details)
GMikesell-WMF moved this task from QA to In Development on the Community-Tech (Sea Lion Squad) board.


Test Case 3: Verify filter by Focus Area

  1. Open the filter accordion and select a Focus Area (e.g., “Accessibility”).
  2. AC3: Confirm that only wishes within the selected Focus Area are displayed.

Focus area disappears in the Title and focus area column

That is expected, since they all have the same focus area. If you filter for >1 focus area, then the FA text will show again.

The column is supposed to say just "Title" and not "Title and focus area", however. That will be fixed once the patch for T406719: Tags should be links is merged.

Test Case 5: Verify filter persistence via shared URL

  1. After applying filters, copy the URL from the browser address bar.
  2. Open the same URL in a new browser tab or share it with another user.
  3. AC5: Confirm that the same filters are pre-applied and the same filtered results are displayed on load.

URL did not change

That is T406719, which is a subtask of this task. Sorry for the confusion. I sent this to QA because I felt we should get some eyes on the filters feature before it goes live tomorrow.

Test Case 9: Verify translation and interface message handling

  1. Switch the interface language (e.g., Hebrew).
  2. AC9: Confirm that all filter labels and category names are properly localized based on the selected language.

So what exactly was supposed to be translated since I did not see anything

I think there is a legit bug here. We'll look into it.

Test Case 10: Regression check – verify wishlist table updates without full page reload

  1. Apply or remove a filter.
  2. AC10: Confirm that only the wishlist content updates dynamically without reloading the entire page.

Is it supposed to update dynamically or only when you click Update

Only when you click "Update" or "Clear all".


I'm leaving this here for now. AC9 needs to be looked into.

Thanks for the quick QA, George!

HMonroy changed the status of subtask T406719: Tags should be links from In Progress to Open.Oct 15 2025, 1:06 AM

Test Case 9: Verify translation and interface message handling
Switch the interface language (e.g., to French or Hebrew).
✅❓❌⬜ AC9: Confirm that all filter labels and category names are properly localized based on the selected language.

We're currently showing these in the page language, rather than the interface language. I've opened T407349 to fix it up.

I think the rest of this task can be called resolved, is that right?

HMonroy changed the task status from In Progress to Open.Oct 15 2025, 7:39 PM
HMonroy moved this task from In Development to QA on the Community-Tech (Sea Lion Squad) board.

@MusikAnimal @Samwilson Since AC5 and AC9 will be addressed in separate tasks, and AC3 and AC10 are as designed, I will mark this as Resolved. Thanks for all your work!


Test Case 3: Verify filter by Focus Area

  1. Open the filter accordion and select a Focus Area (e.g., “Accessibility”).
  2. AC3: Confirm that only wishes within the selected Focus Area are displayed.

Focus area disappears in the Title and focus area column

That is expected, since they all have the same focus area. If you filter for >1 focus area, then the FA text will show again.

AC3: Confirm that only wishes within the selected Focus Area are displayed.

2025-10-15_13-51-37.png (1×911 px, 188 KB)

The column is supposed to say just "Title" and not "Title and focus area", however. That will be fixed once the patch for T406719: Tags should be links is merged.

Test Case 5: Verify filter persistence via shared URL

  1. After applying filters, copy the URL from the browser address bar.
  2. Open the same URL in a new browser tab or share it with another user.
  3. AC5: Confirm that the same filters are pre-applied and the same filtered results are displayed on load.

URL did not change

That is T406719, which is a subtask of this task. Sorry for the confusion. I sent this to QA because I felt we should get some eyes on the filters feature before it goes live tomorrow.

⬜ AC5: Confirm that the same filters are pre-applied and the same filtered results are displayed on load.
Will be taken care of in T406719

Test Case 9: Verify translation and interface message handling

  1. Switch the interface language (e.g., Hebrew).
  2. AC9: Confirm that all filter labels and category names are properly localized based on the selected language.

So what exactly was supposed to be translated since I did not see anything

I think there is a legit bug here. We'll look into it.

AC9: Confirm that all filter labels and category names are properly localized based on the selected language.
Will be taken care of in T399514#11276338

Test Case 10: Regression check – verify wishlist table updates without full page reload

  1. Apply or remove a filter.
  2. AC10: Confirm that only the wishlist content updates dynamically without reloading the entire page.

Is it supposed to update dynamically or only when you click Update

Only when you click "Update" or "Clear all".


I'm leaving this here for now. AC9 needs to be looked into.

Thanks for the quick QA, George!

AC10: Confirm that only the wishlist content updates dynamically without reloading the entire page.
As seen in

GMikesell-WMF updated Other Assignee, removed: GMikesell-WMF.
GMikesell-WMF updated the task description. (Show Details)