Page MenuHomePhabricator

Phabricator should let you interact with external (non-Phabricator) users via email
Closed, ResolvedPublic

Description

Existing task upstream: https://secure.phabricator.com/T1205

Outside users need to be able to email directly into individual tickets for replies.

Example of the workflow we need to replicate: 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.

The outside users must be able to send attachments, that would be stored in the task.

Details

Reference
fl97

Event Timeline

flimport raised the priority of this task from to High.
flimport set Reference to fl97.

qgil wrote on 2014-04-15 05:44:38 (UTC)

In T55#10, RobH also says: "I need to be able to email OUT of a ticket to a non-phab user/vendor sales team."

I'm not sure Phabricator can offer this granularity within a task, where sometimes you can include an email address in the notification, and sometimes you don't. Maybe an option is to create a subtask where only the team members are CCed, not the vendors?

Just saying. I don't know enough about RT workflows.

Rush wrote on 2014-04-22 15:20:16 (UTC)

So to woodshed this a little bit...

If you have a guy from dell who can be added as a normal fab subscriber in a procurement project that is hidden from all eyes except ops, or even some ops, and that dell guy gets new comments / updates as an email that can be responded to via email -- which are in turn added to the ticket -- does that satisfy?

it's really close if so, if not totally doable now. If otoh there needs to be like an email button that sends a template that needs hide fab from said vendor I haven't seen anything like that. But allowing external users who we want to get into our workflow as (limited?) fab subscribers seems pretty easy.

qgil wrote on 2014-04-22 22:01:11 (UTC)

I have created a meta-task upstream.

T4868: The case of the Security project

It includes the use case of non-registered users creating tasks and commenting via email.

qgil wrote on 2014-04-23 03:54:26 (UTC)

I wonder what is the difference between an email address that you know in advance and a user. I mean, if you are expecting procurement emails sent from abc@delllll.com, can't you just create a user account for this email address?

Or are there cases where you would expect someone to create a task without knowing their email address in advanced?

faidon wrote on 2014-04-25 01:23:01 (UTC)

My personal opinion (I'm sure opinions between opsens will differ!) is that communicating with vendors via email is a bit of too much to as from a task-tracking software. RT and Phabricator both track "tickets", but the the nature of those tickets is very different: Phabricator is a task/project management software, while RT began as basically a fancier, more managed system to handle emails in a team. We currently use RT for both our internal task tracking and our e.g. vendor needs but while it can handle the latter better than Phabricator, it's horrible for the former use case (as an example: there's no clear priority/severity field).

I don't think we can reach feature parity in this sense or that we should strive for it. I think that our vendor procurement needs can probably be covered by either using our mailboxes, perhaps with a new alias for the purpose, and uploading PDF quotes or excerpts of our conversations. Worst case, we can even keep an RT instance alive just for this.

I do think that in the long run it'd be nice for Phabricator to gain some kind of Helpdesk/email-desk application that can deal with this use case and also handle mail aliases such as noc@, abuse@, security@ etc. (or even non-tech needs, such as legal's contracts@, trademark violations and such), but this is daydreaming and in my opinion it should be out of scope for this migration.

qgil wrote on 2014-04-25 05:27:47 (UTC)

I was looking for another thing, and I found a task about "grey users" filed upstream with some activity: https://secure.phabricator.com/T1205

In any case, it would be useful to know whether this task is considered by Ops relevant for the RfC or not.

RobH wrote on 2014-04-25 13:31:08 (UTC)

adding the various vendors as users doesn't really work.

We use RT for our contract sends, order sends, etc. We don't want those vendors subscribed or have an actual login or user in any way. They should only get the emails we specifically one-time CC them to receive.

Keeping RT alive for procurement but nothing else is horrible, sorry. If this is a lacking feature that cannot be fixed, I'd personally say not to switch.

RobH wrote on 2014-04-25 14:16:04 (UTC)

Updating this ticket from our IRC discussion involving this:

Chase is going to look more into Phab settings and capabilities. Sometime next week he and I will do an in depth review of the workflow and requirements for the procurement queue and see if it can be integrated, or if that process should split from the rest of the RT processes and not included in the Phab migration.

further notes: vendors never email in and create tickets, they only email in to existing ones. we could change our workflow to email the vendor and set reply to include the phab # in question. the vendor emails are often known in advance, but not always. vendors cannot read their own tickets, only what we one time cc to them, and they can send back in.

qgil wrote on 2014-05-01 14:46:12 (UTC)

See also my questions upstream at T1205: Allow grey users in some form or other.

Rush wrote on 2014-05-01 15:01:22 (UTC)

@Qgil

...in the interest of not doubling up effort I think this exchange could be useful :)

13:31 chasemp: gents and ladies, I'm hoping someone can confirm an inbound email capability. 
 Slightly confused based on: https://secure.phabricator.com/book/phabricator/article/configuring_inbound_email/.  
Essentially, I am hoping that I can email phabricator, get a new ticket back, 
and then -- with that subject line and phabricator receive email cc'd -- send an email to a vendor for quotes, they would reply-all it would update the t
13:31 chasemp: icket.
13:31 chasemp: I'm unsure if an external vendor person would need a prior account in phab?
13:32 chasemp: or if I can do this and the subject line will route to the response to the appropriate ticket even if this person could not login to phabricator and see it
13:32 chasemp: or possibly I'm way off on all counts
13:39 epriestley: chasemp: currently, only about half of that will work. The relevant task in the upstream is...
13:40 epriestley: T1205
13:40 phabot: T1205: Allow grey users in some form or other - https://secure.phabricator.com/T1205
13:41 epriestley: The parts that work are: creating a ticket via email, and updating it by CC'ing it on stuff (it routes based on a unique address like "Txxx@phabricator", not the subject line), 
although we might parse email too aggressively to be great for the case where you're sort of just including a ticket in a primarily-email-based thread.
13:42 chasemp: so all senders have to be emails phabricator recognizes is the hold-up? to summarize for me anyway
13:42 epriestley: Until T1205, non-account-holders have limited/nonexistent ability to update tasks, though.
13:42 epriestley: Yeah. We have some support for external email addresses creating "grey" accounts, but it doesn't all work yet.
13:42 chasemp: matching sender email to email in phabricator I mean
13:42 chasemp: k
13:43 epriestley: (It's planned, and support has been moving forward slowly, but it's not at the top of the priority queue.)
13:43 chasemp: I understand
13:44 chasemp: if I were to make a limited dummy account (my words) in phabricator for external people, I could do all of this though?
13:48 epriestley: chasemp: it may have some rough edges, but I think it should mostly work. If you run into trouble with it, let us know.
13:48 chasemp: ok thank you for the help

Rush wrote on 2014-05-01 15:02:17 (UTC)

that being said I have a loose plan for solving this in the interrum for ops procurement that I need to speak with Robh about, and I am pretty sure that use case can be handled currently with a bit of our own stuff

qgil wrote on 2014-05-01 16:36:50 (UTC)

Thank you! Note that I posted that question upstream one hour before you updated this task here. :) I'm very happy to see you took the lead.

I will move this task to "Not critical for the RfC" because the requirements are clear, and this is clear blocker for RT migration, although not for the rest.

aklapper wrote on 2014-07-02 15:22:42 (UTC)

In T97#26, @Rush wrote:

that being said I have a loose plan for solving this in the interrum for ops procurement that I need to speak with Robh about, and I am pretty sure that use case can be handled currently with a bit of our own stuff

@Rush: Did you find time to talk to RobH? Or any thoughts that are already worth to share here?

Rush wrote on 2014-07-02 15:24:13 (UTC)

I did talk with Robh, and it comes down to what we will able to actually do...which comes down to configuring exim....which is probably going to happen late this week? or next week. tbd

aklapper wrote on 2014-08-20 16:27:08 (UTC)

For the records, @Rush spent some time with Mark discussing how to handle the usecases of RT.

Rush wrote on 2014-09-07 13:56:00 (UTC)

this should be done

https://gerrit.wikimedia.org/r/#/c/158426/

importing issue status

flimport closed this task as Resolved.Sep 12 2014, 1:24 AM
Qgil reopened this task as Open.Sep 17 2014, 7:50 PM
Qgil added a subscriber: Qgil.

We need to test this feature here.

Qgil added a comment.Sep 19 2014, 11:19 AM

This looks like a rt-migration blocker, more than a production instance blocker.

This is done enough to be compatible with a general deployment. In truth the RT features should all be present, but I'll leave the minutia of that for RT.

chasemp closed this task as Resolved.Oct 2 2014, 10:57 PM

closing any further work can be in other tickets

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 23 2016, 6:07 PM