changing users settings of local users

Reported by Wim Boucquaert on 2006-09-22
16
Affects Status Importance Assigned to Milestone
Silva
Low
Daniel Nouri

Bug Description

In a local folder with it's own acl_users it's not possible to change your own
user settings. You are asked to login but are not authorized to change your
personal settings.
When you try to change your personal settings and login with a user with manager
rights in the root you are able to log in as that manager and change your
"manager" user settings. If you then refresh you can see in the right bottom
that you're still logged in as the non-manger user with the local rights but if
you click on the uses settings you still get the managers personal information.
If you create a document you create it as the non-manager user with the local
rights. So there is something wrong with de users settings in Silva 1.5. I'll
test it on Silva 1.6

Eric Casteleijn (thisfred) wrote :

No this is not connected to the other 2 issues.

Kit Blake (kitblake) wrote :

This problem did not get fixed, while there are lots of sites out there with
nested acl_users.

Flynt (flyntle) wrote :

Up to now, following a statement of Infrae sometime in the past, at ETH we do
not officially support nested acl_users. There were some efforts in the past
with a "satellite acl_users", but the work on that has been dropped.

However, it should have been fixed in the past, that in a situation with one
acl_users in Silva Root any user can change his user settings. Can we trust on that?

Kit Blake (kitblake) wrote :

> However, it should have been fixed in the past, that in a situation with one
> acl_users in Silva Root any user can change his user settings. Can we trust on that?

Yes, that works as it always did.

Kit Blake (kitblake) wrote :

Since Reinhard has a better memory than I do, I'd better rescind my statement
until I find out why we haven't supported it in the past. It may not be
possible, or a good idea.

Kit Blake (kitblake) wrote :

We're not going to fix this in the 1.5 range, and we need to investigate the
'why' before changing anything.

Sylvain Viollon (thefunny) wrote :

This was fixed with the refactoring to Silva 3.0, since the code that edit the object is now trusted (zeam.form).

Changed in silva:
milestone: none → 3.0.2
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers