Allow "almanac.service.edit" to create services
ClosedPublic
Actions

Authored by epriestley on Apr 9 2018, 9:20 PM.

Details

Reviewers

amckinley

Maniphest Tasks

Commits

Summary

Depends on D19317. Ref T13120. Ref T12414. See PHI145. See PHI473.

This adds a Conduit-only "type" transaction for Almanac services. This is very similar to the approach in D18849 for Drydock blueprints.

Test Plan

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.

Repository

rP Phabricator

Lint

Lint Not Applicable

Unit

Tests Not Applicable

epriestley requested review of this revision.Apr 9 2018, 9:21 PM

amckinley added inline comments.

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

This revision is now accepted and ready to land.Apr 9 2018, 11:32 PM

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.