Feature Request
Allows admins to optionally configure aliases for provisioned accounts. Since LDAP is already a popular choice for a user back-end of Nextcloud, we can build this feature around LDAP. The admins will have to enter the attribute name and we use \OCP\LDAP\ILDAPProvider::getUserAttribute to fetch the alias email address.
If LDAP isn't available (\OCP\LDAP\ILDAPProviderFactory::isAvailable) then we should hide this setting from the admin.
The attribute could be multivalued if more than one alias is set. We have to check if/how \OCP\LDAP\ILDAPProvider::getUserAttribute supports this because it currently always returns a string. Taking a quick look at the implementation tells me only the first result will be returned if the value is an array. This means we might have to change the server API to allow multiple values, e.g. in a getUserAttributes or getUserMultiAttribute
Summary
Provision aliases based on LDAP attributes.
Feature Request
Allows admins to optionally configure aliases for provisioned accounts. Since LDAP is already a popular choice for a user back-end of Nextcloud, we can build this feature around LDAP. The admins will have to enter the attribute name and we use
\OCP\LDAP\ILDAPProvider::getUserAttributeto fetch the alias email address.If LDAP isn't available (
\OCP\LDAP\ILDAPProviderFactory::isAvailable) then we should hide this setting from the admin.The attribute could be multivalued if more than one alias is set. We have to check if/how
\OCP\LDAP\ILDAPProvider::getUserAttributesupports this because it currently always returns a string. Taking a quick look at the implementation tells me only the first result will be returned if the value is an array. This means we might have to change the server API to allow multiple values, e.g. in agetUserAttributesorgetUserMultiAttributeSummary
Provision aliases based on LDAP attributes.