one user is in vacation or sick and another user should take over his work...

Saturday 17 April 2004 2:38:03 am

Hey,

in our project we have the requirement, that - if one user (User A) is in vacation, sick, ... - there should be the possibility that another user (User B) can take over his work.

First I thougth that I only need to put User B to the same groups User A is member of (or sometihing like that - can a user be member of more then one user group like content can be published at different nodes?) Now User B has almost the same rights like User A

But that's not enough: User A is owner of some objects only he can access: perhaps he has an article, only he can update, or much more important: User A has some customers or setup some notifications in the system. I think it would be hard to give those rights to User A.

* What is possible without to much work? What is not really possible?

* Does it help to create a user group for each user, and - in times of vacation - a second user becomes member of this group, too? But I think I have the same problem with for example notifications...

* Would it be possible to simply extend eZ publish in the way that a user has not only his ID but also the IDs of one or more users. Would this be a central point in the code (user module?) to change, that User B not only has his rights but also the rights of User A, so that for example he can see his notifications and those from User A in one List, or another example he can see his collaboration objects and those of User A? Or could this only be defined in the templates' logic?

(Hard to explain in english; hope it's not to confusing :) Any idea?

Thank you and have a nice day

Thomas

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