[MAGNOLIA-574] User preferences Created: 12/Oct/05  Updated: 23/Jan/13  Resolved: 29/Sep/08

Status: Closed
Project: Magnolia
Component/s: admininterface
Affects Version/s: None
Fix Version/s: 4.0

Type: New Feature Priority: Major
Reporter: Boris Kraft Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
duplicate
is duplicated by MAGNOLIA-1371 Add button 'User properties' to allow... Closed
relation
is related to MAGNOLIA-2388 Easy privilege escalation from user p... Closed
is related to MAGNOLIA-551 Dialog controls show wrong locale Closed
is related to MAGNOLIA-573 customizable change notification Closed
is related to MAGNOLIA-1265 User Dialog allows to add denied Roles Closed
is related to MAGNOLIA-2320 Remove hardcoded user permission modi... Closed
is related to MAGNOLIA-2692 When using ExternalUserManager user c... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

Mechanisms to have user preferences so that each user can change his own preferences like password (obviously), email, name, language but also other stuff (extensible) - one example is the change notification scheme. see MAGNOLIA-573



 Comments   
Comment by Philipp Bracher [ 17/May/06 ]

The user dialog should be configurable like the others

Comment by Magnolia International [ 24/Aug/07 ]

related to the public user registration project (see MGNLPUR)

Comment by Magnolia International [ 24/Aug/07 ]

http://jira.magnolia.info/browse/MGNLPUR

Comment by Magnolia International [ 06/Jun/08 ]

Could we - for 3.6 or 3.7 - just have the logged in username clickable, which would open the user's own edit dialog ?
Currently the only possibility for a user to change his own password is to setup complex ACLs, just to have the proper items in the menu, which is fairly annoying - I think the actual ACLs to write to his/her own node are there by default for every user ?

Comment by Jan Haderka [ 11/Aug/08 ]

Actually by default users do not have even read rights to their own node at the moment.

ERROR  info.magnolia.module.admininterface.DialogMVCHandler DialogMVCHandler.java(getStorageNode:359) 11.08.2008 14:49:34  can't read content to edit
info.magnolia.cms.security.AccessDeniedException: User not allowed to Read path [/admin/test]
Comment by Jan Haderka [ 12/Aug/08 ]

when preferences are changed via user preferences dialog linked directly from the main frame (by clicking on the user name in right top corner), whole frame is reloaded and therefore even menu and top header is updated.

Comment by Jan Haderka [ 13/Aug/08 ]

r17287

Comment by Fabrizio Giustina [ 13/Aug/08 ]

wow, looks a little bit too "open"!
Any user should obviously be able to change its password or details, but letting anyone adding himself to the superuser group through this preference dialog is maybe too much

We should create a specific dialog for this preferences, without the group/roles section, and be sure that the automatically added acls don't allow changing its own groups...

Comment by Fabrizio Giustina [ 13/Aug/08 ]

hint: maybe we could just leave the user acls as they are now, without adding any specific permission for changing their own details (maybe adding only READ permissions).
Then we could create a specific dialog for this and a custom save handler (see MAGNOLIA-2272) which carefully check the admitted values against the currently logged user and save them using a system context operation... probably better than hardcoding specific acls in the user dialog...

Comment by Jan Haderka [ 14/Aug/08 ]

The problems you mention are not a problem of exposing the user preferences dialog. Please see MAGNOLIA-1265 and MAGNOLIA-2320 for details.

Comment by Fabrizio Giustina [ 14/Aug/08 ]

> The problems you mention are not a problem of exposing the user preferences dialog
well, but exposing the group/role selector as a part of the user preference dialog is IHMO surely not expected... at least we should create and expose a specific dialog without this part, WDYT?

Comment by Jan Haderka [ 14/Aug/08 ]

I think that when the other related issues are resolved user won't be able to assign themselves groups/roles they do not have access to. The nwe can discuss whether it is appropriate to also disable this option in the dialog or not. But first of all we have to make sure users are not able to widen their own privileges themselves.
As for my personal opinion, I think it is ok to show user groups and roles they are assigned to. As well as to show them extra groups/roles that they have already enough privileges to assign to themselves. This way when admin is setting rights for the users they can easily check whether ACLs they are using have intended effect or not, rather then waiting for some smart user to discover how to assign something extra so themselves even if such options are not visible by default.

Comment by Jan Haderka [ 29/Sep/08 ]

reverting fix in 3.6.x due to security concerns (users can lock themselves out of system). For details see MAGNOLIA-2388.

Comment by Jan Haderka [ 29/Sep/08 ]

Keeping for 3.7

Generated at Mon Feb 12 03:18:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.