Expected behaviour on LDAP optional fields

[alexbarcelo]

I have an LDAP which have some optional fields, like mobile and email. My settings contain something
similar to the following:

LDAP_SYNC_USER_ATTRIBUTES = {
    "uid": "username",
    "givenName": "first_name",
    "sn": "last_name",
    "mail": "email",
    "telephoneNumber": "mobile",
}

But with those settings, only the users with all the fields are created in Django, the ones without mobile are not.

I was planning to fix this behaviour, maybe send a pull request, but... what would be a nice behaviour? Silent omission? (And delegate to the user model the failure if required fields are not given) Maybe a flag like LDAP_SYNC_IGNORE_MISSING_FIELDS?

The silent omission may be the least intrusive one, but I am not sure if it fits every use case.

[PGower]

I suppose if you were using your own user model in place of the Django one then the expected (preferred?) behavior would be to use the defaults defined on the model when there is no value in LDAP. When using the builtin Django user model I would say that the best option would be to add an extra settings item that defines a dict mapping field names to values where values can either be a static value or a lambda which is passed the raw ldap record data and can return a value.

So to sum it up, if the value is missing in LDAP use the default defined on the model field, if no default then look the field up in the settings (LDAP_SYNC_USER_DEFAULT_ATTRIBUTES, LDAP_SYNC_GROUP_DEFAULT_ATTRIBUTES ?), if the value is callable then call it with the ldap data else return whatever the value is.

[alexbarcelo]

Ok, I find that approach very reasonable, indeed :)

One issue: maybe the LDAP_SYNC_USER_DEFAULT_ATTRIBUTES should have precedence over the model field's default? Given that the default attribute is explicit in the settings, I may prefer to use that instead of the "more implicit" value defined on the model. If there is no DEFAULT in the settings, use the model default --which would mean to simply skip the attribute. If the field has no default, it will fail, as expected --if we have no LDAP information about it, and have no default in the settings of ldap3-sync, then we cannot come up with any valid value.

[PGower]

Yes, you are right, that is a better way to approach it. So in order, it will be defaults defined in settings, then defaults defined in the model and then it gets left blank.