Details
- Reviewers
epriestley - Maniphest Tasks
- T6262: Create a new Phriction document via Conduit interface
T4029: Support policies on Phriction wiki articles - Commits
- Restricted Diffusion Commit
rP6db25aa41c9d: Phriction - add "create" conduit endpoint
made a document via conduit and it worked!
Diff Detail
- Repository
- rP Phabricator
- Branch
- T4029p2
- Lint
Lint Passed Severity Location Code Message Advice src/applications/phriction/conduit/PhrictionCreateConduitAPIMethod.php:64 XHP16 TODO Comment Advice src/applications/phriction/conduit/PhrictionEditConduitAPIMethod.php:65 XHP16 TODO Comment - Unit
Tests Passed - Build Status
Buildable 2986 Build 2990: [Placeholder Plan] Wait for 30 Seconds
Event Timeline
I'm not sure how valuable this is before T5873, but I don't think it costs us much either. Your call either way.
Offhand, I imagine we'll probably end up with full-power endpoints (say, app.xcreate, app.xupdate) which take a list of transactions to apply (and, in the case of xupdate, an ID to update) and get full access to every possible transaction. And then maybe we'll have easy endpoints (say app.create, app.update, app.comment) which take a small list of things like "title", "content", etc., and build the transactions for you.
However, I'm not sure how valuable the easy endpoints really are, or if we need them. If we do, maybe we can get away with a few shared ones (like anything.comment which takes a PHID to comment on) and not have per-app create/update easy ones. So it's possible that after T5873 we might want to deprecate this kind of endpoint and just provide fully transaction-aware endpoints (which can presumably be very simple). Not a big deal regardless, and I don't have strong feelings about either choice being preferable.