Page MenuHomePhabricator

Give "owners.search" a "paths" attachment and a default "owners" value
ClosedPublic

Authored by epriestley on Dec 14 2015, 2:25 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Mar 5, 3:22 AM
Unknown Object (File)
Tue, Mar 5, 3:22 AM
Unknown Object (File)
Jan 28 2024, 2:46 AM
Unknown Object (File)
Jan 12 2024, 8:22 AM
Unknown Object (File)
Dec 27 2023, 7:49 AM
Unknown Object (File)
Dec 23 2023, 8:21 PM
Unknown Object (File)
Dec 21 2023, 3:01 PM
Unknown Object (File)
Dec 7 2023, 5:28 PM
Subscribers
None

Details

Summary

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.
Test Plan
  • Queried packages via API.
  • Edited packages (paths, owners).
  • Created a package.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Give "owners.search" a "paths" attachment and a default "owners" value.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: chad.
chad edited edge metadata.
This revision is now accepted and ready to land.Dec 14 2015, 4:16 PM
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]".

This revision was automatically updated to reflect the committed changes.