I'm going to close this as tentatively resolved since it's fairly old and things have changed a fair bit since it was filed. I believe we may now handle this use case reasonably well. If you still have use cases for this that aren't addressed at HEAD, feel free to file a new issue describing what problems you currently face after upgrading (following Contributing Feature Requests).

Why do we need to allow it to be hidden?

It looks like it works, it's just a little confusing since "Home" doesn't show up. I'll fix that:

Also, we might be torpedoing open-source installs which don't have a dashboard right now since the magic "Home" doesn't show up if you're logged out. I'll look at that.

I think that's a whole pile of work, I was just thinking that administrators could disable the global item.

Leave the default fake 'Home' as is (corporate install, your stuff)

I also, generally, can't come up with any uses for links that or other items which are only visible after you log in, outside of dashboards.

I'd like to wait until we have a good answer on how we'd use this feature before we pursue it. I worry that it adds a significant amount of complexity and may really have zero use cases. In the best case, it is useful to only a tiny number of open source installs.

Oh, or is that non-hypothetical?

How would you like the two dashboards to differ on this install?

Oh, maybe I misunderstood then. How would you like to make the logged-out vs logged-in menus different on this install, or how do you think other open source installs would benefit from this? (This only impacts open-source installs, right?)

I'm not really sold on the use case -- which is just letting open source installs have a logged-in dashboard tailored to the user, right?

Please follow the rules in Contributing Feature Requests when submitting feature requests.

• After D17282, we do branch=phabricator/diff/689, commit=HEAD when building revisions.
• After D17282, we do branch=<one arbitrary containing branch>, commit=<commit hash> when building commits.
• The "GitHub Settings" workaround above resolved the "tags disabled" issue, as suggested.

Yeah, run bin/audit synchronize --all (or rXYZ for just one repository) after doing manual cleanup with bin/audit delete. This is noted in the documentation at HEAD as of ~yesterday, although it may not have regenerated in production yet.

I think I've pushed this approximately as far as I plan to in this iteration. Everything mentioned in the description has been tackled, and audits on this install are now in a relatively sane state.

(arc list will also grow some kind of --reviewer=me --status=open mode in T7715, but I suspect that no one would really care if arc patch just did that by default.)

D17283 allows you to double-click the D1234 crumb to select it, since it's no longer a link. I don't know if double-clicks are too complicated or not.

The selection junk is caused by float: left which apparently fixed some kind of IE thing in 2014 (T5902) so that may be involved to fix.

Also a lot of users do not notice this text is in the URL since on Safari the browser hides everything except the domain until you click on it.

One general improvement we could make is to have arc patch without arguments offer you open, non-authored revisions in the same repository, using the new numerical menu selector from T10895. That might moot this, and I can't immediately imagine any other default behaviors for arc patch with no arguments (other than showing you how to provide arguments, as it currently does, but we could retain this text in an abbreviated form).

I'm also confused about this:

arc list will eventually be more flexible (T7715) but today it's only your stuff.

Er, oh, other reviews. Then maybe this feedback should be on T12026, rather than here.

Oh, then arc list?

@jcarrillo7: there is no command line way to get back a list of reviews (with their identifiers) that are active for the current repo.

We queried a subset of instances to gain insight about how frequently repository data is hosted on GitLab, so we're better prepared to respond to any indirect fallout from a recent operational incident on their side:

Broadly, I'm supportive.

All changes in Phabricator need to be driven by strong, real-world use-cases.

I'd like to see real use cases for this before pursuing it. In the use cases above:

Build also works fine if I submit it unmodified but omit the refs/tags/... prefix.

Only hit for "tag" is in this paragraph, which has no limits set (unless "empty text field" means "no tags"):

Here's a more granular transcript which suggests I'm not doing something goofy:

When I submit this:

Upshot: I'll do the thing that works for now. If we have tension down the road for the "code reviews intended for master" vs "code reviews intended for develop" use case, we can deal with it when it actually arises. It may be completely hypothetical. Users that did care could conceivably lift HARBORMASTER_BUILD_TARGET_PHID out of the environment and use Conduit to figure out where the review was targeted.

I guess there's also some amount of overloading here for "branch" and "commit", which is understandable since building tags/refs is rare.

This may be a bad approach, but one possible not-great-but-not-horribly-disruptive change might be this:

I think what I actually did was this:

Hrrm, I may be incorrect about that and have accidentally forced the tag to fetch in some other way.

Things seem to work fine as long as we pass the full path to the tag (we currently don't, since I'm reusing some CircleCI code and CircleCI, a lovely an inventive build system with many creative and original ideas, did not work with a full ref).

Let me poke at things and see how far I can get, there's a lot of future design space here that I want to leave open.

🐈

Because of the complexity of building a reproduction case and high chance that this is a wild goose chase, we'll move forward with this after a community member confirms it reproduces for them. See T12134 for some discussion. See T12129 for a similar recent report which was a time-consuming wild goose chase.

I'm working on this thing but it's turning out to be fairly involved so I probably won't have a diff for a bit:

I'll counterdiff you for these:

This was fairly straightforward since the Buildkite API and Harbormaster appear to have very similar models of the world. D17270 adds at least basic support. It uses webhooks, so you don't need to configure any post-commands. There may be some bugs or rough edges, so let us know what you run into if once you have a chance to try it out.

This also touches T10333: if you drop below card Z in group G (say, "High Priority" or "Assigned to alice"), I think intent is always to end up in group G even if card Z has moved from that group.

When you drop a card into a column, we send something like "alincoln dropped card X into column Y below card Z" to the server.

These aren't really related from a backend viewpoint, even though they're closely related from a UX viewpoint.

We're also assuming that you're red/green colorblind -- is that right? If you have some other kind of colorblindness, I think that would tend to explain why the colorblind changes made things worse for you, and I probably should not call the accessibility mode "Red/Green Colorblind".

• A very light "removed" color (default: very pale red) for lines which have removed text on them.
  • A more visible "removed" color (default: red) for lines which have been completely removed, text on lines which has been removed, and removed text in prose diffs.
  • A very light "added" color (default: very pale green) for lines which have added text on them.
  • A more visible "added" color (default: green) for lines which have been completely added, text on lines which has been added, and added text in prose diffs.

Do you want to give me four colors that work well for you as a starting point, by, e.g., control-clicking an existing diff and fiddling with the CSS?

Prose:

Better? Both just look grey?

Sorry I mean indigo

pink / slightly different pink incoming

@chad, I don't mind doing the legwork on this if you're OK with a separate mode.

I think we should just revert to the old colors and put a blue/orange mode in Settings → Display → Accessibility, since no one seems excited about doing the legwork in T12060 to pick other colors.

We recently darkened that color in T12060 to improve the UI for colorblind users, and the change was specifically vetted by a colorblind user (although maybe not a colorblind engineer who uses Phabricator? T12060#205789).

What version of Phabricator are you using?

I can't reproduce this. Here's what I did: