When an account is created on Wikitech, that account gets a 'shell name' in addition to other account attributes. I'm pretty sure this happens via a hook in OpenStackManager; we need a way to create that fully-featured account in the post-OSM world.
|Open||None||T189531 All Wikimedia developer services should use single sign-on|
|Open||None||T161859 Make Wikitech an SUL wiki|
|Resolved||PRODUCTION ERROR||Tgr||T195253 Special:Notifications gives a consistent PHP exception on load ("The trash icon is not registered") for users with OpenStackManager notifications|
|Open||None||T106123 Extensions needing to be removed from Wikimedia wikis|
|Open||None||T161553 Remove OpenStackManager from Wikitech|
|Open||None||T196171 Developer account creation without OpenStackManager|
- Mentioned In
- T161859: Make Wikitech an SUL wiki
T237889: Install php-ldap on all MW appservers
T167973: Move database for wikitech (labswiki) to a main cluster section
T233236: Move labtestwikitech database to clouddb2001-dev
T229392: Cleanup wikitech registration page
- Mentioned Here
- T179463: Create a single application to provision and manage developer (LDAP) accounts
Yes, that solution is described in T179463: Create a single application to provision and manage developer (LDAP) accounts. Doing this would mean developing a new Django based application, getting it through security review, and getting it deployed followed by some amount of support for fixing bugs once it is rolled out. Not impossible at all, but not a trivial amount of work either. It is my preferred long term solution, but it would be nice to find a way to keep that from blocking the removal of MediaWiki-extensions-OpenStackManager from wikitech which is the main blocker to hosting wikitech in the main wiki cluster.
Yes, that would be possible. It would not be too difficult to make some mostly cosmetic changes to the workflow there as well to make that a bit less confusing. The most efficient thing to do by time and effort would be to combine the developer account and Toolforge use-cases into a single tool (Striker). In the longer term however that may be working counter to other goals (e.g. streamlining the Toolforge on-boarding process).
When I started planning Striker my intent was to hide as many of the "power user" use-cases as I could so that the experience of joining and using Toolforge was as simple and direct as possible. The assumption was that a typical new Tool maintainer does not care about VPS instances, Gerrit, or even Phabricator; they care about deploying a webservice or bot to help on their home wiki. I still generally believe this, so I'm hesitant to "temporarily" move in the other direction because I know that once the pressure is off we are less likely to build the better solution (T179463).
I'm not sure the the introduction of CAS service has done anything to change the world here. CAS is backed by the Developer account LDAP directory but only does authentication and does not provide any account creation system which is what this ticket is about.