Ref T3404. The only mildly sketchy bit is these codepaths all load the application email directly, by-passing privacy. I think this is necessary because not getting to see an application doesn't mean you should be able to break the application by registering a colliding email address.
Details
Details
- Reviewers
epriestley - Maniphest Tasks
- Restricted Maniphest Task
- Commits
- Restricted Diffusion Commit
rP7d309a8e46ca: Application Emails - make various user email editing paths respect…
Tried to add a registered application email to a user account via the web ui and got a pretty error.
Ran unit tests.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
See one inline, but when a Query class exists, I think it's preferable to bypass by using the omnipotent user over a raw loadOne call. In this case it doesn't matter too much, but in the case of more complex objects it makes sure they get loaded with all the right attached objects (and it's possible we'll start attaching stuff to these some day, e.g. the Application objects would be maybe-reasonable to attach on load).
| src/applications/auth/controller/PhabricatorAuthRegisterController.php | ||
|---|---|---|
| 66 | "shoud" | |
| 69–70 | Prefer bypass with OmnipotentUser instead of a raw query? Then we pick up linked objects, etc., properly. | |