Page MenuHomePhabricator

Allow grey users in some form or other
Closed, DuplicatePublic


Particularly for Maniphest, we should allow installs to permit non-users to interact with tasks over email. This is a request from @davidreuss and an obvious good for onboarding/penetration.

The trouble comes when those users eventually sign up for accounts. But it would probably be reasonable to do this:

  • Introduce a new user-app object called "ExternalUser" or similar, which has a PHID and some external identifier (like an email address).
  • Add Handle support.
  • Auto-create them for unknown inbound email.
  • When they eventually sign up, weakly associate the ExternalUser to the real user (e.g., when a user confirms an email tied to an ExternalUser, we know it's them) if/when we can.
  • Add a script like "reconcile_external.php" which goes through app-by-app and replaces "PHID-XUSR-..." PHIDs with "PHID-USER-..." PHIDs for external users who are now associated with real users. Administrators can run this periodically if they care. It's probably perfectly fine to leave these users unreconciled in most cases -- not a big deal if a 3-month-old comment says it's from "" vs "epriestley".

So this probably isn't actually that hard, since we can just do all the hard stuff offline and add zero logic for it at runtime.

Revisions and Commits

rP Phabricator
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@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 ( 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 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',

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.

epriestley edited this Maniphest Task.
epriestley edited this Maniphest Task.

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 will arrive in the same mailbox but can be interpreted by the receiver.

btrahan edited this Maniphest Task.
btrahan edited this Maniphest Task.

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?

epriestley closed subtask Restricted Maniphest Task as Resolved.Jul 10 2014, 5:18 PM
Unknown Object (User) moved this task from Important to Potential blockers on the Wikimedia board.Oct 9 2014, 8:48 AM
AMonk changed the visibility from "All Users" to "Public (No Login Required)".Apr 11 2015, 8:16 PM
eadler added a project: Restricted Project.Jan 8 2016, 10:27 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jan 8 2016, 10:41 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 4 2016, 9:06 PM

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