@msbt I agree. In this case though there is no other way to do this unless they sign up or register themselves on the Cloudron. I suppose I could get this to work with minimal confusion. I think I'd need to set up the mailbox ahead of time too so that once they've finished their Cloudron account (with their own password) they can directly login. This also depends on them using the same username as the one I used for the mailbox.
OR I just wait until they've finished setting up their Cloudron account, see what they used for their account name, and THEN make the mailbox, hoping that in the meantime they don't try to login to SOGO, fail, and then think this all sucks. To mitigate against that I guess I could only make the SOGo app visible in their Cloudron dashboard after I've see what their username is, make the mailbox, then make SOGo visible to them, but not really mention the Cloudron dashboard again, telling them instead they can use webmail at such-and-such url.
However, they will have signed up on the Cloudron with their current email, possible making them wonder why they are getting a different email a few minutes later.
Hm, I don't think there is anyway around this other than just going with an outside email provider, like MXRoute. (The point being it is important that they have just one login to worry about - the email, and not the email AND the Cloudron ((even though they are the same)).
@msbt I'm not following you here. What is the "them" in your reply? Is it the account (the Cloudron account), or the email address made in the Cloudron?
you can link accounts to email addresses as soon as you created **them**
I need to wait for them to register with Cloudron in order to find out what their username is, because their username will be the front part of the email address of the domain. (There is one domain for this Cloudron.)
I could guess their username and and go ahead and use it to create the email and then assign their Cloudron user as MailBox Owner, BUT if the usernames differ (remember, they will now have 2 emails, the one they signed up with, and then the Cloudron email) that will be sure to invite confusion and questions.
@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 email@example.com. 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, firstname.lastname@example.org. Then, they will have two emails to think about: Their current email@example.com, and the Cloudron specific firstname.lastname@example.org
But we are stuck again. I have to use their current email, email@example.com because there won't be password yet for firstname.lastname@example.org. 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 email@example.com 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.