[Freeipa-devel] [PATCH] 005 Show error in serial association

Endi Sukma Dewata edewata at redhat.com
Thu Aug 18 16:25:58 UTC 2011


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
> freeipa-pvoborni-0004-1-error-dialog-for-batch-command.patch.
>
> 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
> undefined.

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




More information about the Freeipa-devel mailing list