Allowing users to Edit their own details with 'SelfEdit'. How does it work?

Saturday 28 June 2003 8:59:06 am

I want to be able to allow users to edit their own User account but even though you have added a SELFEDIT feature to the user module I cannot get it to work. I just get an access denied error. I have added the self edit feature to the role with no effect.

Am I doing something obviously wrong? And is their any documentation on using the feature?

Your help would be greatly appreciated as I have waited over a month now to resolve this issue and I have a backlog of work do do around this feature.

Thanks
Fats.

-- Stuart

stuart@grandmore.com
http://www.grandmore.com

Sunday 29 June 2003 2:38:38 am

read this too:

http://ez.no/developer/ez_publish_3/forum/developer/editing_a_user_profile

http://ez.no/developer/ez_publish_3/forum/developer/publishing_a_user_profile_draft

paul

Sunday 29 June 2003 3:49:56 am

ok. its a thorny problem. btw are you using 3.1?

Does giving the user access to all (* * *) work?

Monday 30 June 2003 6:57:42 am

I like where you are taking the user. I haven't tried working with related objects yet in that sense but it sounds like you have a better way of extending the user. Ideally it would be nice for the classes to be naturally more oo-like :)

I created a new shop group with a new shop user with the attributes I needed. With that I also changed the site.ini file to reflect the new ids for the shop user id and group so that new shop users go into the right folder to obtain the right role.

Currently i have following role permissions set for this user and can confirm this works:

content read *
user login *
shop buy *
user selfedit *
content edit Class( User ) , Owner( Self )

The (content read *) is contentious i know but for development and while i add new classes i leave it like this and lock it down later.

Is this any different from your own?

paul

Tuesday 01 July 2003 6:03:56 am

Well, at least its been narrowed down, and ill hit the same problem sooner rather than later ;)

Im afraid i haven't time at the moment to test narrowing this down. Have you tried narrowing it down yet?

paul

Tuesday 01 July 2003 11:20:00 am

I have resolved to do a code modification for the time being. I have trying to avoid doing this but I cannot find another solution. So for the strong at heart here is a modification that will resolve the issue.

I have created a new site.ini variable called UserCreatorIDChangeToUserID I then set this to true if I which to use this feature or false if I do not. This gets tested during registration and if true updates the owner id to make the user object owned by the user.

Origionally I used UserCreatorID and tested it for a zero value. If it was zero then I would execute the code below. However since I don't know is that variable has a meaning when set to zero I added a new variable to keep things separate from any other core vraibles.

Here is the code that needs to be inserted into the register.php file.

If the section that starts with:

if ( $module->isCurrentAction( 'Publish' ) )

Here is the code with the changes in it.

if ( $module->isCurrentAction( 'Publish' ) )
{
$http =& eZHTTPTool::instance();

$user =& eZUser::currentUser();
include_once( 'lib/ezutils/classes/ezoperationhandler.php' );
$operationResult = eZOperationHandler::execute( 'content', 'publish', array( 'object_id' => $object->attribute( 'id' ),
'version' => $version->attribute( 'version') ) );

// Start: Code Modification
// A code change to renumber the owner_id to the object id Modified to ensure that
// users created through registration own their own account. This means that they
// can then edit their own account because they are now the owner of it.

$ini =& eZINI::instance();
$userCreatorID = $ini->variable( "UserSettings", "UserCreatorIDChangeToUserID" );
if ( $userCreatorID )
{
$object = eZContentObject::fetch( $object->attribute( 'id' ) );

$object->setAttribute( 'owner_id', $object->attribute( 'id' ) );
$object->store();
eZDebug::writeWarning( "Content Owner ID changed to:", $object->attribute( 'owner_id' ) );
}
// END: Code Modification

And don't forget to put the new variable in the site.ini file.

This is hopefully only a temporary solution because I don't really like changing the base code it goes against my laziness as I will have to bear this in mind evcerytime I do an update.

Anyway hope it helps, it has for me.

Fats.

-- Stuart

stuart@grandmore.com
http://www.grandmore.com

Wednesday 02 July 2003 12:02:23 am

If that variable is dancing around at the moment publish is started then sure, It would be faster.

Fats.

-- Stuart

stuart@grandmore.com
http://www.grandmore.com

Tuesday 29 July 2003 8:03:52 pm

I've tried Fats' hack - I didn't bother with the inifile stuff - 'cause I want my users to be able to change their email adress all the time.

No - Paul that isn't a typo - userCreatorID is set to the value in the *.ini file - the owner can't be true or false :)

I've set up policies thusly:

user login *
user selfedit *
content read Class( User ) , Owner( Self )
content edit Class( User ) , Owner( Self )
content create Class( User )

The new users are able to get all the way to the 'edit' screen - but they can't publish ! When they try they get access denied :(

Fats - u have an idea on this ?

Wednesday 30 July 2003 8:37:11 am

Allowing user/edit by omitting the check sounds like a user would be able to edit any user by Changing SITEURL/content/edit/OWN_ID to SITEURL/content/edit/ID_OF_ANOTHER_USER ?

You should check that Selma - it may be a hole in your setup....

Well - I believe Fats is spot on. It is definately a problem with ownership - and changing the ownership of the new user account to it's own id is the cure...

I tried to change the content owner back and forth directly in the Database - and it is def. an owner problem.

What further foiled me was that I (as the new user) got redirected back to the 'view group' page to which I had no read access !!!

But instead of getting a message saying 'Your changes are stored - but you can't view this page' I got 'Access Denied' which I wrongly interpreted as 'Access denied - you can't change anything'

So now I allow the usergroup to be viewed - I plan to extend the user class with options to show or not show things like email etc...

These are the permissions I've found to be essential for it to work (NB: Together with Fats hack):

content read Class( User group , User ) , Section( Users )
user login *
content edit Class( User ) , Section( Users ) , Owner( Self )

Wednesday 18 August 2004 1:56:28 pm

in case you want to create your users via the textlogin-handler. you should add the following to eztextfileuser.php in /kernel/classes/datatypes/ezuser :

$object->setAttribute( 'owner_id', $userID);

It should be added in the column where the new user-object is created.

visit http://www.jayasinghe.de