[MAGNOLIA-3728] Users created without permission to change own properties Created: 07/Jun/11 Updated: 19/Dec/16 Resolved: 04/Aug/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | admininterface, security |
| Affects Version/s: | 4.4.3, 4.4.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Marc Werlen, Netcetera | Assignee: | Philipp Bärfuss |
| Resolution: | Outdated | Votes: | 4 |
| Labels: | admincentral | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
local dev env, enterprise edition, windows |
||
| Attachments: |
|
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
When creating new User in the admincentral (Menu 'Security'=>'Users', then invoke 'New user'), user is created as untitled, which seems correct. According to forum thread The user is created, but no 'acl_users' node is included. Renaming the user to 'user1' doesn't add the missing 'acl_users' node, according to export-XML. When logging-in as the user1 and editing own settings, the dialog is empty when loaded, save leads to empty page. after submit a npe is logged, caused by the node not read previously to the password dialog control: Can be reproduced perfectly on current demoauthor-instance (althought the 'eric' demo-user is able to change own properties). |
| Comments |
| Comment by Danilo Ghirardelli [ 10/Aug/11 ] |
|
This is quite annoying for users... My workaroud for the problem is to add a role with permission to read/write the users repository. Not exactly secure but at least users can change their language or password. |
| Comment by Marco Glur [ 22/Nov/11 ] |
|
Is there any work going on or is it quasi rejected to fix this? The work around won't work for us due to our security demands. Users must not be able to add themselves new roles or groups. |
| Comment by Marco Glur [ 28/Nov/11 ] |
|
I found a possible solution to the problem, when looking at differences between adminInterface tree definitions:
Setting the class accordingly for the tree usersAdmin seems to fix the problem. Now I'm not quite sure if there is any impacts caused by this tree handler class, or if there is a good reason it is not set to UsersTreeHandler. Fixed and exported file attached. |
| Comment by Michael Mühlebach [ 04/Aug/15 ] |
|
We're closing this issue as outdated as it was reported for 4.4.x or earlier versions which are no longer supported. Don't hesitate to reopen or create a new ticket in case this is still relevant and you'll experience it on 4.5.x or later versions. |