❌ 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

In T368423#11380266, @aude wrote:

For the overall wish from the community for improved pagination on the special pages, we are now not sure that a Pagination vue component would be what we need.

We might just need HTML elements with codex styles.

https://meta.wikimedia.org/wiki/Community_Wishlist/W186

We could try and do something similar to what was done for HTMLForm "displayFormat" and support the current navigation output and a "codex" looking one? Would that make sense?

Thank you @CCiufo-WMF. I wanted to make sure there weren't any known blockers or dependencies before this could be picked on.

@CCiufo-WMF We are considering this work as part of our next wishathon. Is there a particular reason why this was moved to the backlog? Is the proposed designs by @bmartinezcalvo good to go as is? Any help on how to move this forward is greatly appreciated. Thanks.

@GMikesell-WMF TIL The category is not showing because there is a preference to show/hide hidden categories. Preferences > Appearance > Advance Options > Show hidden categories.

❓ AC1: Confirm that an error message is displayed indicating that the type field is missing or invalid.

Double quotes are indicating empty. I think it's fine considering that this is only on preview mode

Acceptance criteria might be in conflicts with T406670: Automatically add a support vote on behalf of a wish proposer depending on how we solve it. I'll bring it up in other channels.

When a wish is created, make a request to action=wishlistvote on behalf of the user. Leave the comment blank – they'll be able to change it later if they want to.

To be clear, the comment can only be changed by editing the /Votes page or after the status is changed to one that allows voting.

Pretty sure this is related to T406669: Vote count isn't changed to zero when all votes are removed. All of the wishes I tried had already been voted on and the Votes pages exists.

I'm gonna give a shot at this but I'm not sure how to approach it. We count votes when we render them, so if there are not calls to the parser function the count is just ignored and thus this issue. I think we need special handling for votes pages on onLinksUpdateComplete perhaps? Open to ideas

In T406674#11264111, @Samwilson wrote:

The statuses are stored in configuration and have unique numerical IDs. This means "Accepted" will have to come last in the config

I might be missing something here. Can't we just store them out of numerical order, and they'll display in the order we want? (See the above patch.)

In T406194#11244514, @Samwilson wrote:

Do we? User signatures, mentions, etc. don't get updated when users are renamed — wouldn't this be similar? It would be nice if things stayed in sync, but it doesn't really feel like the usual way it's done (sort of annoyingly, but also it does make things simpler).

Anyway sorry if I'm quite off track here, but some of this does feel like unneeded complexity.

For now if the focus area is not found we will be displaying "Unassigned". I've updated T406059 description to include nullifying cr_focus_area when focus areas entities are deleted.

In T404748#11231484, @GMikesell-WMF wrote:

@dmaza Please review Focus and the new error that came up, thanks!
❌ New Error when Page language is Hebrew and Table language is Hebrew. The Title is no longer a link. If you want me to create a separate task, please let me know or if here is fine.

In T402834#11229696, @GMikesell-WMF wrote:

@dmaza Please review AC1, thanks!

In T404748#11226990, @GMikesell-WMF wrote:

@dmaza Can you please review AC2? Thanks!

yeah I see it. That's not supposed to happen. I'll take a look.

Yes, that's the latest revision as of today.

In T402834#11194099, @MusikAnimal wrote:

If we need to ship without the filters UI, my suggestion is to just manually create a Community Wishlist/Wishes/Declined page with {{#CommuntiyRequests:wish-index|status=declined}}, and we can hard-code the default wish-index to not show declined unless it's added as a filter.

In T404748#11186460, @MusikAnimal wrote:

Not a blocker to deployment, but this should be fixed.

The problem: By the time we get to CommunityRequestsHooks::RevisionDataUpdates – which is where we change the page language to the user's language – the parser output is already cached. Ideally we'd set the page language earlier in the process, which is what we tried to do originally but I couldn't get it to work.

So, we can just go the cheap route here. After an entity is saved in the LinksUpdateComplete hook handler, we can call WikiPage::updateParserCache() on that page (and/or WikiPage::doPurge() if that's also necessary). It may be that this requires a refresh, which maybe we can't do from the hook handlers, but at least then any subsequent visit to the entity page will have the correct parser output.

Odd, I think this might be related to beta being slow + a caching issue. If you edit, but wait around 10 seconds before reloading, then the message does not show after a refresh. I still can't reproduce it locally. I'm gonna change priority to low and move this to the backlog. We can revisit once deployed to meta and then see if it is still happening

I found T305240 & https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/982781

@GMikesell-WMF I can't reproduce this, I tried in Firefox and Chrome. Can you verify that this is still valid?