Page MenuHomePhabricator

Migrate Tools access request process to Phabricator
Closed, DeclinedPublic

Description

Quim demonstrated recently that Phabricator allows different bug forms for different use cases. If feasible, this would present a good opportunity to fold the Tools access request process with its wikiness and SMW and hard-to-metric-ness and own queue into "standard" Phabricator.

For efficiency, we would probably need some extension that displays the link to the "Add user to Tools project" form at wikitech prefilled with the wikitech username. Another possibility would be a extension that allows to change user group memberships in Phabricator itself, but that'd be a lot of work so only useful if useful for other projects as well.


Version: unspecified
Severity: enhancement

Details

Reference
bz70625

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:46 AM
bzimport added a project: Toolforge.
bzimport set Reference to bz70625.
scfc created this task.Sep 9 2014, 8:15 PM
coren added a comment.Sep 9 2014, 8:31 PM

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

coren moved this task from Triage to Backlog on the Toolforge board.Nov 25 2014, 4:08 PM
yuvipanda closed this task as Declined.Nov 25 2014, 7:42 PM
yuvipanda added a subscriber: yuvipanda.

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

Restricted Application added a project: Cloud-Services. · View Herald TranscriptJan 14 2016, 11:04 AM

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?

yuvipanda reopened this task as Open.Jan 14 2016, 10:00 PM

Given that horizon is a bit far away on the... horizon, and phabricator forms now exists, reopening.

Aklapper removed coren as the assignee of this task.Jan 14 2016, 10:04 PM
Aklapper added a project: Project-Admins.
Aklapper set Security to None.
yuvipanda raised the priority of this task from Low to Needs Triage.Jan 14 2016, 10:10 PM
Luke081515 triaged this task as Normal priority.Feb 12 2016, 7:31 PM

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...

scfc added a subscriber: bd808.Feb 5 2017, 7:52 PM

@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.)

bd808 added a comment.Feb 5 2017, 10:17 PM

@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.

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 :)

Dzahn removed a subscriber: Dzahn.Feb 6 2017, 10:41 PM
scfc added a comment.Feb 17 2017, 4:41 PM

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? :-)

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.

Qgil removed a subscriber: Qgil.Feb 20 2017, 2:53 PM
bd808 added a comment.May 2 2017, 10:54 PM

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.

bd808 closed this task as Declined.May 8 2017, 11:13 PM

T162508: Implement Tool Labs membership application and processing in Striker is deployed now. Lets try that out for a while. If it turns out to be awkward we can revisit this workflow idea as a replacement.