Ref T9964.
- Add a "paths" attachment for fetching paths.
- Always load owners. We will need this to do policy checks in the future, anyway, and this data is not large, is very useful, and is reasonable to load unconditionally.
Details
Details
- Reviewers
chad - Maniphest Tasks
- T9964: Fill in Conduit support infrastructure for ApplicationEditor changes
- Commits
- Restricted Diffusion Commit
rP10cdc55cf70b: Give "owners.search" a "paths" attachment and a default "owners" value
- Queried packages via API.
- Edited packages (paths, owners).
- Created a package.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Branch
- attach4
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 9548 Build 11407: Run Core Tests Build 11406: arc lint + arc unit
Event Timeline
| src/applications/paste/engineextension/PhabricatorPasteContentSearchEngineAttachment.php | ||
|---|---|---|
| 20 | not related? | |
| src/applications/paste/engineextension/PhabricatorPasteContentSearchEngineAttachment.php | ||
|---|---|---|
| 20 | Sort of, this is adjusting a thing I added in the previous diff, and it's vaaaaaguely related because it's making it consistent with what I did here. Originally I called the content data, because having two nested content keys seemed a little weird, but then when I got to owners I decided it was fine and better than having every attachment have a generic data key so this is just "I'm going to use descriptive keys instead of generic ones, even if that sometimes means you access result.data[3].attachments.paths.paths[3] in callers, since callers need to be managing that complexity in a reasonable way anyway and this is probably more clear in the long run, and that's not really worse than result.data[3].attachments.paths.data[3]". | |