(We also need solution A in some form for our use of Drydock, so if upstream doesn't have that, we'll end up patching an implementation of solution A on top of the new API anyway)

fyi solution (A) is implemented in the revisions I wrote that add custom attributes for blueprints. I'm guessing these will be reasonably straightforward to translate to the new API, since it's mostly just updating the filtering checks (lease attributes matching resource attributes and lease attributes matching blueprint attributes).

More broadly, we're now much of the way toward a functional v1 here but most of the interesting action has been attached to T9253 rather than directly to this task, and getting this operating in the upstream has depended on Phacility changes in T7399 (I don't want any live Phacility credentials to exist on the build hosts in any form, but do want to deploy them using common cluster tooling).

General plans here:

Yeah, I think it's very unlikely that we'll require hovering to reveal document hierarchy (or, eventually, parent projects) since two results called "Onboarding" (or, in the future, "Sprint 32") are completely indistinguishable right now. This use case feels much stronger to me as a material usability issue than snippeting.

Thanks for adding me to this issue! Please don't rely on mouseovers/hovering. I want to be able to just look at the results and see which ones are relevant without having to move my mouse.

Yeah, that makes sense. I think this is straightforward and won't create a big ball of mess or anything, so I'll see if I can slip it in somewhere.

just a heads up that I'm not actively working on this any more (have to finish other things before my contract ends.)
Last time this was discussed, @vishal proposed tweaking our current APC settings.

D14097 reverts this because it felt really bad in production, and generally not very promising as a direction we could iterate on and make successful.

pls revert. pls.

How about we:

I mocked this out and intended to build it into the redesign for PHUIObjectItemListView, but never got to it. A snippet/summary button like GitHub uses. Could be useful here.

I searched for 'self actions' earlier today and that search would be much harder now.

D14096 has some screenshots of this and I've pushed it to this server. It may get some design followup but feels relatively reasonable to me in its current form.

Here's a case where the result feels OK, especially if I'm a new user:

On real data, this feels very bloated to me for tasks, at least:

This doesn't feel completely solid to us yet so we're going to try it out for a bit and see if there are further adjustments to make. We're interested in feedback on this version of the feature if anyone has a particularly positive or negative experience with it. I'll push it to this install shortly so it's available to play around with.

See that diff for some details, here's what it looks like currently:

D14095 is a rough pass at this. I'm summarizing (showing the first ~paragraph of content) rather than showing contextual content around body search results. This is easier and maybe-better, given that our search results are more highly structured than webpages? I'm not sure if this holds up in practice.

You listed T7783 twice above btw. Was one of those instances supposed to be a different task?

I expect the general shape of the code to survive, but a lot of the particulars to churn. There are lot of issues with state handling, error handling, locks, which things are responsible for what, etc., right now.

DrydockBlueprintImplementation::newResourceTemplate can't possibly work because it calls a nonexistent mutator on DrydockResource. By extension, the entire DrydockWorkingCopyBlueprintImplementation is currently unusable.

Whoops, fixed. Thanks.

Should be DrydockBlueprintImplementation::executeAcquireLease

Just jotting these down here to make sure they don't get lost:

One caveat to the above is that loading src/extensions/ may trigger loads of other code through autoloading extended classes. So I'd expect one of three outcomes from the PHUTIL_DISABLE_RUNTIME_EXTENSIONS test:

Interesting. That "load libraries" step is much slower than I'd expect; we see ~5-10ms on this host.

/changes/inline is new and has only existed for <1 week, btw

New startup tab for creating an inline comment: