Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 11 rates

While adding support for a time-zone user preference, the user profile story popped up again. So far, it was only briefly envisioned, when M5 favorites were implemented.


  • Avoid polluting UserMgnlUser APIs with non-security-related concerns
  • Enable external users to set magnolia and/or admincentral preferences
    • Allow easy bridging / mapping between external system user info and magnolia's user prefs 
  • Provide it as a backbone for public user profiles (via PUR)
  • Allow developers and templaters to consume user info

Status on 5.4 / 5.5

User properties

  • All user fields are stored as properties of the user node, in the "users" workspace.
  • These fields are subsequently exposed on the interface.

This has the "advantage" of being easy to edit for both sys-admins and users themselves.

  • In the security app, through workbench selection and dialog (security-app:user)
    • fields: [ node name, pswd, enabled, title, email, language ]
    • additional group/roles tabs
  • From the user menu, through the editUserProfile action and dialog (ui-admincentral:editUserProfile)
    • User node is strictly resolved in the action, via MgnlContext > MgnlUser > #getPath() and passed to the form presenter.
    • fields: [ node name, pswd, title, email, language ]
  • Plain JCR dialog and node-adapter in both cases.
  • Mind the duplication, inconsistency, and arguable naming of the editUserProfile dialog definition.

Favorites on the other hand were designed around the a vague idea of user profile.

  • Favorites are stored under the "profiles" workspace
  • Favorites components are full of JCR and JcrNodeAdapter APIs, e.g.FavoritesManagerImplFavoriteStore
    • With irrelevant packaging, see info.magnolia.ui.frameworkinfo.magnolia.ui.admincentral.shellapp.favorites
    • What's the difference between favorites and bookmarks?
  • ACL setup for the profiles workspace is unclear, see  MGNLUI-2981 - Getting issue details... STATUS

User vs. Preferences

Here's a summary of what belongs where:

User / securityPreferences / profile
  • name
  • password
  • enabled
  • groups/roles
  • email
  • title
  • language
  • time zone

and potentially...

  • additional personal details
  • avatar
  • favorites
  • app-launcher settings
  • notification settings
  • content view settings (e.g. tree density, thumbnail size)

(question) Is email *just* a profile information? (accounts are usually bound to a single email as identifier)

(question) *Some* preferences may be provided by 3rd party systems too, do we consume them and/or allow to override them?

Where to go from there...


  • Split dialog into separate tab/section for user info (maybe read-only) vs. preferences
  • Remove dialog duplication
  • Expect to build upon forms refactoring to compose a dialog with tabs, backed by different items
  • (question) Should security-app even allow to view/edit user preferences info in its dialog?
    • admin vs. user privacy
  • (question) Even compute the dialog from the model?
    • instead of using the dialog as the model and back-mirroring it in User bean


  • Profile as an optional module of main, though present in typical bundles
    • a minimal magnolia could live without user prefs
  • Favorites management APIs extracted
    • does exposing favorites without the UI make sense?
      • can public users benefit from favorites? (wouldn't do it most likely)
    • not on UI framework level
    • fav shell-app as an admincentral reactor sub-module
    • Refactor Favorites API to eliminate JCR and adapter references

Consuming preferences

  • (question) Via (User)Context?
    • tryptic between context, security and preferences
      • => security and preferences on lower level than cms
  • Via userfn
    • getPreferences()
    • getPreference(String preferenceKey)


  • (question) Going further, should we go as far as having multiple workspaces per user entities, i.e. favorites in their own workspace?
    • calling for a workspace permission scheme to easily setup workspace ACLs and UI behaviors, when content shouldn't be shared between users

  • No labels