aklapper wrote on 2014-04-09 14:54:20 (UTC)

#2: Emailing interface exists ("You can also create tasks by sending an email to: bugs@phabricator.com") but not sure about passing a project/queue via email. (Related: See T60 for passing a project/queue via URL parameter.)

RobH wrote on 2014-04-10 13:20:35 (UTC)

I do the following workflow for our procurement, I'd need to be able to accomplish the following:

• All procurement tickets would automatically be private, and only accessible to WMF Employees and those who have signed an NDA for this purpose.
• I need to be able to email OUT of a ticket to a non-phab user/vendor sales team.
• Outside vendors need to be able to email directly into individual tickets for replies.
• Example: I email my Dell rep in RT, he can reply back to the RT#@rt.wikimedia.org, and it goes directly into said ticket without entering any other queues where it may not be private.
• Must be able to attach a history of file attachments, as we get in multiple quotes for review, and then send back signed purchase orders via the same ticketing system.

This lets me have a full quoting, approval, and purchase history for each system.

RobH wrote on 2014-04-10 13:23:34 (UTC)

Also, Edit is appending, not editing. If I click edit entry, and it instead appends instead of editing in line. That is stupid and misleading.

RobH wrote on 2014-04-10 13:26:09 (UTC)

There must be some kind of categorization or flag for differing types and access levels.

Example: Procurement tag/category/queue, Security, access requests (which are very restricted), etc...

dzahn wrote on 2014-04-10 13:27:21 (UTC)

please also see: https://www.mediawiki.org/wiki/Talk:Project_management_tools/Review#Must_be_able_to_do_14

dzahn wrote on 2014-04-10 13:29:45 (UTC)

Is there an equivalent to the "Activity Tab"? That's a place where i see all recent edits to all tickets, which tells me what others have been working on.

RobH wrote on 2014-04-10 13:30:31 (UTC)

I also need to be able to subscribe to all tickets of a given category to email me notification. So any procurement ticket would generate an email to the 'procurement admins', or any other example of a queue/project/tag/whatever generate emails to user(s) specific to said queue/project/tag/whatever

Rush wrote on 2014-04-10 16:13:58 (UTC)

Daniel,

There a few views for things. Tickets and differentials.

There is this:

http://fab.wmflabs.org/audit/view/audits/

There is also a way to view under a user their activity including your own.

Rob,

I think the closest thing to a category, for which you are thinking is a 'project'. At first this was unintuitive for me. At my last place in Phabricator we did not use 'go make lunch' style things as projects, it was instead an 'ops' project and an 'ops-backog'. This would map projects pretty much to the 'queue' types in RT I believe. For which you can get an email regarding status changes being a part of a project (comments, diffs, etc). So a project for ops (general) maybe, and then ops-procurement and ops-requests, etc.

Rush wrote on 2014-04-10 16:18:31 (UTC)

Daniel,

Not sure if you have seen it but this may be the closest thing to what you are thinking:

http://fab.wmflabs.org/feed/

qgil wrote on 2014-04-10 18:08:52 (UTC)

A tactical move could be to park the discussion about RT in Phabricator until the Bugzilla/Trello/Mingle plans are clear.

If we don't migrate from Bugzilla/Trello/Mingle to Phabricator, then the RT migration will not happen either. If we solve the B/T/M combo, then we may have paved the road for some of the RT requirements as well. At that point we can check what is still missing, and whether any tradeoff can be made.

RobH wrote on 2014-04-10 20:32:41 (UTC)

I think delaying this discussion is simply asking for Ops to singularly not move. As you have the two most prevalent supporters of RT/workflow in this discussion at present, putting it on hold would not be ideal (imo ;)

RobH wrote on 2014-04-10 20:36:46 (UTC)

I should rephrase (too bad edit is really just clone post for reposting ;)

"I think delaying this discussion is simply asking for Ops to singularly not move."

Rephrase:

Delaying this discussion could very easily lead to the same situation we have now. BZ could possibly have been made to work for Operations ticketing as well as deveopment; however, its historical processes, workflows, and access levels made it unworkable for operations. Having operations involved at this discussion at the early stages can help to ensure that the deployment and workflows put in place for Phabricator can match both the needs of the developers and operation staff use.

I think that sounds far less confrontational than I meant my initial quoted statement to mean. Hope that explains.

faidon wrote on 2014-04-14 11:24:16 (UTC)

I agree with RobH here (especially with his more verbose answer). We, as the operations team, would like to jump on this ship and be first-class citizens here not only for our benefit, but for the benefit of everyone else in this organization that interacts with us. I'd be willing to bet that more people in the organization interact with RT than Trello (or perhaps even Mingle), so I see no reason to single RT out here. I'd be also willing to bet that for most people, interacting with RT is a frustrating experience and one that hinders cooperation between both Ops/Dev and staff/community and creates artificial walls that wouldn't exist otherwise. I believe RT should be made a priority of this whole project (and by the way, so should other operations team's needs, such as our Git workflows).

dzahn wrote on 2014-04-14 14:10:07 (UTC)

we created a ticket in RT to find out ways to import tickets into phabricator

https://rt.wikimedia.org/Ticket/Display.html?id=7264

Ariel started looking around and found this:

Mon Apr 14 10:39:41 2014 Ariel T. Glenn - Correspondence added [Reply] [Comment][Forward]
Download (untitled) / with headers
text/html 827b
On Mon Apr 14 05:52:59 2014, dzahn wrote:
Hide quoted text

we want to find out which options we have to import all RT tickets into
phabricator (per queue, with different permissions)

A hunt around for importtools of any kind for tasks/issues came up short. There's the 'create issues via email' approach, but there's also a (poorly documented and asserted to be veery unstable) api called Conduit which could be used to script something, see https://github.com/facebook/phabricator/blob/master/src/docs/tech/conduit.diviner

There are python bindings here: https://github.com/disqus/python-phabricator

A tiny example of task creation via the python bindings is here: https://github.com/getsentry/sentry-phabricator/blob/master/sentry_phabricator/plugin.py

dzahn wrote on 2014-04-14 14:13:23 (UTC)

testing cross linking, from RT to phabricator i could use the custom field "third party ticket" we already have. from phabricator to RT it's a wiki style link with URL and label so far. RT #7264

aklapper wrote on 2014-04-14 15:48:02 (UTC)

@RobH: "Edit is appending, not editing. If I click edit entry, and it instead appends instead of editing in line. That is stupid and misleading." is now T89

qgil wrote on 2014-04-14 17:07:33 (UTC)

The Ops team is a first-class citizen in this plan, and I'm sorry if my poor choice of words or my "tactical" proposal suggested anything different. I also would like to see RT migrating to Phabricator before Day 1.

The list of features listed by RobH deserves subtasks for each, so we can analyze better which ones exist, which ones kind of exist or are almost there, and which ones are totally missing.

dzahn wrote on 2014-04-14 18:30:34 (UTC)

the most important thing is that we can get them all imported and have separate permissions for them. if we get that done i see good chances

RobH wrote on 2014-04-14 18:43:29 (UTC)

I think that Rush's comment makes sense. So if projects can have fine grained access controls, and we NEVER give admin for viewing various projects to anyone who couldn't be allowed to read ALL private and purchasing data, as well as all security issues and user issues (see how bugzilla suddenly wouldn't have worked in the past ;) then it sounds like this may work. To the point, I am optimistic.

qgil wrote on 2014-04-15 05:08:13 (UTC)

I have created a Secret Ops test project, adding RobH, dzahn, faidon, aklapper, and guillom. I have set the most restrictive access, where only the members of the project can join/add members, edit, and view tasks. Then I removed myself.

The first test is privacy. I cannot see the project listed at http://fab.wmflabs.org/project/query/Y39_.q9qHsZy/#R because I'm not a member of the team. Good. :)

I have also created the "Ops team" and "Ops -- Shell access" projects to start playing with cascading permissions. The idea is that you can control de members of "Ops team" and then limit the permissions of another project or a task to "Open team". It seems to work.

There are scenarios that are still unclear to me e.g. how can a registered user create a task for a "secret"project she is not member of, and whether non-member users can be CCed to "secret" tasks e.g. when someone requests shell access. I will open tasks to discuss these scenarios in detail.

dzahn wrote on 2014-04-18 11:56:02 (UTC)

I created a new task within the secret project. http://fab.wmflabs.org/T157

Ariel, who is not listed as a member above, reportedly can still see the ticket anyways.

that seems to be issue T95

aklapper wrote on 2014-04-18 12:30:48 (UTC)

"Unfortunately" I'm admin according to http://fab.wmflabs.org/p/aklapper/ (I'd love to know if this comes into play) but when I go to http://fab.wmflabs.org/maniphest/task/edit/157/ I see "Visible to: Public" and "Editable by: All users". Might be T95, yeah.

qgil wrote on 2014-04-22 21:55:32 (UTC)

I have created a meta-task upstream to flesh out the different use cases for secret projects and tasks.

T4868: The case of the Security project

qgil wrote on 2014-05-01 15:31:04 (UTC)

The unfulfilled needs of RT users are being discussed in T95 and T97. If you find more missing features, please create them as subtasks. Resolving here.

importing issue status

In T30#474, @flimport wrote:

qgil wrote on 2014-05-01 15:31:04 (UTC)

The unfulfilled needs of RT users are being discussed in T95 and T97. If you find more missing features, please create them as subtasks. Resolving here.

These links "T95, T97" seem to be to unrelated things, not RT related. I suppose that is because they are imported tickets and means "the task that used to be T95 before it was imported from the other installation".

That would be now:

The unfulfilled needs of RT users are being discussed in T50: Restricting access to tasks based on project membership and T52: Phabricator should let you interact with external (non-Phabricator) users via email. If you find more missing features, please create them as subtasks. Resolving here.

In the meantime, the RT migration got its own project: https://phabricator.wikimedia.org/tag/rt-migration/board/