Or get rid of the darker sidebar. I think it's only needed on projects/profiles

(Or whatever more nuanced version of things you want to do. But that's the current fate/rationale of phabricator-home.)

.phabricator-home makes the menu full-screen on mobile, so it's currently only applied to /.

Might even contract some illustrations O.o

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.

Put this workflow inside "Edit Menu"

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

Yeah that is one argument for crumbs

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.

got it! Could reproduce the "restricted error":

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

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

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.

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

Awesome, thanks for hunting that down.

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.

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

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.

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

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

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.