[dev] Object_creator Permissions

[Jan Schneider]

Zitat von Michael Menge <michael.menge at zdv.uni-tuebingen.de>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael Menge <michael.menge at zdv.uni-tuebingen.de>:
>>
>>> Hi,
>>>
>>> At the moment i have some trouble with shares, see Bug #4021 and
>>> feature request #4063. I would like to help in solving this   
>>> problem. Here is
>>> my proposel how i think the share system should handle the object_creator.
>>>
>>> ---------------
>>> We have the Permissions SHOW, READ, EDIT, DELETE and CREATE
>>>
>>> If object_creator has the SHOW permission a user should only see a share if
>>> there are objects in the share he owns.
>>
>> No, shares don't know about their objects.
> I think here lies the Problem i reported in the Bug #4021. Every user
> can see every share that has object_creator SHOW permission set.
> Seeing thounsend of shares they can't use and they should not see is
> very confusing for the users.

Then don't set SHOW permissions.

>>> In this case the user should only see objects he owns.
>>
>> This is how it works today.
>>
>>> How the user could create the object is not the matter at this place
>>>
>>> If object_creator has the READ permission a user should only be   
>>> able to READ
>>> the objects he owns. Same for EDIT and DELETE
>>
>> Should be the case already.
>
> Yes, some things work already in the way i would ecxpect them to work.
> But at the moment it is possible for everyone to create Objects in
> shares if the EDIT permission is set for the Object creator.

On purpose, see my comments in the ticket.

> But if the EDIT permission is not set for the objectreator but other
> permission (i.e. READ and DELETE) are set and the EDIT permission is
> set for the user then he can edit all but his own Objects in the share.

Huh? I lost you here.

>>> If object_creator has the CREATE permission and the user owns an   
>>> object that
>>> is a share itself the user would be able to create entries in the subshare,
>>> but not to create other objects in the share itself. To create a new
>>> object in a
>>> share the user must have CREATE permission set for him or for a group he is
>>> in.
>>
>> Huh? I think you confuse shares and objects here.
>>
>
> I have read that Shares can have objects that are subshares. At the
> moment i don't know a module that uses this feature.

No, there are no subshares. And there are no permissions on the object level.

> If we have only normal objects in a share the CREATE permission for
> the objectcreator would be useless. But if subshares (objects that are
> shares themselfe) are allowd, this permission could be used to allow
> me to create new objects in that subshare.
>
> But this could also be solved by setting the permissions for that
> subshare. So maybe we should not use the CREATE permission for object
> creator.
>
>
>>> Maybe we need a way for the owner of the share to change ownership  
>>>  of object
>>> in his share.
>>
>> This is already possible with event delegation in Kronolith.
>>
>>> At the moment it is not tested if there are objects in a share that
>>> are created by the user so every user has the right to see a share and
>>> to add new objects in a share if the object_creator has SHOW or EDIT
>>> permission
>>
>> Yes, and that's how it is supposed to work. Share permissions have
>> nothing to do with the objects in the share, only objects are affected
>> by the share permissions.
>>
>
> I understand that objects and shares are stored in different ways and
> that only objects are affected by the share permissions, but I dont
> want that everyone can see that there is a share "blafasel" or "I hate
> my boss".

Then don't set the permissions. If you don't want the user to see  
these share, you probably don't want them to create objects in them  
either.

> Group permissions are only evaluated for Groups I am member of (which
> is correct). Why dont we implement a funktion that shows the shares
> the user has objects in and evauate the object_creator permissions
> only for these shares.

Because 1) this is technically not possible, 2) this would be a huge  
performance hog, 3) this is not the purpose of the creator permissions.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/