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

Author Message

Thomas Nunninger

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

Gunnstein Lye

Monday 19 April 2004 7:46:02 am

A user can be placed in as many groups as you want. He/she will get all the roles assigned to all the groups.

If you have role policies based on object ownership, then it will be very hard to transfer the rights. A user group for each user would help, but will be much work to maintain if you have many users. Also, you would have to change your roles to not use object ownership as access criteria.

Changing eZ publish so that a user "has" the user ID of several users would be a lot of work, and very dangerous in terms of security. Allowing user A to view user B's notification and collaboration items would also be very hard.

The easiest solution in this case is to give B's password to A when B is away.

Thomas Nunninger

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

Gunnstein Lye

Tuesday 20 April 2004 12:28:15 am

I know that giving away the password is not ideal, but it is safer than the alternative. Remember, if you do these changes, then it may get very difficult to upgrade eZ publish later. Also, you may get security and stability problems. It depends on how much work you are willing to do to achieve what you want, of course. Anyway, good luck.

AFAIK, owner/creator id is set on creation of an object, and is never changed.

Paul Borgermans

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

Thomas Nunninger

Tuesday 20 April 2004 1:26:03 am

Hey Paul, hey Gunnstein,

thank you for your ideas.

When we where discussing the solutions we found the problem of upgrading to. Because of that we decided not to do this.

Paul, your idea is good. We also thought about a similar way: changing the user object of the current session. This means: you log in with your own password and then you have the possibility to switch in the other user's identity. Both ways would be a more central solution than our first idea.

Thank you and have a nice day

Thomas

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.