I cheated them into existence, but unified, browsable lists do work now:

Added my vote to increase the priority for this feature. Thanks.

This is opening up into some very deep infrastructure work.

See also T7472.

T6670

Yeah, I vaguely remember there being a task.

In T5750#95455, @qgil wrote:

Are you considering to interpret #alias in quicksearch box as "in project #alias"? For example, to query a string within the tasks associated to one project only. Right now this is usually a two-step process, first searching for the string, then narrowing to the project.

Original request: https://phabricator.wikimedia.org/T86110

Here's my v0 plan for this:

The draft state is now communicated very clearly. Presuming this is resolved at HEAD until we see more reports.

This View is removed.

Nice, thanks!

AFAIK the "pop in" is an unintentional regression.

I've had a bunch of stuff going on today, but is the "pop in" where the column loads after the page and then the whole layout jumps intentional? It feels a lot worse to me than the behavior I think we had before (empty column which loads content but doesn't reflow the whole page).

On sending messages stuff

I love that last one.

Ah, nice. That feels a lot more palatable.

Non-heavy version.

Yeah, it might be too heavy. Mostly I'm curious if we value added the callout (Finalize Review - scrolls to comment box), if that'd make it more OK. I have some less obnoxious ideas, but wanted to start here.

I like (3) on its own, but they all feel too heavy to actually ship to me -- (2) and (3) moreso than (1). Like, the terrible one-time clippy popup seems less bad to me than making the element that much heavier for experienced users. My thinking that we can make headway here by making the "draft" state more obvious may ultimately be misguided, since these are pretty tame but still feel too heavy to me.

Everything is being re-built and re-designed as far as inline commenting goes, but I don't have mocks yet for the the submission form yet.

I think the real problem is right here:

Any direction you prefer?

I was planning to look into this with T7503

Yeah, basically. Presumably at some level of <blink /> tag, no first-time user will get the model wrong, but then every user pays the price for it forever. That mock feels like too high a price to pay, although maybe there's a 1/2 as blinky version that's more obvious than "Not Submitted Yet" + dashed border.

<blink>Unsubmitted</blink>

One possible approach is to overkill the draft-ness so hard that no reasonable user being can possibly miss it:

We have at least one piece of feedback from a red/green colorblind user that the current color scheme doesn't cause a problem (see T3127#32078), although it's possible this wouldn't extend to the unified view.

This task though is mostly a joke, I only intend to bring the colors inline with our common color palette.

We have many colorblind users of Phabricator and Differential and we've not heard any issues, but there are also many different kinds of colorblindness. The intent on our color use is merely a secondary indicator, and generally will not be the sole indicator of a status. Differential for example, could be enhanced by using + and - columns.

Have you had any feedback about red/green being difficult for colorblind users?

• Value seems very low.
• Behavior is generally consistent with "Find Next" in many programs, including browsers.
• It's a pain to compute "Next (Back to Top)" because inlines can become visible or invisible in response to a bunch of events (e.g., adding and removing comments, showing and hiding files, new files loading).
• There may be only one inline, which would produce something goofy like "Prev (Wrap to Bottom) * Next (Back to Top)" and probably need to be special cased, further raising the complexity of the feature.
• Use case isn't very compelling: there shouldn't ever be a lot of lint comments. If linters are raising nontrivial levels of false positives, delete them. Lint has powerful tools for excluding files, adjusting severities, etc., and particularly after .arclint these are relatively easy to configure.

My only thought was maybe change the text to say:

@chad, do you have thoughts on where you want to go with this? I'm definitely WONTFIX on it -- e.g., neither Chrome nor Safari nor TextMate give a specific visual indicator when wrapping under "⌘G", so this feels consistent to me. I can't recall any application giving a specific wrap indication except nano, which just says [Search Wrapped].

MAKING WAVES MAN, MAKING WAVES congrats, you invented a new color

hahaha, even Incognito returns it first.

I googled that and D11918 was the first result

lots of blindigo

"Code review should be fun!" - even if everything is in shades of blue and grey

Fix0red enough for me.

Yeah, I don't think this is unique to Passphrase.

In the screenshot above, the user does not have access to any items on that list, when clicking Lock Permanently it shows a dialog that says you shall not pass, which is correct, but that item should also be greyed out, there are several places that have this inconsistency.

• Clicking on "Edit Credential" (which is greyed out) returns the "You Shall Not Pass" dialog.
• Clicking on "Allow Conduit Access" (which is not greyed out) also returns the "You Shall Not Pass" dialog.
• So shouldn't "Allow Conduit Access" be greyed out as well?

I don't follow what is incorrect here.

Yeah, this doesn't make sense. Feed goes newest->oldest time-wise, History tends to go oldest->newest. We could combine them but that makes actual history difficult to parse.

There is a small issue with the linking of the jumping icons where the click mask doesn't really work:

In T4214#99869, @epriestley wrote:

Ah, right, we're using the immutable cache, which is DB-backed. You should be able to clear it with:

$ bin/cache purge --purge-all

We should also probably put the PHID in the cache key.

Ah, right, we're using the immutable cache, which is DB-backed. You should be able to clear it with:

We had a similar experience, set the initial PHID for an image file, didn't like the result and then used the same process to change the image. The PHID changed, but the old file was displayed. I think we found the image was cached in the phabricator_cache database, after clearing those caches the new image displayed.

cleared php cache

I was easily able to get it to display a logo image that I uploaded to the files app. However, I didnt like the result. I followed the same process to configure an alternate image but it doesn't work. It accepts the setting and saves the correct PHID, but when the page is rendered, the inline css still points to the old image. It's not related to caching because I cleared my browser cache and I also cleared php cache and restarted nginx. If I remove the custom logo from the config, it goes back to default. Though when I add any other PHID to be the logo it displays nothing at all in the logo area (b/c the image it tries to show doesn't exist).