On Wed, Mar 06, 2013 at 02:05:38PM +0100, Martin Kosek wrote:
> On 03/06/2013 01:42 PM, Petr Vobornik wrote:
> > On 03/02/2013 08:40 PM, Endi Sukma Dewata wrote:
> >> ----- Original Message -----
> >>> First two patches are bug fixes which are required for third patch.
> >>> Depends on my patch #259 (Combobox keyboard support)
> >>>
> >>> 1) [PATCH] Fix dirty state update of editable combobox
> >>>
> >>> Editable combobox didn't update it's dirty state correctly. CB had
> >>> it's own internal value changed event, which was incorrectly used. It was
> >>> removed and widget's value_changed event was used instead.
> >>
> >> ACK.
> > 
> > Pushed to master
> >>
> >>> 2) [PATCH] Fix handling of no_update flag in Web UI
> >>>
> >>> There was an incorrect check for no_update flag. Check was performed
> >>> as if the flag was an attribute of object not an item of array. Hence,
> >>> the flag never caused any effect.
> >>
> >> ACK.
> > 
> > Pushed to master
> >>
> >>> 3) [PATCH] Global trust config page
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/3333
> >>
> >>> Just two notes:
> >>>
> >>> ipantfallbackprimarygroup requires a posix group. Our API currently
> >>> doesn't support search based on object classes therefore the entity
> >>> select widget incorrectly offers non posix groups as well.
> >>
> >> Are we planning to add the missing functionality? Right now you'll get
> >> 'group not found' if you select a non-POSIX group, which is confusing
> >> because the group does exist. Possible solutions:
> > 
> > 
> > Waiting for "[RFE] Add option for filtering groups by type (posix,..) in
> > group-find command" to be implemented to solve issue.
> > 
> >>
> >> 1. Fix the error message to say '<group name> is not a POSIX group' or
> >> 'Fallback primary group requires a POSIX group'.
> >>
> >> 2. Execute another batch of group-show operations to get the object
> >> classes of the groups to be displayed and filter out the non-POSIX groups.
> >>
> >>> Another problem is that hidden 'Default SMB Group' is not listed.
> >>> Hence it couldn't be set again after a modification. I made the combobox
> >>> editable (first usage, so it revealed a bug) to avoid this problem.
> >>> User can enter garbage, but the framework should handle that.
> >>
> >> This is a little difficult to use. You'll need to know that you have to
> >> type 'Default SMB Group' to go back to the default and the UI doesn't
> >> show that as an acceptable value. Possible solutions:
> >>
> >> 1. Add the 'Default SMB Group' as the first entry in the drop down list
> >> so you can reselect it again. The drop down list doesn't need to be
> >> editable.
> >>
> >> 2. Use radio buttons to separate the default value from other values:
> >>
> >>    Fallback primary group: (o) Default SMB Group
> >>                            ( ) POSIX group: [ drop down list ]
> >>
> >> Regardless, I think the server API needs to be changed to accept an
> >> empty value to go back to the default value instead of taking 'Default
> >> SMB Group'. A default value should be simple and not something that will
> >> potentially conflict with a non-default value that happens to have the
> >> same name.
> > 
> > I agree. Martin is it feasible?
> 
> I do not think this is something we want to have fixed FreeIPA API side, when
> you set some field/attribute to None, it is just set to None, i.e. removed 
> from
> LDAP. No default value kicks in.
> 
> If you would that to work, we would first have to update ipa-sam plugin to
> understand missing Fallback primary group as "use the default". If I read the
> code right, it currently just fails the operation.
> 
> Sumit, do you think it would we feasible to change the ipa-sam operation this
> way? I.e. when fallback primary group DN is not present, use the value
> hardcoded in ipa-sam. It may have been thought about originally as
> ipaNTFallbackPrimaruyGroup attributeType is a MAY and not a MUST on the
> objectClass.

In general yes, if this attribute is not set ipa_sam can search for a
group with 'cn=Default SMB Group' (which is created during
ipa-adtrust-install) and use this group. I'm just wondering what would
be the fallback if a smart admin has deleted this group as well.

Simo, Alexander, should we fallback to the well-known RID 513 for 'Domain
Users' in this rare edge case, jsut to make sure that there always is a
RID which can be used?

bye,
Sumit
> 
> Martin

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to