Monday 19 April 2004 10:48:27 am

Hey Gunnstein,

thank you for your answer. Giving away the passwort is not a really serious solution. Even if your suggestion would be acceptable there is the problem that I always need to log in into different accounts - I would do this only once a day - not really in time...

I spent almost the whole day on this problem - trying to find out how for example the pendinglist works. Now I have an idea...:

In the file 'kernel/content/ezcontentfunctioncollection.php' the function fetchPendingList() is defined. This function calls eZPersistentObject::fetchObjectList() with the following condition for the database query:

array('creator_id' => $userID, 
      'status' => EZ_VERSION_STATUS_PENDING)

If I'm right, I just need to replace $userID with an array of the relevant user ids - that is: I need one function, searching the relevant IDs in a content class belonging to this feature.

Then I searched for 'creator_id' in the whole code finding 51 places, which I have to look at if this piece of code is relevant for such a feature. Additionally to the 'creator_ids' I need to collect the additional roles for the user - but I think this should be a thing that could be solved much more central (probably in the ezRole class...)

In the end I just need some additionaly templates in the admin interface to transfer temporary the rigths of one user to another one...

There are just some additional questions I need to test; e.g. if User B creates a new version of an object of User A: who is / should be the owner of that object?

What do you think?

Thank you and have a nice day

Thomas

Tuesday 20 April 2004 1:12:08 am

Hi,

Here we have a similar situation implemented, but only for secretaries to be able "to take over" the role of certain users. This is coupled to our specific use of hierarchies and extra attributes defined for users (not applicable for you).

There is also a "super user password" functionality which can be used to login as any user (known only to the admins of course). This is all implemented in a custom login handler, so it does not interfere with future upgrades. The idea is very simple: first compare the password used to a set of predefined passwords in a dedicated ini file (store password hashes, not the bare text passwords), if it matches, the login is granted. If not it is checked the regular way (in our case against a LDAP server). It is very useful to test roles for users.

An even better way would be to implement a "login as ... " functionality in a seperate module so you can define a new policy to enable this in certain roles. Thats more work of course.

hth

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans