For example, the "Design" profile could feature Pholio prominently and hide Audit by default, or whatever. The "User Operations" profile could hide most of the apps by default.

We're probably not going to pursue this any time soon on the natural roadmap, but @jbrown and I talked about it in IRC a bit and it has come up a few times before. I think attacking this globally (top-level profiles, vs just default Maniphest filters or something) is the best approach, since all of the above seems fairly closely related to me. This probably isn't technically complicated, but is a fair bit of UI work.

Turn PhabricatorUserPreferences into a full object which implements PhabricatorApplicationTransactionInterface.

Rebuild /settings/ in a parallel /settings-pro/ using EditEngine + transactions + modular settings + modular groups (these are partially modular already?), making sure each setting has an option to set it to "default".

Support the creation of standalone preferences sets which are not bound to a particular user.

Wire up the inheritance stuff, caching, global assignment, etc., to make this actually work.

This is mostly straightforward. A few controls have some level of issue:

Translation: I want to separate "complete", "usable", "very incomplete", and "special (silly/developer)" translations in this menu, but that's just an <optgroup /> sort of thing. Some adjacency to T5267.

Pronoun: Not sure if setting a global default is useful here, although I could perhaps imagine, say, a summer program for female engineering students might want to default the pronoun to "her". Feels a little weird to have an explicit "Use Server Default" option here though, so I'll likely keep the visible behavior the same even if I do make it possible to specify a default pronoun.

Display preferences: 4x defaults. Need a way to enter both "use default" and "empty string" in a textarea? Maybe it's fine to not be able to set these to empty string if the server specifies a default. These seem to be the only textarea prefs we have, so probably fine to cheat.

Home page: Needs complex weirdness if we're going to try to merge the defaults with user settings, or nothing if we're just going to overwrite. Maybe needs "reset to default"? Maybe also needs "show default" if it has "reset to default"?

Search preferences: These options are so, so, so dumb.

I'm going to remove the jump nav setting. I don't think there's any reason to ever disable it, and it came from an abundance of caution ages ago in T916.

I'm going to remove the "/" setting and the "/"-to-focus behavior. See T916 + T989. T989 is a compelling reason not to support this behavior. Users can add this behavior with browser extensions or we can pick some legitimately unused keystroke if there is somehow outcry about removing this. At least in my browser, the "tab" key has the same effect and is more obvious.

Developer settings / Dark Console: this doesn't really need a default but I guess. This option is also kind of weird.

Email Format: Already have defaults.

Email Preferences: 2x defaults, and then I guess we just add "use server default" to the 400 notification options. ¯\_(ツ)_/¯ This needs fixing but here is probably not the time or place.

None of the other stuff is "real" settings that make any sense to inherit.

There are some additional things stored in settings that have no corresponding preference panel (like the collapsed state of the durable column, and of the filetree browser, and ignored timezone offsets) but these don't make sense to set as defaults.

finalclassPhabricatorPeopleMainMenuBarExtensionextendsPhabricatorMainMenuBarExtension{constMAINMENUBARKEY='people';publicfunctionbuildMainMenus(){$viewer=$this->getViewer();// TODO: This should get cached....