On 8/17/2011 10:38 AM, Petr Vobornik wrote:
Ticket #1628 - https://fedorahosted.org/freeipa/ticket/1628
Unreported insufficient access error
This patch is dependant on
This may be only a checking if approach of this patch is good.
I was not sure if this type of error message (result.failed property) is
more general or it only appears in adding members. So I put error
handling in serial_associator instead of command. If it would be put in
command and success will be transformed to error, it will change the
behaviour of executing commands - other commands after error won't be
executed. If the approach is good, it could be probably better to change
it a little and offer same logic for batch_associator.
It should be working for adding users to groups, netgroups, roles and
assigning hbac rules (tested as non admin user).
Modified association test - data in success handler should not be
Currently with serial associator if there's a failure the rest of the
commands will not be executed, so it's an existing problem. You can test
this by adding a user into multiple groups via UI but remove one of the
groups via CLI just before adding. The user will not be added into the
remaining groups. Bulk associator doesn't have this problem because it's
executed as a single command.
I think eventually we want to convert the serial associator to use batch
commands (no need to do it now, but you can if you want). Once it's
converted, all error checking (including result.failed) should be done
in IPA.command so it can be captured by the batch handler.
I'm not sure about other scenarios that will return result.failed, but I
wouldn't assume it's limited to associations. So I think it should be
handled in a more generic way in IPA.command.
One other thing, I think we should avoid using plural class name (i.e.
IPA.errors) because suppose we have a collection of instances of this
class the variable name could become confusing (e.g. that.errorss :) ).
IPA.error_list might be better.
Endi S. Dewata
Freeipa-devel mailing list