@scooke you can even give your users a predefined username. what you could do: add the users without sending them an invitation, add the emailadresses and link them to their accounts, then hand out the link to your cloudron where they can (re)set their password which will then be used for sogo login. If that's not an option, then I'm out of ideas
About the "them": you can add emailadresses and link them to cloudron accounts, regardless if those accounts are active or not.
@scooke if I understand you correctly, the main issue of not setting up a Cloudron account for each user, is the need to use two email addresses then. So since you seem to setup their accounts anyways, you might as well just create them with the same email address and not send out the invite automatically (there is a checkbox on user creation for this). Then you can send them the invite link through other means. This should make sure the email addresses match. You can also set the fallback email to some non-cloudron email for password reset mails.
@nebulon Possibly. Let me try explaining again.
I have set up a cloudron on example.com. I have 5 users who will be using new email addresses like firstname.lastname@example.org. But I have not made those email addresses yet in Cloudron. I in fact did try that, but then realized that the users will need a password to actually use the email address, whether through SOGo or an email client. This led me to realize that the only way for them to have access to the new email address is to also make a User on Cloudron. But, I would like to avoid them interacting with Cloudron more than they need to mainly due to "complication" of them having to deal with two things - their email and this Cloudron thing. But also, if I have them set up their Cloudron account first they will use their current email, email@example.com. Then, they will have two emails to think about: Their current firstname.lastname@example.org, and the Cloudron specific email@example.com
But we are stuck again. I have to use their current email, firstname.lastname@example.org because there won't be password yet for email@example.com. I could set it all up as I detailed above, but in order for them to reset their passwords I would have to user the firstname.lastname@example.org address as the secondary address (in the User info). Then they could, if ever needed, reset their password, and even though it would go to their previous email address (which unfortunately might have been cancelled after some time), they would almost certainly end up interacting with the Cloudron dashboard, wondering what it is.
I don't see anyway around this. I either set it all up for them, including their passwords (and then of course delete these from my records), or I may as well get them to go straight to the User registration and deal with whatever issues and questions they will have about the two/three systems (email/SOGo and Cloudron).
@scooke I really think you're making it yourself a little bit too complicated
I manage 4 Cloudron's Premium, of which 3 are for 3 different foundations working with volunteers (average age 65+)
This is my workflow:
- create an account with username: firstname.lastname and with an email address I know. BUT: don't send invitation link! Make it member of the usergroup "webmail" and make sure the "webmail"-app is accessible by that group and the rest of the apps NOT
- create an email account with same name firstname.lastname and the owner is the user in step 1
- go back to the user and change the Primary email into the just created email address in step 2
- copy the invite link and use it in a self composed email
What I do explain to the users:
- "your account for my.domainname.tld is to make use of our fantastic platform and to manage you password"
- "logging in to my.domainname.tld shows you a personal dashboard with all the apps you need"
- "click on My Webmail and log in with your username firstname.lastname and you self created password" (I rename all the LDAP apps to start with My and explain that every such app is accessible with same credentials.
@imc67 I really appreciate the time you took to explain your process. Believe it or not, this is exactly what I've been aiming to do. BUT, there is still a question that remains unclear in the process:
When is the password created?
Your Step 4
use it in a self composed email... you send this to yourself, and you set the password?
When you explain it to your users, you must be sending the email to another email address of theirs. This is one hurdle I was hoping to avoid, but it seems not. And then when they go to the fantastic platform to manage their password it sounds like they are (re)setting their password, and not in fact you in Step 4.
I like the way you explain the Cloudron Dashboard.
So, if you monitor their access at all, do they all continue to access their webmail by logging into the Cloudron, and then clicking on the webmail icon? Or do they go straight to the webmail url after some time?
and you set the password?
No, I just send them the copied unique password reset-link from the user GUI in Cloudron in my own composed email, they set their password by themselves, I don't want to know that.
Indeed every user has as primary email the domain, but for password reset everyone has a "personal/external" email address, otherwise they won't be able to receive the password reset email if they've forgot it. The same is for you "welcome" email, you have to send it to their current.
Some of the users are smart and recognize the URL of webmail and go there straight ahead. But I do want them to be aware of the Dashboard because we may rollout new apps for them.
@eddowding So, you would prefer a unified view instead of selecting the domain first? In any case, would be great if you can create a separate topic with your suggestion since this topic was about cloudron user+mailboxes initially. Would be good to hear!
@girish There were two topics, both related to the create user / email flow.
As @imc67 outlined on 1st Feb, it takes 7 steps in 3 parts to create an email address for a user. I hope we could all agree that that's too complicated.
I could perhaps have reported the data privacy flaw separately. However as a paid user I really hate it when companies I pay for a service make ME do their error reporting work.
For some reason I am still not fully following what this is about, especially the "data privacy flaw" is very much unclear. For the mailbox creation, are there any suggestions on how to improve the flow? Is this mostly about that a Cloudron user has to exist, who owns the mailbox?
the "data privacy flaw" is very much unclear.
I think that's just this:
Also even if app access is restricted, if a user goes to Dropdown > Email, they can see all the hosted domains.
@jdaviescoates is this because that user has the role of User and Email Manager? Is this so Cloudron used like a shared hosting environment of sorts?
I've no idea. @eddowding ?