Page MenuHomePhabricator

Implement "Role Profiles" to provide search, homepage and application defaults
Closed, SpitePublic

Assigned To
Authored By
Nov 14 2013, 6:13 PM
Referenced Files
"The World Burns" token, awarded by epriestley."Like" token, awarded by monsdar."Like" token, awarded by ofbeaton."Like" token, awarded by dans."Like" token, awarded by ProfFan."Love" token, awarded by jonathanrseawright."Love" token, awarded by ivo."Like" token, awarded by JOY."Like" token, awarded by stevex."Like" token, awarded by featherless."Like" token, awarded by tycho.tatitscheff."Mountain of Wealth" token, awarded by zephraph."Like" token, awarded by jazzdan."Like" token, awarded by r0bbie."Orange Medal" token, awarded by philippe.jadin."Like" token, awarded by chenvii."Like" token, awarded by bpetty."Like" token, awarded by michaeloa."Like" token, awarded by aik099."Like" token, awarded by hach-que."Like" token, awarded by qgil.


This probably needs a better name, but the idea is that you could create several "Role Profiles", like "Engineering", "Design" and "User Operations". These profiles would let you configure:

  • Application tiles on the home page (which applications are shown/hidden by default, and which ones get full vs small tiles).
  • ApplicationSearch in applications (specifically, you could customize the default queries users see when they load, e.g., Maniphest for the first time).
  • After T3583, the default widgets/layout/content of the homepage.
  • Ability to set Anonymous and Logged-In default Dashboards
  • Other things???

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.

Revisions and Commits

rP Phabricator

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

My tentative plan here is:

  • 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.
  • Timezone: needs explicit "use default". Grouping by GMT offset might be helpful.
  • Time of day: needs explicit "use default".
  • Date format: needs explicit "use default".
  • Week starts on: needs explicit "use default".
  • Conpherence preferences: needs explicit "use default" and also this panel is silly, but probably a battle for another day.
  • Desktop notifications: needs explicit "use default". This panel has some magic.
  • Diff preferences: 3x defaults.
  • 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.

Summarizing caching for my own benefit. See also T10078, T10077.

Availability Cache: On-object. Maybe move to user cache. Uses weird NO_MUTATE.

Profile Image Cache: On-object. Maybe move to user cache. Uses weird NO_MUTATE.

Preferences: Not cached. Create and move to user cache.

  • Dirty user record on any user-attached preference write.
  • Dirty all user records on any any global preference write.
  • Version internally so we can nuke this cache without migrations later?

Notification Count: Not cached. User cache?

  • Dirty user record on notification clear.
  • Dirty user record on any publish.
  • Why does this load twice?

Conpherence Count: Not cached. User cache?

  • When does this thing dirty?
  • Why does this load twice?

EditEngine + "Quick Create Menu" (T10077)

  • Huge huge mess.
  • Hard to store; hard to dirty.
  • Dirty all on any config edit?
  • Dirty user on on policy error?
  • Probably good enough.

Global Search Settings: Not cached. User cache?

  • Sort of tricky to reduce to a cacheable value?
  • Dirty cache on save of named queries.

Mystery Query: Where is this coming from?

  • SELECT `user`.* FROM `user` user WHERE (user.phid IN ('PHID-USER-cvfydnwadpdj7vdon36z')) ORDER BY `user`.`id` DESC`


I think this leads toward a new <cacheKey, userPHID> user cache.

This leaves us with spaces and config queries uncached, but they aren't user-depedent.

Mystery Query: Where is this coming from?


final class PhabricatorPeopleMainMenuBarExtension
  extends PhabricatorMainMenuBarExtension {

  const MAINMENUBARKEY = 'people';

  public function buildMainMenus() {
    $viewer = $this->getViewer();

    // TODO: This should get cached.
epriestley claimed this task.
  • SettingsCreate Global Defaults as an administrator to set global defaults.
  • T11098 for feedback or bugs.