Details
- Tried to create an empty service via "almanac.service.edit", was told to pick a type.
- Tried to pick a bad type, was told to pick a good type.
- Created a new Almanac service via "almanac.service.edit".
- Tried to edit the service to change the type, wasn't allowed to.
- Created and edited via the web UI, nothing changed from before.
Diff Detail
- Repository
- rP Phabricator
- Branch
- almanac4
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 20047 Build 27187: Run Core Tests Build 27186: arc lint + arc unit
Event Timeline
| src/applications/almanac/editor/AlmanacServiceEditEngine.php | ||
|---|---|---|
| 46–52 | Do we care about validating that someone doesn't pass in two type transactions that disagree with each other? I'm not too bothered about this "last type transaction wins" implementation, but I wanted to make sure it was intentional. | |
| src/applications/almanac/xaction/AlmanacServiceNameTransaction.php | ||
| 19 | Ugh, I saw this in the other diff and thought it looked wrong... | |
| src/applications/almanac/editor/AlmanacServiceEditEngine.php | ||
|---|---|---|
| 46–52 | We allow multiple edits of the same type as long as they're each individually valid, and then combine them before applying them, and remove them if they have no effect. This ends up sort of weird for edits like "set title to X" + "set title to Y" since the "set title to X" transaction completely vanishes, but for edits like "Add subscriber A" + "Add subscriber B" or "Add comment X" + "Add comment Y" the behavior is more sensible, and then I think it's good that we apply the same rule to "set title to..." that we apply to other transactions. | |