- Called the API method from conduit and browsed lease queries from the UI.
- Used the new "ownerPHIDs" constraint via API console.
This isn't a Datasource because owners are a weird mishmash of different object types, I assume? Seems OK to me to let users search by owner, but I think pretty much anything can own a lease right now?
What's your use case for reading attributes? I'm not sure we should dump them verbatim -- they may conceivably contain internal data or keys, and I think their structure is somewhat in flux, and they're probably not the most-preferred format for consumption. If possible, clients probably shouldn't be relying on raw attributes.
If this is for completeness, maybe omit it?
If this is for a particular purpose, maybe we can find a better way to expose the data that's more client-consumable?
Yeah, initially I had this as a user facing typeahead that accepted people as it's datasource, was thinking of combining build steps and people into one datasource, but then you would have to be able to search build steps by name, etc etc.
Internally we display like, what version of the workspace you have checked out from the CLI when you're looking at your leases, or the hostname of the machine if you have a machine lease.
We can just implement it as a search attachment when reintegrating with upstream, probably would tend to agree with you more that it needs some work before being exposed over the API.