[dev] Horde Perms

[Jan Schneider]

Zitat von Gonçalo Queirós <goncalo.queiros at portugalmail.net>:

> Em 14-08-2011 08:38, Ralf Lang escreveu:
>> Am Sonntag, 14. August 2011, 04:00:42 schrieb Gonçalo Queirós:
>>> On 08/13/2011 02:44 PM, Jan Schneider wrote:
>>>> Zitat von goncalo.queiros at portugalmail.net:
>>>>> Hi there.
>>>>>
>>>>>  Started to dedicate some attention to Horde Perms, and there seems
>>>>>
>>>>> to be
>>>>>
>>>>> some odd behaviors with it:
>>>>>  - If i give to user A permission to kronolith:max_events = 2, he
>>>>>
>>>>> will be
>>>>> able to create only 2 events, but every other user won't be able to
>>>>> create
>>>>> any event.
>>>>>
>>>>>  I then give all authenticated users permission to create 5 events,
>>>>>
>>>>> and my
>>>>> user A will now be able to create 5 events too. Digging the code i
>>>>> saw that
>>>>> Horde_Perms just returns to Kronolith an array('2', '5'), and then
>>>>> Kronolith uses the max of the array.
>>>>>
>>>>>  As a user pointed on the IRC, i could add all users to a group, give
>>>>>
>>>>> that
>>>>> group permissions to create 5 events, and give user A permission to
>>>>> create
>>>>> 2. While this would probably fix the problem, it doesn't seem right
>>>>> because
>>>>> every time a user registers i would need to add him to this group.
>>>> There's nothing odd about this. Permissions are additive. You cannot
>>>> further restrict permissions that a user gained by other permissions.
>>> Sorry, but i don't understand how does it make sense. If I deny a
>>> permission to a specific user, im also obliged to allow the permission
>>> to all access users (otherwise, none will have it), and since they are
>>> additive, it actually doesn't matter what i set to the specific user.
>>> Currently you can't deny access to one user to an application, and still
>>> allow all authenticated users to access it..
>> Yes. You do not "deny" access or thresholds but "allow" it on  
>> several levels.
>> If the permission exists, it's denied by default. If not, just the other way
>> around. I think it was that way back in H3. For denial, a simple checkbox
>> would not be enough. You needed to mark if you mean "go with higher level
>> settings" or "explicitly deny". This whole thing would get messy with
>> countable permissions - You would need to indicate if a number may be
>> overriden but this doesn't work. Nobody prevents you from marking two
>> overlapping permissions as "don't override" or put users in groups they were
>> not in before and so on. You could settle with "specific overrides general"
>> but this still doesn't apply to all situations. In the end, you would mark
>> every countable permission as either "no lower than this", "no higher than
>> this" or "overridable default".
>
>> Not only storage and calculation, also the UI
>> needed to be different to allow the user overview all the implications of a
>> permissions change on any level.
> I don't think that in the current UI you can see this also. You  
> still have to know if the user belongs to any of the groups affected  
> by the permission.
>> This all can really be circumvented by just putting all good guys in a
>> "normal" group and the lesser users into a "I don't trust you guy" group and
>> assign permissions on this level instead of "all authenticated".
>>
>> Though it would be handy if there was a setting "put new users into default
>> group". Probably you could do this by a hook or through the signup form.
>>
> So, in the administrator point of view, instead of a hierarchy  
> permission system (creator > user > group > default), it actually  
> sums up to the higher permission you ever given to a user.
> This would seem acceptable, if you didn't have to move the rest of  
> the users to a generic group. Does it make sense? Affect other  
> users, because you wan't to change the permissions of one user?
> Other thing that doesn't seem right is, everytime i want to give a  
> user specific permissions i will have to check if he's in any group  
> that might give him higher permissions than those i want to specific  
> give him, and remove him from those groups.

Yes, it makes sense, because it's much more likely that you want to  
extend permissions for individual users than that you want to restrict  
them.

Jan.

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