@Afaque_Hussain, I think this is a pretty reasonable one. Basically, in some cases, it would be good to let users interact with some objects without having accounts. But we need to create some kind of record for these users so that we can show something like this:

Evan Priestley (e...y@phacility.com) added a comment:
derp derp derp

...instead of:

A Mysterious External User added a comment:
derp derp derp

This isn't too difficult, but it's a big pain to test right now. First, we should make it easier to test.

Make it Testable

We have a receive mail test form at /mail/receive/, but it can only be used to send mail to objects (like D123), not to arbitrary email addresses (like bugs@phabricator.com). We should make it more flexible:

• Change the label/form to indicate that email addresses are fine.
• Change the implementation in PhabricatorMetaMTAReceiveController to only do the loadReceiverObject() bit if the string is not an email address. If it is an address (you can just look for "@" in it), we can just use it unmodified.

You can test this by:

• Set metamta.maniphest.public-create-email to something like "bugs@phabricator.local".
• Use the test form to "send" an "email" to that address.
• It should create a new task in Maniphest.

When you have this working, send me a diff and we can do the next part.

Okay, so for the next steps we're basically going to do this:

• Create an object representing an "external account".
• Add Handle support for the external account objects so they can be loaded and displayed.
• When we get a task from a user who we don't know, we:
  • Look up an existing external account by that email address.
  • If we don't find it, we create a new record.
  • Then we set that account as the owner.

These external accounts will behave a lot like users in some ways, but be much simpler.

This has a lot of overlap with T1536, and with D4647 in particular. I think there's enough overlap that it's worthwhile to make them be the same object -- specifically, PhabricatorUserCredentials from D4647. But let's start simpler and build up to that.

Create PhabricatorExternalAccount

So I'd say the next step should be to define a PhabricatorExternalAccount class which extends PhabricatorUserDAO. It should have these fields:

• userPHID (nullable)
• phid (define a new PHID type for these objects, like XUSR)
• accountType (this will always be "email" for this use case)
• accountDomain (nullable, this will be "null" for this use case)
• accountSecret (nullable, this will be "null" for this use case)
• accountID (string, this will have the email address)
• displayName (string)

Create the class and a .sql patch to add the table.

Use PhabricatorExternalAccount

Once that works, we want to take the metamta.maniphest.default-public-author block in PhabricatorMetaMTAReceivedMail and basically replace it with:

$existing_account = id(new PhabricatorExternalAccount())->loadOneWhere(
  'accountType = %s AND accountDomain IS NULL and accountID = %s',
  'email',
  $the_email_address_the_message_came_from);

If there's no existing account, create a new one and save it. Then set the ExternalAccount PHID as the task creator. This might create some problems, so we might have to do some other work before we can do this, but I think it won't break too much stuff.

Add Handle support

Assuming the step above works, the task should get created but the "Author" should say "Unknown Object". Edit PhabricatorObjectHandleData to let it load the new types of objects. This should make "Author" say something more reasonable (e.g., the email address).

Add Email support

We also want to send email back to the user when the task is updated. This will probably require a few small changes.

Add email reply support

Finally, these users should get recognized on the email reply pathway too (not just the create pathway).

(Future) Hook into registration

After T1536, we can add a footer to emails we send to external accounts which allows them to register easily.

(Future) Offline or online reconciliation of grey users

If a user signs up, we should replace all the instances of their XUSR PHID with their real USER PHID. To facilitate this, maybe we should write an edge from the XUSR object to the other object.

{D5770}

How usable is this in practice with latest HEAD?

Any stuff to watch out?

Nothing should be broken but the UX probably won't be that much improved -- I think we still aren't recognizing grey users in some critical interfaces. I haven't actually run through all the new stuff from a UX perspective, though.

Okay, thanks. I guess i'll try and enable it and see how it goes. Thanks for the work on this so far! :)

And you too @Afaque_Hussain :)

what about using the + sign for sub addressing certain applications or even objects. we have seen other systems (would not like to advertise here) using that.

Specially when fetching from IMAP/POP folders an email address like diffs+project@phabail.com will arrive in the same mailbox but can be interpreted by the receiver.

Are these features mentioned above implemented now in Maniphest?

• Handle support
• Email support
• Email reply support

In other words, can non-registered users (ExternalUsers?) create tasks, receive updates, and comment via email?

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella.

That is, the future for these use cases mostly looks like "lightweight/external users interact with Nuance, then staff triage issues into other objects like Tasks that only real users interact with", not "lightweight/external users interact with every application and every application gains support for email/external/grey interactions".