The only thing that I can think of which might be disrupted is converting a task from public to restricted. Currently that is supported by editing the value of the security field on a task. Without the security extension that won't be an option for most users, only someone with enough privileges to edit task policies will be able to restrict access to a task. How much impact will that have on people's workflows? I don't know if it's common to change a task from public to private. Once a task is submitted as public then it's potentially indexed on public search engines so restricting it after the fact does not prevent it from being seen. To me that limits the value of restricting tasks after they are already made public.

This is a huge issue, and honestly this is a blocker in the short term.

Since it sounds like this is the direction your taking with Phabricator, we'll make it work. But it's going to take a fair amount of prep on my end to get ready for this. This is a very common workflow (I don't have the time to run a conduit query to count out how many issues have gone through this, but I can think of at least 3 recently), so changing this needs planning and communication.

Is there any way we can overlap the processes for a period of time, so users get used to pointing users to one form for creating normal issues, and another form for security issues? Will the security form be linked to from the normal form?

I think we'll need to give the right to escalate tasks into security bugs to a number of community members so we have multiple users able to perform this around the clock. Preferably, those users can't see tasks that are already security bugs. Is that possible?

Your feedback will be greatly appreciated. If there isn't any objection then I can proceed with deploying these changes next Wednesday during the scheduled deployment window.

^ This cannot happen. It's going to take a lot longer to get ready for this.

I think we'll need to give the right to escalate tasks into security bugs to a number of community members so we have multiple users able to perform this around the clock. Preferably, those users can't see tasks that are already security bugs. Is that possible?

Here's a possible approach:

• WMFExtensionsApplication.php
• WMFLockTaskEventListener.php
• WMFLockTaskController.php

Here's what it looks like in the UI;

Notes:

• The controller just changes the title rather than adjusting policies or custom fields, so that needs to be tweaked.
• Some of the other UI stuff can probably be better tailored for your use case, it's mostly just placeholder text.

(You may also need to fiddle with setIcon() vs setFontIcon() vs setIconFont() if you try to run that slightly behind HEAD -- everything is setIcon() at HEAD, but some UI elements had inconsistent APIs until ~48 hours ago.)

In T125104#1974536, @csteipp wrote:

Is there any way we can overlap the processes for a period of time, so users get used to pointing users to one form for creating normal issues, and another form for security issues?

Not really, upstream already removed the api we use after a short (~2 week) deprecation warning.

Will the security form be linked to from the normal form?

Yes, that's easy to do, each form can have arbitrary markup in the header above the form.

I think we'll need to give the right to escalate tasks into security bugs to a number of community members so we have multiple users able to perform this around the clock. Preferably, those users can't see tasks that are already security bugs. Is that possible?

I think we can give people the ability to edit policies without letting them see all security issues, however, anyone who can edit policies has a lot of power in their hands to restrict things that probably shouldn't be restricted (or vise-versa, however, they can only edit policy on objects they can edit)

That said, I may be able to implement some sort of escalate procedure that uses herald, to avoid the whole situation. I'm not entirely sure how that would work though. The way it works now is less than ideal. The dropdown is fairly cumbersome and the code is convoluted.

In T125104#1977436, @epriestley wrote:

Here's a possible approach:
...

Holy crap that was fast. @epriestley never ceases to amaze me.

I'm one of the very fastest Phabricator implementors in the whole world!

@epriestley: indeed, but you sell yourself short. I'd say you are one of the most prolific and generally helpful developers I've ever known. (in general, not just in phabricator)

UI changes would require someone (who?) to update at least the following documentation pages on mw.org related to managing Security reports (I have not checked other wiki sites):

• https://www.mediawiki.org/wiki/Security
• https://www.mediawiki.org/wiki/Reporting_security_bugs
• https://www.mediawiki.org/wiki/Phabricator/Security

Here's my attempt at writing the markup for the security escalation dialog box:

Discussion is in the diff: D113: Add a button to maniphest tasks to escalate security issues which need to be restricted.

@csteipp: Does the current version seem like a suitable solution? If so, please accept D113