In T402834#11275037, @Samwilson wrote:

That's not super elegant is it! Because we're treating 'not declined' as being just 'everything else'? I don't see how else to do it without introducing some sort of filter negation, which is going to get trickier.

Does the proposed solution in the task sound feasible? I am only envisioning things in my head, but I think it could work without too much hassle.

And does that happen when linking to the index page via a tag? Because if so, perhaps if we're linking to a tag it makes sense to list all, including declined.

Good point! I can see why that might be desirable behaviour, but I imagine it's better for the behaviour to be consistent, be it to always hide unless requested, or the inverse.

We could do without the config changes too if we wanted. So instead of the parser function taking a showexcluded parameter, it'd take a hidestatuses parameter. That's maybe cleaner but still means every parser function invocation needs to add declined and whatever else to get the behaviour they see at the Wishlist.

Or maybe showexcluded didn't make sense in the first place… yeah, there's no need for that I guess. hidestatuses makes sense, but I still think it'd be nice to have the exclusions done internally by default.

The issue here is that we don't want to show all the statuses in the filter box isn't it? I mean, there's no other reason for defining excluded statuses.

Perhaps we could solve it in the way that Phabricator does, with an "Any open status" quasi-status, which is basically what adding excluded: true to the config would do. I think that makes sense.

That's maybe cleaner but still means every parser function invocation needs to add declined and whatever else to get the behaviour they see at the Wishlist.

There are only three places, I think: the homepage, /Wishes, and /Archive. If we change statuses then we're probably going to be updating a bunch of other places too, so I don't think that's too terrible.

I'd imagine more often than not, users would want to filter by one or two tags of interest, but they must first click "Clear all".

Maybe I'm misunderstanding: if they open the form and all the statuses are prefilled, and they want to look at tags, why do they need to clear anything?

All up I'd say this isn't a high priority.

In T407309#11275325, @Samwilson wrote:

The issue here is that we don't want to show all the statuses in the filter box isn't it? I mean, there's no other reason for defining excluded statuses.

Yes. The current state of affairs is clunky and unintuitive (in my opinion). I do certainly agree it's not high priority, though!

Perhaps we could solve it in the way that Phabricator does, with an "Any open status" quasi-status, which is basically what adding excluded: true to the config would do. I think that makes sense.

How would that work in the UI? Or are you talking about a parser function parameter?

That's maybe cleaner but still means every parser function invocation needs to add declined and whatever else to get the behaviour they see at the Wishlist.

There are only three places, I think: the homepage, /Wishes, and /Archive. If we change statuses then we're probably going to be updating a bunch of other places too, so I don't think that's too terrible.

No it's not terrible, it's the principle that bothers me. Ideally {{#CommunityRequests:wish-index}} will by itself do the job of the "default" view. Even focus area detail pages have this problem; we just haven't fixed it there since we don't foresee ever having declined wishes assigned to a FA.

I kind of see it as akin to say {{Special:RecentChanges}}, where we hide bot edits by default.

Note also the parser function can be used outside Wishlist pages, too.

I'd imagine more often than not, users would want to filter by one or two tags of interest, but they must first click "Clear all".

Maybe I'm misunderstanding: if they open the form and all the statuses are prefilled, and they want to look at tags, why do they need to clear anything?

Bah, I think I confused tags and statuses! I've removed that from the description.

After getting some rest, I realize now there's a much simpler solution. We could add the excluded option in $wgCommunityRequestsStatuses as described, and effectively simulate what we're doing now of passing in statuses= that are not excluded. That should be pretty simple to implement.

Change #1201179 had a related patch set uploaded (by Dmaza; author: Dmaza):

[mediawiki/extensions/CommunityRequests@master] Add flag to status config to be excluded from queries and filters

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

Change #1201179 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@master] Add flag to status config to be excluded from queries and filters

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

@dmaza Please review AC2/AC4, thanks!

Test Result - Meta Beta

Status: ✅ PASS/ ❌ FAIL
Environment: Meta Beta
OS: macOS Tahoe 26.1
Browser: Chrome 142
Device: MBA
Emulated Device: NA

Test Artifact(s):

https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/Wishes?statuses=Declined

Test Steps

Test Case 1: Ensure Declined Wishes Are Hidden by Default

1. Navigate to the Community Wishlist wish-index page.
2. Observe the list of wishes displayed.
3. ✅ AC1: Confirm that wishes with the status 'Declined' are not shown in the wish-index by default.

}

Test Case 2: Ensure Declined Wishes Can Be Viewed When Explicitly Requested

1. Navigate to the wish-index parser function with statuses='Declined' in the URL.
2. Observe the list of wishes displayed.

3.❌ AC2: Confirm that only wishes with the status 'Declined' are shown.

Wishes did not show up when I entered:
https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/Wishes?statuses=Declined

Test Case 3: Ensure Filters UI Does Not Include 'Declined'

1. Open the wish-index filters panel.
2. Check the list of selectable statuses.
3. ✅ AC3: Confirm that 'Declined' is not present as an option in the filters UI.

Test Case 4: Validate Link to Declined Wishes Page

1. Navigate to https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes/Declined
2. Verify the page content.
3. ❌ AC4: Confirm that users can view all declined wishes via the Meta page.

Wishes that got changed to decline did not show up via URL

@GMikesell-WMF

❌ AC2: Confirm that only wishes with the status 'Declined' are shown.

"Declined" should be lowercase, all statuses values are lowercase. If you go to https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/Wishes?statuses=declined it works just fine

❌ AC4: Confirm that users can view all declined wishes via the Meta page.

This is a wiki page and we need to call the parser function just like we do in the index page but specifying the status=declined param. This is a non-issue

I think this is working as intended, let me know if you have any questions

In T407309#11429052, @dmaza wrote:

@GMikesell-WMF

❌ AC2: Confirm that only wishes with the status 'Declined' are shown.

"Declined" should be lowercase, all statuses values are lowercase. If you go to https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/Wishes?statuses=declined it works just fine

❓ @dmaza Where should "Declined" be lowercase since the only time I see it lowercase is in "Edit", as seen in the video? Even clicking on the URL doesn't show any lowercase.

❌ AC4: Confirm that users can view all declined wishes via the Meta page.

This is a wiki page and we need to call the parser function just like we do in the index page but specifying the status=declined param. This is a non-issue

I think this is working as intended, let me know if you have any questions

✅ Ok sounds good to me, thanks!

❓ @dmaza Where should "Declined" be lowercase since the only time I see it lowercase is in "Edit", as seen in the video? Even clicking on the URL doesn't show any lowercase.

Yes, that’s correct. "Declined" should only appear lowercase in "Edit" (wikitext) or in the URL when filtering. The uppercase term you see in the UI is not the actual status value; it's a translation. This difference becomes clearer when you use another language. For instance, if we switch to Spanish, the URL still includes "declined," but in the UI, you'll see "Rechazado," which is the Spanish translation. You will see it in the table and in the form with the exception of wikitext which is not translated. Does that make sense?

https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/Wishes?statuses=declined&uselang=es

In T407309#11444171, @dmaza wrote:

❓ @dmaza Where should "Declined" be lowercase since the only time I see it lowercase is in "Edit", as seen in the video? Even clicking on the URL doesn't show any lowercase.

Yes, that’s correct. "Declined" should only appear lowercase in "Edit" (wikitext) or in the URL when filtering. The uppercase term you see in the UI is not the actual status value; it's a translation. This difference becomes clearer when you use another language. For instance, if we switch to Spanish, the URL still includes "declined," but in the UI, you'll see "Rechazado," which is the Spanish translation. You will see it in the table and in the form with the exception of wikitext which is not translated. Does that make sense?

https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/Wishes?statuses=declined&uselang=es

Got it, I see now as seen in the video below. I will now mark this as Resolved. Thanks for all your work!