How do you handle explaining to clients how the username & email logins work in Cloudron?
-
@marcusquinn I don't think it works that way on Cloudron though because of the Cloudron configurations for multiple mailboxes to a single user. If I try to login with my Cloudron credentials in Roundcube, it fails to authenticate. It'll only work if I use my Cloudron mailbox for the username. Does it actually work for you that way? It's an interesting point though... I wonder long-term if Cloudron somehow could automatically setup Roundcube to link to each mailbox the user is an owner of, that'd be pretty useful and may take away some of the confusion, although it could create different confusion too. haha.
-
@d19dotca I just went to https://roundcube.example.com and logged in with:
- {name} and {password}
- {email} and {password}
Both worked. Both the credentials for a Mailbox on Cloudron.
Not sure if that answers or not TBH but it feels like it already works to me from a quick test.
-
@marcusquinn Interesting, that's definitely not how it works for me. Even in Cloudron's own documentation, it seems like they need to login with the email address, though it mentions "multiple domains" so maybe that's a difference between our environments. Ref: https://cloudron.io/documentation/apps/roundcube/#multi-domain-setup, and https://cloudron.io/documentation/email/#email-client-configuration suggests that it should be the email address as the username too for any client app setups. So that's very strange, haha. But hey that'd be awesome if I can get it to work with usernames instead of email addresses, that'd likely remove some of the confusion with my clients.
-
@d19dotca I might not be understanding fully, but I have a few clients for whom I anticipated this sort of challenge - managing/using a cloudron name plus email login info. So here is what I did. I made groups and assigned their cloudron username to their respective group, and then restricted app access on the cloudron to the only one they need - the SOGo installation. BUT, I never told them about this! All I gave them was the SOGo url and their email login info. But they also just have one email account, so none of them need to sign into more than one webmail account or setup more than one email client.
I was unaware of the usefulness of the User and Group options in Cloudron until I was setting up Wordpress for someone and wondered how to manage it. So rather than letting wordpress amange, I made them a Cloudron user and set that to work with their wordpress install. Then they needed another app, and I realized I could then make a Group, add them and myself, and restrict access to the apps in question, and then I could still take advantage of the Cloudron management. Without Cloudron Users and Groups I'd be busy chasing down individuals credentials over several apps! Could this be of help to you?
-
@d19dotca Just a quick note that I tried this at sogo.example.com and I could only login with the email and password, not my Cloudron username + password. But I wonder if this is because my Cloudron user has several different accounts on the Cloudron, and thus different emails, so SOGo (in my case) needs more specific login info?
-
Generally the email web clients are setup on Cloudron just like a desktop client. The login should be email+password since a username may have more than one address associated. In the past username+password worked well since there was a direct mapping to
username@domain.com
setup as an email address, but we have moved away from that long time ago.Some webmailers do support managing more email accounts within one login session, but that since support for that is not unified, this adds to the confusion for the user.
On top of that, rainloop for example would allow username+password in case that user owns the
username@domain.com
since rainloop would append the domain automatically, while the input field in the login screen actually indicates that one should enter a full email address.While some combinations currently work due to app specific quirks, the general flow should be to always user email+password for a user.
-
@nebulon Perfect, so that confirms what I suspected that it requires mailbox@domain.tld for the username when using webmail. No idea why this works for @marcusquinn but maybe that's from the older mappings you mentioned that existed a "long time ago".
Any thoughts on how I can improve users understanding of how a user account relates to mailboxes? I know we're all technical people so it seem obvious to us, but many people are not that technical and I'm trying to find a way to help those ones who are repeatedly confused by the relationship between a user account and a mailbox, when they never have to use their username for anything really since they're only ever using webmail.
Do you think there's a way Cloudron can improve this a bit? Because I liked one suggestion above which was the ability for users to login to webmail with their username instead of the mailbox, and then Roundcube for example is auto-configured to load up all the mailboxes the user currently owns.
-
@d19dotca Documentation is unclear.
With roundcube you can user the username is the email suffix is the same as the domain as the webmail.Just checked, I only use username for login.
The secret?
It only assumes the domain it's on.
If your email is me@will.com
And your mail server domain is mail.you.com
You can't login with just "me" as the username.However,
If your email is me@will.com
And roundcube is at mail.will.com
Username only auth works. -
@will Ah that's an interesting workflow. According to the Cloudron developers though, if I understand correctly, we should be using our full emails to login with, not usernames. Nebulon wrote "While some combinations currently work due to app specific quirks, the general flow should be to always user email+password for a user."
Since I'm managing over a dozen clients freelance, I think I need to stick with the "official" recommendations whenever possible just to avoid possible future issues / breaks to the workflow in the future. Although maybe this is a safe one to go a different route on. Interesting observations - until this thread I had no idea some users are logging in with their usernames for webmail. I can't even do that, but I guess that's because of the domain setup for it, perhaps.
-
If usernames could be edited, I guess you could set them all to be their email address as well?
-
@d19dotca Please note that login with email address is for web mail clients like rainloop/roundcube. Most non email client apps are using the username!
We are aware of the potential confusion, but unless upstream apps can agree on one way or the other is is hard to make that uniform. -
@nebulon Ah, interesting. So because of how the Cloudron documentation is, I've used full email address for even desktop and mobile clients. Are you saying that we should be using usernames for that instead of email address for desktop clients as a best practice?
-
@scooke Ah yes, I heavily use groups already, basically one group per freelance client/business, and all users of that business are in that group. But this unfortunately is all back-end mechanics, it doesn't change the front-end for users at all.
I probably wouldn't have this difficulty with having to explain (and repeatedly) how users/accounts related to mailboxes and such if my clients all used other apps too like signing into their Wordpress site because then they'd be actively using their user account itself and likely then understand better how it relates to their mailboxes, but many of them only use webmail because they only have a website and email and never need (nor care) to login to the website side of things. I think that's why it seems I'm one of surprisingly few people who seem to have experience this difficulty with clients with trying to get them to grasp how user accounts relate to mailboxes when they have so many mailboxes each.
-
@d19dotca You could present this as the way of the future then! Rather than it coming across as a new hassle to their established workflow (not saying that is what you are communicating), you could tell them this is the future, now, this is how things get done, that they are privileged to be using Cloudron, and since this is how Cloudron works, then they have a wonderful chance to broaden their minds and processes!
-
@scooke I don’t think that’s the issue, lol, but I appreciate the sentiment. No clients are complaining or frustrated or anything like that, so I don’t need to sell them on any platforms or ideas.
I only find myself having to repeatedly explain to them how the relationships work whenever they request a password reset for example because they forget that that same account affects other mailboxes too and that changes what they want once they remember that. So I was trying to find a way to better communicate how the relationships work so they better understand going forward, figured there must be a sort of comparison with more normal-life areas or something I could use to resemble how it works in Cloudron, but can’t figure one out yet.
Assumed others have experienced similar issues but it doesn’t seem like others really have, so it may just be a unique issue with the type of clients I have and their specific use-cases which centres around webmail only and a rotating list of employees, role changes, etc.
COVID-19 has made me more aware of their challenges because they are hiring like crazy to get through all the COVID-19 testing for the government and such as their use of webmail, onboarding new employees, needing password resets (I’ve explained how they can do this themselves but this again is confusing to them when they don’t remember how the username works (or heck what their username even is since they never have to use it) and how it impacts their existing mailboxes), and much more has all skyrocketed for the medical clinics I offer my services to.
-
I appreciate everyone trying to help Seems this may be something I need to figure out myself given the seemingly unique circumstances I’m running into. But if I find a good way to do this I’ll be sure to update this thread for others who may run into the same circumstances in the future.