Got today a "Restricted" Report for "Home" from one of our users. Hmm.

Kicking this out of scope for now.

I think D17298 is probably a good change for Favorites either way (so we don't have a "pin" UI there that doesn't do anything) since it's pretty simple.

Pinning on Favorites has no effect.

Do we need pinning at all on Home or Favorites? I think it's only for Workboards?

You want to use top-most displayable even if the user has two personal dashboards and has explicitly clicked the pin icon on the second one to make it their default item?

Basically I had this happen to me, thats why I filed it. Users just know they had a default page they installed and it suddenly went away as default - admins maybe figure out they messed up, but can't un-pin. So all users must then go and pin a default to fix.

You can change the rules for picking a default item in PhabricatorProfileMenuEngine->loadItems() if you want to use different rules.

I assumed we were going with top-most displayable, which is simple and admins can't really force you into something else by mistake?

If you're a user and an admin pins a default, it's confusing and likely not expected.

There isn't a way to un-set a default, or pick a different global default as a default, although you can effectively do either by creating a copy of whatever global item you want to be default and pinning it, except "magic home", which you can't copy. So there are a couple of messy edge cases there but they don't feel too important to me.

If Admin "sets default" on Global, and users have not set a default, the page follow admin default. (I had to set my dashboard as default, as seems to be no way of un-setting a default).

• For HTTP, this is broadly expected in some sense until T4369 is resolved.
• For SSH, this is not expected but the linked file is 1.75GB. Did you encounter this in a more realistic scenario and the size of that file is just for demonstration purposes, or are you trying to store ~1GB binary assets in a Git repository? Git is generally not well suited to serve as a binary asset store. GitLFS (T7789) or possible future changes like T11367 are likely better fits for this use case.

Completely fine to make the engine aware of the viewer running the query, I think we just didn't have use cases for that when this stuff was written.

First of all: thank you again for the quick response and great work!

In 99% of cases, the right thing to do when you see an error in the daemon logs is:

@epriestley: Was deleting the active task the right way or did I broke my database or relations?

This report is missing version information. See Contributing Bug Reports and Providing Version Information for help. To move forward:

We can only accept bug reports against current versions of Phabricator, as detailed in Contributing Bug Reports. Feel free to file a new report against a modern version, if this issue still reproduces at HEAD of master or stable.

Is there any plan to add support for this in the near future?

@epriestley: This all sounds excellent. I'll start by fixing any instances of

I have this working downstream in Wikimedia's instance of phabricator, however, our fork is significantly modified. I intend to refactor this into something that is either a) mergeable upstream or b) installable as an extension but for now the code is on phabricator.wikimedia.org PhabricatorElasticFulltextStorageEngine.php

I think D17294 + guidance is maybe good enough?

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).

Not sure if you pulled today or yesterday, but we've had a dozen diffs on the new menu.

@epriestley This part of the migration might be confusing, should we disable the built-in home if they had a Default Dashboard?

OK, yes, that is the default "Builtin" one we ship with. It wasn't previously visible if you installed a global default. When you migrate to HEAD, it should have ended up with 2 links, one for the built-in home, and one for the global dashboard that was migrated. You can disable the builtin Home under Global Menu Item.

Before "Home Menu"

You'd need to tell me more about how your install was previously, in case we missed something with migration.

Ok. But I see two different "Home" Dashboards on our install. It is expected?

Theres a lot of flexibility here, so hollar if you get stuck trying to implement something.

You can now have multiple dashboards, and I think we'll default to the top-most.

I'll write up a blog post this week and I suspect we'll have a migration guide since it's new to old admins.

It's no longer a config, nor do you need to "Install Dashboard", Just add your new one to the sidenav and disable the built in.

Is there a way to change the default dashboard used for Home? Couldnt find a config for this.

I've been seeing exceptions about "Can't parse an empty diff" in daemon logs, which I believe happens occasionally when merging commits and using a strategy to ignore changes from the incoming commit. This happens when merging a branch which might contain commits with similar/same changes which should not be kept due to already being resolved upstream. This results in any phabricator revisions/audits always showing the "Loading Content" when viewing in web.

Usually every Saturday we cut stable, unless we're writing a lot of bugs that particular week.

This sounds great, thanks. We only plan to use it for testing Diffs at this time, so the other branch limitations aren't a concern right now.

We have 2 Homes, I'd like 1.

Why do we need to allow it to be hidden?