| • JWheeler-WMF | |
| Apr 23 2024, 9:00 PM |
| F56798269: image.png | |
| Jul 30 2024, 11:15 PM |
| F56798116: 2024-07-30_15-57-03.png | |
| Jul 30 2024, 11:15 PM |
| F56799648: 2024-07-30_16-12-19.png | |
| Jul 30 2024, 11:15 PM |
As a user viewing a focus area, I should see, but not be able to edit:
As a user viewing a focus area, I should be able to
| AC | Status | Details |
|---|---|---|
| 1 | ❓ | T363235#10030247 |
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| Fix focus area index location, to Template:Community_Wishlist/Wishes/ | repos/commtech/wishlist-intake!176 | samwilson | index-prefix | main | |
| Hide 'area' or 'status' column of index tables | repos/commtech/wishlist-intake!175 | samwilson | hide-table-cols | main | |
| Add focus area template, dummy data, basic Lua module | repos/commtech/wishlist-intake!59 | musikanimal | more-mediawiki-pages | main |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T370069 Ship Focus Area MVP | |||
| Resolved | Samwilson | T363235 Focus area pages: reader experience | |||
| Resolved | Samwilson | T369697 Don't show focus area column in the wish table on focus pages |
musikanimal opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/59
Draft: Add focus area template, dummy data, basic Lua module
samtar merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/59
Add focus area template, dummy data, basic Lua module
"support a wish" is a separate task FYI (T363231).
I've done some of the template editing for Focus Areas. There's still more to do, including bot automation. Unlicking for now.
For this we'll not want to show the 'Focus area' column in the wishes table on Focus areas' pages, and similarly for T369554 we're going to not show the 'Status' column, so in the collab session today @tstarling and I were talking about switching from having a single {{Community Wishlist/Wishes}} template using {{Community Wishlist/Wishes/Row}} to a set of these templates for each type of the (now four) wish tables. So we'd have something like:
And at some point we'll add focus area tables, in the same vein:
How does this sound?
samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/175
Hide 'area' or 'status' column of index tables
musikanimal merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/175
Hide 'area' or 'status' column of index tables
samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/176
Fix focus area index location, to Template:Community_Wishlist/Wishes/
samtar merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/176
Fix focus area index location, to Template:Community_Wishlist/Wishes/
I think everything here is now covered, other than voting, which is tracked in T363231, and the requirement to not be able to edit. I suggest that protecting pages be left until we know there's an issue — that's the usual approach on Meta, rather that locking things down beforehand.
Also, the template arrangement I described in a comment above isn't how it's ended up. We've stuck with the easier system of having the two optional columns handled conditionally within the single Row template.
@JSengupta-WMF did you want to take a look at this instead since voting hasn't been implemented, some stuff is missing, and I am still able to edit as seen in the screenshots.
Status: ❓NMI
Environment: Wishlist-test.toolforge
OS: macOS Sonoma 14.5
Browser: Chrome 127
Device: MBA
Emulated Device: NA
Test Artifact(s):
 |  |  |
Editing shouldn't be possible for any of the staff created pages. But I guess this is one of the limitation of building the pages in wiki?
We can protect them if need be, but what is the reasoning for not having them be able to be edited? They're wiki pages after all, and usually people can edit anything unless it's a problem if they do. People will come and fix typos and copyedit and generally improve things.
@JSengupta-WMF Did you want them protected or able to edit them per response from T363235#10037581
As per @Samwilson's rationale, we don't need to protect the page for the time being. If we see the page is being vandalized, can take this call later.