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.
Goals
- Avoid polluting
User,MgnlUserAPIs with non-security-related concerns - Enable external users to set magnolia and/or admincentral preferences
- 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
info.magnolia.cms.security.Userinterface.
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
editUserProfileaction 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 ]
- User node is strictly resolved in the action, via
- Plain JCR dialog and node-adapter in both cases.
- Mind the duplication, inconsistency, and arguable naming of the
editUserProfiledialog 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.
FavoritesManagerImpl,FavoriteStore- With irrelevant packaging, see
info.magnolia.ui.framework,info.magnolia.ui.admincentral.shellapp.favorites - What's the difference between favorites and bookmarks?
- With irrelevant packaging, see
- 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 / security | Preferences / profile |
|---|---|
|
and potentially...
|
Where to go from there...
Definitions
- 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
Should security-app even allow to view/edit user preferences info in its dialog?- admin vs. user privacy
- Even compute the dialog from the model?
- instead of using the dialog as the model and back-mirroring it in
Userbean
- instead of using the dialog as the model and back-mirroring it in
Components
- 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
- does exposing favorites without the UI make sense?
Consuming preferences
- Via (User)Context?
- tryptic between context, security and preferences
- => security and preferences on lower level than cms
- tryptic between context, security and preferences
- Via userfn
- getPreferences()
- getPreference(String preferenceKey)
Storage
- 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
Overview
Content Tools