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

I think D17294 + guidance is maybe good enough?

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.

We have 2 Homes, I'd like 1.

Why do we need to allow it to be hidden?

Also need to allow fake 'Home' to be hidden... somehow. I can make a fallback page if needed.

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.

I looked briefly, but couldn't figure out how to move fake 'Home' into the Personal Menu as a built-in

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

Based on that, the problem to solve is making "contributor" type dashboards easy to find/install.

So let me walk through what I think you're suggesting.

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.

As far as Dashboards in general go, I was planning on that next (as a project to clean up) and haven't given a lot of thought about logged in / logged out versions. I have no idea how many installs rely on these, so assumed at least, we weren't removing the feature.

As a user, being able to hide global links is probably going to come up, and is another way to resolve this.

Oh, or is that non-hypothetical?

You're asking me a question I'd probably put a few weeks in to answer.

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

The main thing right now is we have two different Home dashboards. If there was a way to resolve that to just one (maybe I just do this in PhabricatorHomeMenuItem?) then we shouldn't need public/all user menu items. At least, I'd wait for more use cases like you suggest.

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 was referring to menu items. If we can fix up Dashboards enough that (logged in/logged out) is a single dashboard, I think that resolves the immediate use case.

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?

Are we comfortable for Global menus of giving admins "visible (logged in), visible (logged out), visible (all), and hidden" as visibility options? Or just implement Policy and really confuse everything?

Resolved at HEAD. Follow T12174 for bugs/feature requests/future action items.

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:

A quick word to express my satisfaction about the new personal menu: after some days, it becomes standard practice on two instances I use to access current sprint workboard from the menu.

The buckets now in Audit also make the count confusing, before I think it was all open audits, but now we break them out like in Differential. Maniphest makes some sense, but not really in any actionable way. I think Nuance though, we should have some sort of count since the goal of that product is "inbox zero".

Yeah that makes sense. On mobile you don't get the dash but in that scenario you're probably wanting to look at most recently activity and not so much of "what do I have to do today".

Home should be "stuff I need to address". I don't think per-app "counts" really solve anything at this point with customizable dashboards.

Would it be the same effort to show that there are any vs. no items needing addressed?

I have discovered that we already have PhabricatorDashboardProfileMenuItem.

Oh! I thought that mock was a screenshot and that "Home" was a new DashboardMenuItem. No conflicts, I'll shoot you a diff in a bit.

I don't think we'd conflict? Nothing I'm doing is in MenuItem (all that stuff is wired). I'm just deleting code.

Yeah, but since you already wrote DashboardMenuItem we'd conflict -- do you want to just diff that separately now, then I'll fancy-it-up and it should integrate cleanly?

Oh, I guess you could pre-patch me with projects then

We shouldn't need to build a route into the applications separately -- getProfileMenuRouting() already adds a route (from the code, I guess the actual route is /home/item/view/123/).

proooobably projects too

I hadn't considered building dashboard routes into /home/ but that seems pretty simple.

Yeah, fully agreed that we should stay in Home in terms of the nav menu, crumbs (none on Home, but relevant for Projects), checking application permissions, etc. I just got scared off by "AJAX", since I think the non-ajax thing will take me 20 minutes and an Ajax version would take me 20000 minutes.

Yeah, this is just polish to me, though it makes dashboards I think way more useful (and likely what I'll want to fix the UX of next).

If you just want to diff that when it's ready I can implement the fancier version to get the dashboard rendering on the same page. Looking at the code, it's not quite as simple as I remembered -- I thought we had some similar panels already, but all the stuff we have is more hard-coded than I thought.

On here I've added a personal dashboard called "home", if I click it I go to dashboard/view/1/, and I don't stay on home. Maybe I implemented the dashboard menu item wrong?

I mean if you're on home, and you have 3 dashboards, that you don't leave home. I think we talked about this before and you said that was simple.

Do we actually need this? Dashboards already load nothing since all the individual panels are ajaxed -- and even less with Quicksand -- and there's no state to preserve? What's the goal?

That is, the rule the menu already uses is already "show the item the user has explicitly selected as the default item, or the first item which they could select as a default, if they haven't selected one yet". This is what lets you pick projects to default to the workboard or project profile, but causes them to default to the project profile.

Selecting first dashboard as homepage. I think I can just query the menu itself in MainController and pull it out? Use built in home if nothing returned?

I think I have most of this working, but there will be some follow ups needed I'll need help with:

In T12136#208145, @chad wrote:

I can vanish them now.

I can vanish them now.