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

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.

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.

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

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

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

My vs. an other User:

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

Previously there was:

• Builtin (hardwired) Home
• Dashboards (Install as Personal Home)
• Dashboards (Install as Default)

Hardwired Home is still present. Personal Home should have migrated to Personal Menu Item and Dashboard (Install as Default) should have migrated to Global Menu Item.

Before "Home Menu"

1. All Users have set a customized dashboard (installed globally)

2. Our small team (internal) have es second dashboard (installed personal)

The current visible dashboard on HOME, does not match the one from 1. or 2. It look like that is a default dashboard. It would be cool, if we could set it like 1.

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.

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

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

I think D17294 + guidance is maybe good enough?

If we try to disable "Home" I think we need to write rows for every builtin item, or "Home" will float to the top, since builtins with a row sort above builtins without one. If we continue tweaking builtins, that might lead to more confusion down the line than not disabling home would.

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'd say this behavior is reasonable -- if you want a different default, pin it? That is, my expectation is that we use these rules to choose a default:

• If a personal item exists and is marked as a default, select it.
• If a global item exists and is marked as a default, select it.
• If any personal items exist which could be marked as a default, select the first one.
• If any global items exist which could be marked as a default, select the first one.
• Give up and select "magic home" if we make it this far without selecting anything else.

Would you expect different rules?

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 we want to clean them up, we probably need to change defaults to be per-user, I guess? And change the pinning workflow to let you select any personal or global item. Doable, but not sure how valuable it is as a v1 feature.

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

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

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

If we make a possible Personal default beat a selected Global default, we might end up in this scenario:

• User adds a dashboard item to see what it does.
• Their homepage changes, which they didn't expect/want.
• They can't get back to the old one without deleting the item.

That feels a little more likely/surprising to me than the scenario you outline, but maybe it isn't.

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 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?

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

Pinning on Favorites has no effect.

Pinning on Home has an effect, but maybe it's simpler to remove it than try to resolve these cases.

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.

I think just removing the feature on Home is reasonable for an initial version, too. I'm 100% happy with that solution forever on a personal level and it's a lot simpler than anything that involves the explicit "pin" action.

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

It says restricted application and only members of a certain project. Do you have steps I can reproduce the bug locally. I can't reverse guess here offhand how you've configured your instance to get here.

We should make sure to not error out the sidenav though.

1. If I remove a user from our internal group (Project: contain internal members), I receive the error above.
2. The internal group is only visible to its members (explains the "restricted project")
3. Removing the "visible to" restriction, displays Projektname in error message

BUT: All our old Dashboards are visible to all users. hmm

Please file a bug report with the steps we can follow to reproduce what your seeing. I still can't follow what I need to do here to see this locally.

Awesome, thanks for hunting that down.

I thought it might be that same issue, but sounded like it was a new issue and not a pre-existing one.

I'm not sure if I actually fixed @rphl's issue or not. D17308 was just aimed at the existing issue under the theory that we'll see more of it after this ships if we aren't already seeing it, but his report definitely might be a new issue.

It might have fixed @rphl's issue, if the underlying problem was something like: a dashboard contains a Query panel that runs a query for an application which the viewer can't see. Maybe. I'm not immediately sure how we can hit an Application policy exception from Home, unless that application is Home or Dashboards.

One thing I thought I might do is special-case the policy exception for applications so it says their name, since application names aren't secret. Then the dialog would at least say "You can't see Diffusion." or something instead of "You can't see an application.", and that would probably make it more clear what was going on in most cases. But the whole thing may have magically vanished at HEAD after D17308 if we're lucky.

Yeah, I don't think I fixed it. I tried this set of steps at master prior to D17308:

• Create a Dashboard visible to All Users.
• Add it to Home.
• Add a Query panel showing Commits.
• Restrict "Can Use Application" in Diffusion to only user A.
• View the dashboard as user B.

This failed to reproduce the issue that @rphl reported. The dashboard and panel loaded normally, just with no commits visible.

I'm going to write up Diviner now, then Upgrading guide

got it! Could reproduce the "restricted error":

• Our Phame Application is restricted to the "internal team" (specific project with members).
• But we have added Phame it to the "global menu"
• All other users without access to this team, receive this error for Home
• If I remove Phame (restricted app) from the Global Menu, the dashboard is accessible to all users.

One other thought: it might be nice to provide a way to get to the dashboard from the dashboard-in-a-menu view. Currently, there's no way to "Edit This Dashboard" from Home or Projects: you have to go to Dashboards, hunt it down, and then manage things from there.

Yeah that is one argument for crumbs

Two possible alternatives to crumbs I can come up with, although I don't love either:

• Let menu items have a little edit action that shows up on the item itself, like workboard cards? (But 99% of the time you wouldn't want to click this?)
• Put this workflow inside "Edit Menu" (but that's pretty obscure?)

If we did do crumbs + edit/dropdown button, dashboards could also have "View Standalone" as an option, although that doesn't feel huuugely useful to me.

Put this workflow inside "Edit Menu"

You might also want to edit the dashboard -- and be able to -- without having permission to edit the menu, which is another argument against this.

I plan to go back to Photoshop and re-work dashboards top to bottom... at least, but a lot of time fixing the bad UX everywhere, then ship it as a default application. With Nuance + Facts possibly coming, seems right to get ahead of them.

Might even contract some illustrations O.o

Just tested this out with having global menu items of Create Task forms and Projects, each which are only visible based on some policy - looks to not have any issues hiding/showing based on those policies. Thanks for all this, when I get these changes into production install I'll check for feedback but I'm anticipating it will be a smoother experience for everyone.

I just noticed that that tooltips behave unexpectedly for application entries in the menu: When the application has no "Name", the default name is displayed as well as a tooltip on mouse-over. When I set a custom "Name", only that name is displayed and the tooltip is no longer displayed.

That's expected. When you customize the name, the built-in data (name, tooltip) goes away.

In T12174#213852, @chad wrote:

That's expected. When you customize the name, the built-in data (name, tooltip) goes away.

Will it be possible to set a custom tooltip?

It's not hard to add, just curious what the use case is. Most requests have been to "rename" the applications (Differential -> Code Review"), so pulling in built-in tooltips didn't make sense. Maybe we should add tooltip to the "Link" menu type for best flexibility.

Add catfacts tooltip to each application?

You can now add tooltips adhoc to "Link" menu items.

It would be nice if we could have tooltips for Apps, etc. too

At the current time one of our Menuitems sounds like: Tasks & Bugs (Maniphest)
But I would be great if we could name it just Maniphest and add a Tooltip Tasks & Bugs to it

Other Example: Wiki(Phriction) would be Phriction < Wiki

That's the default behavior, and you can achieve it by deleting "Name":

Alternatively, use "Link" and make whatever you want.

Though I guess we need the icon typeahead there.

thanks for the hint

In T12174#213854, @chad wrote:

It's not hard to add, just curious what the use case is. Most requests have been to "rename" the applications (Differential -> Code Review"), so pulling in built-in tooltips didn't make sense. Maybe we should add tooltip to the "Link" menu type for best flexibility.

The use case is that we renamed applications, but would like to retain the original name somewhere, because it is being used throughout Phabricator and people would be surprised to find the original names, without knowing what these are referring to.