On su, 05 kesä 2022, Leo O via FreeIPA-users wrote:
A little breakthrough, I removed all sub-plugins except
"mailenabled".
Commented out all attributeTypes within the ldif schema, just left
mailEnabled and the objectClass, also removed all entries in the "MAY"
field except "mailenabled".
"
objectClasses: (
1.3.6.1.4.1.29426.1.2.2.1
NAME 'postfixBookMailAccount'
DESC 'Mail account used in Postfix Book'
SUP top
AUXILIARY
MUST ( mail )
MAY ( mailEnabled )
)
"
I still had the same issue "IPA Error 4001: NotFound" when trying to
create a user. I then saw the argument "update=True" on the
"add_missing_object_class". So I set "update=False" in
"mailenabled.py" on the useradd_precallback while leaving it as it is
on the usermod_precallback. (I added the "u" prefix before the
objectClass name but that's irrelevant anyway for python3, will leave
it)
"
def useradd_precallback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
add_missing_object_class(ldap, u'postfixbookmailaccount', dn, entry_attrs,
update=False)
return dn
user.user_add.register_pre_callback(useradd_precallback)
The logic here should be to add an object class to entry_attrs in
user_add's pre-callback directly. That's what 'update=False' is
effectively doing because the entry at this point does not yet exist,
pre-callback is called before entry is created in user_add.
def usermod_precallback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
add_missing_object_class(ldap, u'postfixbookmailaccount', dn)
return dn
user.user_mod.register_pre_callback(usermod_precallback)
"
I can now finally create a user without having that error message. I
will refactor the other python files and see if I can re-enable all of
them.
Please update your github repository.
There is still the issue, where the checkbox is not displaying the
stored value when entering the details view.
To answer your question from last time:
"ipa user-show"
is showing that attribute like:
"
...
Account disabled: False
Mail enabled: TRUE
...
"
A bit strange, don't know if this could cause some issues, but the
value is "TRUE" all uppercase, while the others are written as
"True".
When doing an ldapsearch, I see it also on my user as: "mailEnabled:
TRUE".
TRUE/FALSE in LDAP is correct (that's how boolean type is expected to
behave). What is probably happening is that in IPA framework we don't
properly convert to Python bool type and just return a string (TRUE or
FALSE). This is worth a bug to be opened -- I can see this with other
boolean attributes, like
Bool('idnsallowdynupdate?',
cli_name='dynamic_update',
label=_('Dynamic update'),
doc=_('Allow dynamic updates.'),
attribute=True,
default=False,
autofill=True
),
in 'ipa dnszone-show':
>>
api.Command.dnszone_show('ipa.test')['result']['idnsallowdynupdate']
['TRUE']
This is because we don't have the reverse (from LDAP to Python) mapping
for the LDAP boolean OID 1.3.6.1.4.1.1466.115.121.1.7.
When Web UI asks for the entry, it gets back JSON output that contains
this 'TRUE' value:
"idnsallowdynupdate": [
"TRUE"
],
I suspect what happens next is that JavaScript-based parser of our JSON
output is not converting it to boolean either. Instead, we work around
it this way:
{
$type: 'radio',
name: 'idnsallowdynupdate',
options: [
{ value: 'TRUE', label: '@i18n:true' },
{ value: 'FALSE', label: '@i18n:false' }
]
},
while for idnsallowsyncptr we do
{
$type: 'checkbox',
name: 'idnsallowsyncptr'
},
It is a mess. Please open a bug about boolean handling and I'll see to
fix all these places too.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland