On Meta, we'll also need to add community-wishlist-manager to $wgAddGroups and $wgRemoveGroups
The work here is small but should be done closer to deploy time.
On Meta, we'll also need to add community-wishlist-manager to $wgAddGroups and $wgRemoveGroups
The work here is small but should be done closer to deploy time.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| CommonSettings: Add CommunityRequests projects and group | operations/mediawiki-config | master | +151 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | MusikAnimal | T402967 Deploy CommunityRequests extension to prod | |||
| Resolved | HMonroy | T401268 Deploy CommunityRequests extension to beta | |||
| Invalid | None | T393860 Make any configuration changes needed prior to CommunityRequests deployment |
Should we handle permissions as part of this patch? See https://phabricator.wikimedia.org/T402599#11111360
Does this mean that the default config in the extension will be an empty list? Should we add a demo project for developers to use (e.g. just MediaWiki)? Maybe a single project that is the current wiki (although that'd take a bit more work I guess, to get the name and logo).
For add/remove groups, do we want syops to be able to do it, e.g.:
$wgAddGroups['sysop'][] = 'community-wishlist-manager'; $wgRemoveGroups['sysop'][] = 'community-wishlist-manager';
And perhaps also for staff to be able to add and remove other staff, e.g.:
$wgAddGroups['community-wishlist-manager'][] = 'community-wishlist-manager'; $wgRemoveGroups['community-wishlist-manager'][] = 'community-wishlist-manager';
Change #1184375 had a related patch set uploaded (by Samwilson; author: Samwilson):
[operations/mediawiki-config@master] CommonSettings: Add CommunityRequests projects and group
If r1182929 gets merged before we deploy, then we don't need to worry about the configuration relying on WikimediaMessages. Projects will be no more, to be replaced by tags.
But yes, had we stuck with projects, a valid demo config would make sense! The goal here was to remove the dependency on WikimediaMessages. (Related, I'm sorry that is was apparently drug you into debugging why the tests were failing locally for you!)
Hmm, maybe not? I'm not personally worried about misuse, but I don't think there's a need for the bureaucracy, either. The existence of a user group assignable by non-staff on Meta might invite requests at SRP#Miscellaneous requests or something. In reality there will only be a handful of us.
And perhaps also for staff to be able to add and remove other staff, e.g.:
$wgAddGroups['community-wishlist-manager'][] = 'community-wishlist-manager'; $wgRemoveGroups['community-wishlist-manager'][] = 'community-wishlist-manager';
Yes! That is quite sensible.
Ah, no more projects! Got it. (I'm still catching up!)
So it sounds like no actual config changes are required right now? If crats can already assign the new group, and no project config is going to be needed, what's left here?
Yes, sorry! I had almost revised this task, but I wasn't sure if r1182929 would land prior to deployment. At first we figured it was too drastic of a change, but as it happens, "projects" and "tags" work the same way! I think we should still try to get that in, because otherwise we'd need to have a second migration phase (migrateFromGadget.php would be phase I, and we'd need a new script for Phase II to convert projects to their corresponding tags).
If crats can already assign the new group, and no project config is going to be needed, what's left here?
Hmm maybe nothing, then! The need to amend $wgAddGroups / $wgRemoveGroups was from T402599. As my first time introducing new rights/groups, I concede to any ignorance :-P
The more I think about it, maybe only T&S should be assigning these rights (if it's not done by local 'crats or stewards). This is a community-maintained wiki, after all. If there is a need for staff to give someone else Community Wishlist manager, it would be for work, so it sounds like T&S should do it. Disregard!
I do like leaving room for volunteers to eventually be more involved. I imagine the pure existence of new user group will eventually evolve into something, be it just an info page, or one day a community-defined process to attain the rights! We'll just have to see :)
Per above I think there's actually nothing to do here. We will go through T&S to attain rights.
Change #1184375 abandoned by Samwilson:
[operations/mediawiki-config@master] CommonSettings: Add CommunityRequests projects and group