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...
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 "webmaster(a)yourdomain.com" 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.