mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-26 16:52:41 +01:00
No description
a6fd8f0479
Summary: See PHI1134. Previously, see T13082 and D19969 for some sort-of-related stuff. Currently, edits work roughly like this: - Suppose we're editing object X, and we're also going to edit some other object, Y, because X mentioned Y or the edit is making X a child or parent of Y, or unblocking Y. - Do the actual edit to X, including inverse edits ("alice mentioned Y on X.", "alice added a child revision: X", etc) which apply to Y. - Run Herald rules on X. - Publish the edit to X. The "inverse edits" currently do this whole process inline, in a sub-editor. So the flow expands like this: - Begin editing X. - Update properties on X. - Begin inverse-edge editing Y. - Update properties on Y. - Run (actually, skip) Herald rules on Y. - Publish edits to Y. - Run Herald rules on X. - Publish edits to X. Notably, the "Y" stuff publishes before the "X" Herald rules run. This creates potential problems: - Herald rules may change the name or visibility policy of "X", but we'll publish mail about it via the edits to Y before those edits apply. This is a problem only in theory, we don't ship any upstream rules like this today. - Herald rules may "Require Secure Mail", but we won't know that at the time we're building mail about the indirect change to "Y". This is a problem in practice. Instead, switch to this new flow, where we stop the sub-editors before they publish, then publish everything at the very end once all the edits are complete: - Begin editing X. - Update properties on X. - Begin inverse-edge editing Y. - Update properties on Y. - Skip Herald on Y. - Run Herald rules on X. - Publish X. - Publish all child-editors of X. - Publish Y. Test Plan: - Created "Must Encrypt" Herald rules for Tasks and Revisions. - Edited object "A", an object which the rules applied to directly, and set object "B" (a different object which the rules did not hit) as its parent/child and/or unblocked it. - In `bin/mail list-outbound`, saw: - Mail about object "A" all flagged as "Must Encrypt". - Normal mail from object B not flagged "Must Encrypt". - Mail from object B about changing relationships to object A flagged as "Must Encrypt". Reviewers: amckinley Reviewed By: amckinley Differential Revision: https://secure.phabricator.com/D20283 |
||
|---|---|---|
| bin | ||
| conf | ||
| externals | ||
| resources | ||
| scripts | ||
| src | ||
| support | ||
| webroot | ||
| .arcconfig | ||
| .arclint | ||
| .arcunit | ||
| .editorconfig | ||
| .gitignore | ||
| LICENSE | ||
| NOTICE | ||
| README.md | ||
Phabricator is a collection of web applications which help software companies build better software.
Phabricator includes applications for:
- reviewing and auditing source code;
- hosting and browsing repositories;
- tracking bugs;
- managing projects;
- conversing with team members;
- assembling a party to venture forth;
- writing stuff down and reading it later;
- hiding stuff from coworkers; and
- also some other things.
You can learn more about the project (and find links to documentation and resources) at Phabricator.org
Phabricator is developed and maintained by Phacility.
SUPPORT RESOURCES
For resources on filing bugs, requesting features, reporting security issues, and getting other kinds of support, see Support Resources.
NO PULL REQUESTS!
We do not accept pull requests through GitHub. If you would like to contribute code, please read our Contributor's Guide.
LICENSE
Phabricator is released under the Apache 2.0 license except as otherwise noted.