user role for self editing

Wednesday 03 August 2005 2:12:01 pm

ez 3.6

I can't seem to get the roles correct to allow my registered members to edit their own information.

I have a role called "Members" which all registered members belong too. They are granted access to a members section of the site and should also have the ability to edit their own details. I have the role setup as follows:

content  	 read  	 Section( Members )
user 	all functions 	No limitations
content 	edit 	Class( User ) , Owner( Self )

I receive Access Denied kernel(1) errors when attempting to edit the user via content/view/full/317 where 317 is the user node id. And Object is unavailable kernel(3) errors when attempting to edit the user via /user/edit. If I log in as the administrator I can edit the user via the node_id method without any problems.

working at www.wardnet.com
blogging at www.jamesward.ca

Wednesday 03 August 2005 11:36:25 pm

James,
I too had a similar problem in 3.6.0
Even though the correct policies were in place within the role, members just could not selfedit.
However if you create a role with the following policies and then assign that role to your 'Members' role you may also find that it works for you (I don't know why).

I think this is the default set of policies for the default 'Registered User' role. So assign this role to your 'Members' role.

content    read 	No limitations
content    pdf 	        No limitations
user 	   login 	No limitations
user 	   selfedit 	No limitations
user 	   password 	No limitations
user 	   preferences 	No limitations

NB. Not certain this is significant, but the changelog for 3.6.1 mentions the following...
Fixed bug: Wrong conditional permisssion when you use more then one "assign with limitation" to one role for the same user (limitations are mixed using logical AND instead of logical OR operation).

The Web Application Service Provider

Thursday 04 August 2005 8:59:48 am

Hi,

Create the following policy :

Content / Edit / Subtree(Users), Class(User), Section (Users), Owner(Self)

Lex

Thursday 04 August 2005 9:22:23 am

Luc,
As soon as I looked at your policies I realised what part of my problem was. Because I have assigned users access section by section I never gave them access to the Users section. Adding this seems to have solved the problem. As I can noe access the user information.

content  	 read  	 Section( Users )

I'm going to confirm that the users can edit their info before I call this thread done. Thanks.

working at www.wardnet.com
blogging at www.jamesward.ca

Thursday 04 August 2005 11:42:34 am

Ok got this close to working correctly. With the following policies in place:

user     password      No limitations
content  read          Section( Users )
content  edit          Subtree( Users ) , Class( User ) , Section( Users ) , Owner( Self )

My users can view their profiles, edit their information, and change their passwords.

I removed the selfedit, and login policies because they seemed to have no effect. I also removed the preferences policy because it would allow users to disable their accounts and control the number of logins they were allowed which is more power than I want to give them.

My problem as Luc mentioned is that any registered users can now browse all my registered users. They can only edit their own accounts but I am worried about someone stealing email address.

Unless there is a policy solution to this I will try to solve it using some template code.

Lex thanks for your subtree editing example it seemed to be the key to getting the editing working.

Luc and Luke let me know if you have any thoughts on how best to tackle the user browsing issue.

Thanks all.

working at www.wardnet.com
blogging at www.jamesward.ca

Thursday 04 August 2005 1:29:58 pm

James,
in the policy profile I've posted above, users can read only their own details.

The Web Application Service Provider

Friday 05 August 2005 2:22:23 am

James,
I upgraded from 3.6.0 to 3.6.1 yesterday and just checked this again. I've just found that with the above policy profile, Editors CAN read other user details. Not 100% certain that this is because of the upgrade, but just wanted to let you know my findings. To fix it I've adjusted the policies as follows...

Editor   (limited to subtree /1/43/)  	content  	all functions   No limitations
Editor   (limited to subtree /1/2/) 	content 	all functions 	No limitations
Registred User   	                content 	read 	        Section( Standard , Media , Denmark, Roskilde , Hungary, Bekes )
Registred User   	                content 	pdf 	        No limitations
Registred User   	                user 	        login 	        No limitations
Registred User   	                user 	        selfedit 	No limitations
Registred User   	                user 	        password 	No limitations
Registred User   	                content 	read 	        Section( Users ) , Owner( Self )

Basically I removed the unlimited access to the Content module (which would have included the User section) and added an ability to read Standard, Media and other relevant (project specific) sections. Then added ability to read User section if Owner is Self ( that bit should not work but it seems it does allow the user to see their own details - even though they are not the owner ).
Also removed ability to edit user preferences, but this is would be an optional change.

The Web Application Service Provider

Friday 05 August 2005 6:51:50 am

In my last post above, the policy

Registred User   	                content 	read 	        Section( Users ) , Owner( Self )

Would generally not help, because newly registered users don't own their record. It worked in my particular case because somewhere along the line the policies allowed the user to edit any user record, so having perhaps created a new draft they became the owner. But new users could not read their details (such as via the link in the welcome e-mail). But they could edit their own details because they had the 'selfedit' policy.
So, in the end the only way I can find to allow selfedit whithout allowing the user to read other user records is to borrow code from the &canEdit() function in kernel/classes/ezcontentobject.php
for use in the &canRead() function
producing....

function &canRead( )
    {
        if ( !isset( $this->Permissions["can_read"] ) )
        {
            $this->Permissions["can_read"] = $this->checkAccess( 'read' );
						if ( $this->Permissions["can_read"] != 1 )
            {
                 $user =& eZUser::currentUser();
                 if ( $user->id() == $this->attribute( 'id' ) )
                 {
                     $access = $user->hasAccessTo( 'user', 'selfedit' );
                     if ( $access['accessWord'] == 'yes' )
                     {
                         $this->Permissions["can_read"] = 1;
                     }
                 }
            }
        }
        $p = ( $this->Permissions["can_read"] == 1 );
        return $p;
    }

This makes the (reasonable?) assumption that if you can selfedit then you can 'selfread'. Too bad it taints the kernel.
Other threads have come up with an alternative solution of changing the owner (to their own id) when the user signs up; instead of using the default owner id set in the site.ini file.

The Web Application Service Provider

Friday 05 August 2005 8:16:30 am

In case anyone stumbles in here looking for the redirect code. This seems to work fine for me.
In my user edit form:

<input type="hidden" name="RedirectURI" value={$object.main_node.url} />

working at www.wardnet.com
blogging at www.jamesward.ca