> E.g. it forces to use a radio-box. The fixes from PR 6294 would be needed to > use plain 'checkbox' type.
okay, I will leave it for now as checkbox, as the underlying ldap structure is more important to me atm than the UI. > You only need one class to allow an attribute. If you want to add either > Account or Forward, it would probably be driven by a > different logic -- e.g. whether the user entry would be a primary one or only > a mail forward. I cannot help here -- it is pretty > much your plugin's logic what to use here. Hm, I don't know, to be honest. It is not obvious to me what that actually means, what the consequences are. So I can't do any logic decisions here. I mean the ldap schema is not something I created. It's a common postfix-book schema. The only modifications I made was to lowercase the first letters of the objectClasses (just that the naming style matches the other entries, shouldn't have any effect anyways) and commented out "mailQuota" and "mailForwardingAddress" attributeTypes as they exist already. I think I will remove the second "add_missing_object_class(ldap, u'postfixbookmailforward', dn)" completely from "mailalias.py". Somehow it doesn't feel correct. > Use lambda or a function for a default_from attribute of the parameter. Lambda it is. It's enough for me, plus discovered these handy function like "lower()" and the object "api.env.realm". Tested this pretty nice function and it works as expected: "default_from=lambda givenname, sn: '%s.%s@%s' % (givenname.lower(), sn.lower(), api.env.realm.lower())," The unique attribute is something which causes some headache. I saw it also in here: https://directory.fedoraproject.org/docs/389ds/howto/howto-uid-uniqueness.html 1. Still don't know how to implement it, would I create it inside my plugins schema? But I can't just adapt the entries and throw them into the ldif file, can I? (commented out a few lines, unsure about the "default:" prefix in each line) dn: cn=mailalias uniqueness,cn=plugins,cn=config default:objectClass: top default:objectClass: nsSlapdPlugin default:objectClass: extensibleObject default:cn: mailalias uniqueness default:nsslapd-pluginPath: libattr-unique-plugin default:nsslapd-pluginInitfunc: NSUniqueAttr_Init default:nsslapd-pluginType: preoperation default:nsslapd-pluginEnabled: on default:uniqueness-attribute-name: mailalias default:uniqueness-subtrees: $SUFFIX default:uniqueness-exclude-subtrees: cn=compat,$SUFFIX default:uniqueness-exclude-subtrees: cn=staged users,cn=accounts,cn=provisioning,$SUFFIX default:uniqueness-across-all-subtrees: on default:nsslapd-plugin-depends-on-type: database #default:uniqueness-subtree-entries-oc: posixAccount #default:nsslapd-pluginId: NSUniqueAttr #default:nsslapd-pluginVersion: 1.1.0 #default:nsslapd-pluginVendor: Fedora Project #default:nsslapd-pluginDescription: Enforce unique attribute values --------------------------------------------------------------------------------- But then a few questions came to my mind. 2. I'm using the lambda value to generate a mailAlias out of first name and last name. If I now create such a unique constraint, it would throw an error when creating a user with the same first name, last name, so it would't be possible to create a user at all. 2.a: I would have to either remove the default_value lambda mailAlias, make it optional. Which is not possible because then I get the error again: "missing attribute "mailAlias" required by object class "postfixBookMailForward"" Or 2.b: I don't use the unique constraint and therefore pushing the responsibility to a human person/ the admin to take care that the mail aliases stay unique. which brings me to 2.c: IIRC general emails like "[email protected]" are used and put on multiple user accounts, if I'm not mistaken. Please correct me if I'm wrong. That would mean, I definitely should not use such a unique constraint on mail alias. Puhhh, pure logical issues for that one, I still would like to hear your opinion about that. I tend to go with 2.b and let the admin create users (In case a user with the same first- and last name already exists, add a suffix to the generated mail alias). As this is a real edge case (especially if you plan to use that for 0 - 20 users), no need to create complex mail alias generating functions. Means, the current implementation is done and can be used. _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
