See PHI933. This issue requests a new "Current Viewer" template policy which transforms into a concrete PHID-USER-xyz policy when saved.

Then you can configure the form or application with "Editable By: Current Viewer" or "Editable By: Custom: Current Viewer and Administrators". When users actually create objects, these policies will save as "epriestley" or "epriestley and administrators" respectively.

This is tricky because there's no willSavePolicy(...) sort of hook today, and a lot of older code still dumps the policy value directly from the request into the object. Although there's theoretically an opportunity to add a guard rail in ApplicationTransactionEditor, this may not be exhaustive.

Both the standalone phantom policy ("Current Viewer") and custom policies which embed a phantom policy ("Current Viewer and Administrators") must be converted on save.

This is ultimately "safe" because we can fail the policy unconditionally during evaluation, but mistakes will let users lock themselves out of objects.

This interacts to some degree with policy pre-checks in the Editor. We need to convert phantom policies before we check for policy validity ("You can't set that policy because you'd be unable to edit the object.").

Also somewhat tricky is that we may need to do writes as a side effect to make the de-templated phantom policy concrete and give it a PHID, but may never actually use the policy if it isn't valid. This is probably fine but could get weird in some weird future edge case. That is:

• User saves form with "Custom Policy: Current Viewer and Administrators".
• We want to transform that policy into a concrete custom policy.
• We build a new "epriestley and administrators" custom policy.
• We have to save this new custom policy object to the database to get a PHID.
• We replace the editPolicy with the new PHID.
• Then, perhaps we reject the edit because the new policy is invalid. We've done a write as a side effect that we can't clean up.

Probably not a real concern.