That seems to specific to be generally useful, but how about a "make a MW API call" extension?

In T72625#785419, @yuvipanda wrote:

Going to set this as declined. It'll move to Horizon when we move to Horizon from wikitech.

Given T123601#1933843 is this still declined?

So what is your proposal? A project (type component), where you can put all tasks in?

The proposal would be a form which creates a Maniphest task, which would require the same fields as the access request on wikitech. If we can require a linked LDAP account, that would be even more awesome.

We can create forms now...

@bd808: How does Striker play along with this? If someone signs up at https://toolsadmin.wikimedia.org/, where are users guided to for access to Toolforge at the moment? If users would have to enter a field "I want to use Toolforge for:" on Striker and account approval remains a manual task (which I favour to fence off obvious no-goodniks), how would the users be notified about the approved account (they might not be aware that they have an account on wikitech.wikimedia.org)? Could Striker create a Phabricator user, link that to the SUL wiki and file a task in Phabricator in the name of the user or with him as subscriber?

(I favour Phabricator for this because it means that users will be familiar with using Phabricator for reporting bugs & Co. later on, and administrators already know how to deal with tasks.)

In T72625#2999671, @scfc wrote:

@bd808: How does Striker play along with this? If someone signs up at https://toolsadmin.wikimedia.org/, where are users guided to for access to Toolforge at the moment?

Today, Striker uses a 'goal' prompt with a link to https://wikitech.wikimedia.org/wiki/Special:FormEdit/Tools_Access_Request. I would like to move creation of the Tool Labs project membership request to Striker. As I mentioned previously (see T128158) I think we should move to a model where we let people into Tool Labs and then kick them out if they turn out to be harmful. I'm not sure that we have the tooling we need yet to determine when abuse is happening and react quickly and efficiently, so I'm willing to keep the approval queue model for now.

If users would have to enter a field "I want to use Toolforge for:" on Striker and account approval remains a manual task (which I favour to fence off obvious no-goodniks), how would the users be notified about the approved account (they might not be aware that they have an account on wikitech.wikimedia.org)? Could Striker create a Phabricator user, link that to the SUL wiki and file a task in Phabricator in the name of the user or with him as subscriber?

(I favour Phabricator for this because it means that users will be familiar with using Phabricator for reporting bugs & Co. later on, and administrators already know how to deal with tasks.)

Striker does prompt users to create their own Phabricator account using either their LDAP credentials or their SUL account and then to come back to link that account with their LDAP identity and SUL account in Striker's local database. In order to complete automate Phabricator actions as user we would need configure our Phabricator instance to act as an OAuth identity provider and acquire an OAuth token instead of just making the name based API lookups that Striker does today.

There is another way that we could automate Phabricator task creation today. Striker (or any tool actually) could collect whatever data we want and on submission redirect via a task creation URL that would give the user a pre-populated task creation form that they would only need to hit the create new task button on. These tasks could easily be linked to a Manifest project that is used as the approval queue.

In T72625#2999816, @bd808 wrote:

There is another way that we could automate Phabricator task creation today. Striker (or any tool actually) could collect whatever data we want and on submission redirect via a task creation URL that would give the user a pre-populated task creation form that they would only need to hit the create new task button on. These tasks could easily be linked to a Manifest project that is used as the approval queue.

Exactly what v2c does :)

I haven't tested Striker yet because I would need a second SUL account for that (?), but I think one of the motivations of T128158 was to make signing up for Toolforge a one-stop-shopping experience. IMHO ideally requesting access would be part of that, so that there can't be a situation where the user completes the LDAP account creation, but then can't or does not want to fill in a wiki form or file a Phabricator task. Why can't complex problems not be easy to solve? :-)

In T72625#3036805, @scfc wrote:

I haven't tested Striker yet because I would need a second SUL account for that (?),

Making a SUL account is cheap, so please do test by making a throw away SUL account to test the workflow for creating a Tools account. I'm open to hearing arguments about why we should allow 1-to-N relations between SUL accounts and LDAP accounts rather than 1-to-1. In my analysis and design I couldn't come up with one (beyond easier testing workflows).

but I think one of the motivations of T128158 was to make signing up for Toolforge a one-stop-shopping experience. IMHO ideally requesting access would be part of that, so that there can't be a situation where the user completes the LDAP account creation, but then can't or does not want to fill in a wiki form or file a Phabricator task. Why can't complex problems not be easy to solve? :-)

My ideal solution as proposed in T128158#2128397 is "The waiting period for manual approval of joining the Tool Labs project is highly artificial. There is no good technical or procedural reason I can see for it to not simply be a matter of clicking a button or checkbox." This has not been implemented yet and that choice was largely due to your objection to removing moderation from the queue.

I think moving the process to Phabricator is much nicer than keeping it in Wikitech if we are going to have a moderation queue. I also understand the caution about making it too easy waste resources, so I am in favor of keeping moderation until we have a simple solution for revoking access and cleaning up after a rogue user.

Making a wizard in Striker that walks the user through getting their Phabricator account setup and then submitting a task requesting membership should be easy enough. At the end of the current LDAP account creation wizard we know that the user has both SUL and LDAP accounts so they can easily create a Phabricator account. Striker already has the ability to discover the Phabricator account name based on either.

We are missing an authorization component that would let Striker act as the actual user directly in Phab. There are two ways this can be handled today:

1. Use the task creation URL technique from T72625#2999816 where the user would have to make one more button click on the Phabricator side to submit the request
2. Use the conduit API to create a request as the @StrikerBot user and add the new user as a subscriber so that they get email/web notifications of state change

There is also the possibility of asking for Phabricator's OAuth server to be enabled and changing Striker to use that to get a grant to act as the user directly. The upstream docs on OAuth are incomplete and I haven't looked at the code to see how mature/secure it is. We could always make this change later too even if we chose one of the other two options to implement first.

The code needed for T162508: Implement Tool Labs membership application and processing in Striker has been implemented. The workflow can be tested on https://striker.wmflabs.org/ or in a local MediaWiki-Vagrant VM using the striker role.

It preserves most of the process that Tool Labs admin should be used to from wikitech, but it is a bit less tedious. There is a queue of requests (https://striker.wmflabs.org/tools/membership/) that is publicly viewable, but each request can only be edited by the requesting user and the admins. When a request is in the initial 'pending' state, an admin can approve or deny it. They can also add a note requesting more information and leave it in the pending state. When the request is approved, Striker will:

• add the user to the Tools project
• use its User:StrikerBot account to leave a message on the user's wikitech talk page using the normal subst template
• deliver an "alert" to the requesting user in Striker itself (similar to an Echo event)

When an application is approved, denied, or a new comment is added an alert will be left for the requesting user. New applications will also make alert events for all Tools admins. Admins can also 'suppress' a request if it includes information that should not be shown to the public for some reason. Suppressed requests are still visible to admins, but will no longer show up in the public list of requests.