user_external
user_external copied to clipboard
Automatically set user email and display name
When using External User Backend with IMAP the display name is set as the email address and the user's email is not set. Can we add the ability to set the display name as the name before the @ in the email address and the user's email address automatically setup?
Yes, this would be possible! The email can be set automatically if the IMAP backend is used. For the display name I'm not that sure. This could be confusing if there are users on different domains with the same "first part of the mail". On the other hand if manually set, users can have the same display name as well. PR is welcome!
related to #10
@violoncelloCH Can you point out where to start? Which file to edit.
hi @benkees sorry for the late answer (have been busy myself)... the relevant files in user_external to edit would be the /lib/base.php (specifically those two functions: https://github.com/nextcloud/user_external/blob/f5629eb367113909556d74ee433e5158f498ab9f/lib/base.php#L146-L194) and the /lib/imap.php (check out this call specifically where the user is created: https://github.com/nextcloud/user_external/blob/f5629eb367113909556d74ee433e5158f498ab9f/lib/imap.php#L106)
for reference in nextcloud/server especially this function in the IUser interface seems to be relevant: https://github.com/nextcloud/server/blob/906348ca145058c68f66237de487436575570a44/lib/public/IUser.php#L188-L195 as well as this interface here: https://github.com/nextcloud/server/blob/master/lib/public/User/Backend/ISetDisplayNameBackend.php
don't hesitate to ask further questions :) (I hope I'll manage to answer them faster now as I've a little more spare time the coming weeks)
sorry, didn't mean to close it :upside_down_face:
If 'stripeDomain' is FALSE, we can set the email in lib/imap.php pretty simply:
--- user_external/lib/imap.php 2020-11-08 14:19:02.524859391 -0500
+++ ./imap.php 2020-11-08 14:16:48.550661342 -0500
@@ -103,6 +103,13 @@
curl_close($ch);
$uid = mb_strtolower($uid);
$this->storeUser($uid, $groups);
+ if ( ! $this->stripeDomain) {
+ /**
+ * Set the IMAP user's email to their login
+ */
+ $config = \OC::$server->getConfig();
+ $config->setUserValue( $uid, 'settings', 'email', $uid);
+ }
return $uid;
} else {
OC::$server->getLogger()->error(
However, a "full" implementation would support the situation where 'stripeDomain' is TRUE, or the situation where the email address is different than the authenticating domain - which I see either requiring new configuration options or making assumptions that might be wrong for some users.
private $mailbox;
private $port;
private $sslmode;
private $domain;
private $stripeDomain;
private $groupDomain;
private $storeEmail;
private $emailDomain;
With apologies for the pseudo-code -
-
(do we need to do this?) If we want an admin to be able to specify an email domain that is different from the authentication domain -
- set $myemail to $pieces[0] . '@' . $emailDomain (if $emailDomain is not empty)
- set $myemail to $pieces[0] . '@' . $domain (if $domain is not empty)
- otherwise, set $myemail to '$uid' if $uid contains an '@' sign
-
If we're willing to cause problems for people who want the email domain to be different than the authentication domain:
- if $uid as entered contains an '@', save it to '$myemail' before splitting $uid into pieces
- if $uid as entered does not contain '@', but '$domain' is set, set $myemail to $uid . '@' . $domain
-
Finally, add these lines after 'storeUser' to save the email address
- We could decide that $storeEmail is TRUE unless the admin specifically adds it as FALSE
if ( $storeEmail) {
$config = \OC::$server->getConfig();
$config->setUserValue( $uid, 'settings', 'email', $myemail);
}
I'm happy to test out solutions to this issue, as it fits a local use case.
Can we produce a PR from the snippets given here, and iterate from there?
fine with me, @almereyda
Would that feature work together with the Nextcloud Mail app so that new user e.g. automatically get access to their E-Mails?
@almereyda any updates?
As far as I can see there is currently no PR associated to this issue.