Cloudron Forum

Zulip update: https://chat.zulip.org/#narrow/channel/31-production-help/topic/zulip.20for.20cloudron/near/2425677 (and following messages)

Hi folks,

We have a cloudron instance with a lot of users. We use email and we use groups.
We have mailboxes owned by groups.
Lets call an example group "foo", with user members "user1", "user2", and "user3".
There is a mailbox where the owner is the "foo", called foo@example.com

We want email sent to foo@example.com to get forwarded to the personal email accounts of user1, user2, and user3.

Currently, we need to go into the mailbox and manually set up the email forwarding.

If a new user is added to foo, we have to manually go into the mailbox and add them to the forwarding list.
If a user within foo updates the email address associated with their cloudron account, we need to go and manually change their address within the mailbox.

It feels like we're doing something wrong, and that there should be a smarter way to link the email addresses in cloudron, the groups in cloudron, and the mailboxes.

Any suggestions?

Otherwise, feature request?

@james said:

Correct me if I am wrong but, I have this feeling that you are using group owned mailboxes to solve a need for something that should be handled by a mailing / ticketing system like @freescout or @chatwoot.
Using such an application would resolve almost all the points you have brought up.

Hmm, that's an interesting point. You may well be right. I'll have a think about whether that might work for us. My initial reaction is that it wouldn't go down well because unless the email integration was simple and rock solid we'd need to ask users to get to know a new tool. And currently the work of updating email lists is a hidden admin chore, and so there's not much argument for changing things from the user perspective.

One of the groups was using Freescout until recently, but moved away from it because they couldn't get it to send emails reliably. They've now transitioned to using the kanban board feature of NextCloud (Deck) instead.

When one signs up on this forum, you check a box saying that you consent to email notifications.

The default notification settings do not have email notifications enabled.

It was my assumption that I would receive email notifications when someone replied to a post I had made. I therefore didn't think to manually check whether someone had replied, which led to a considerable delay in me finding a solution to an issue I was facing.

I would propose changing the email notification defaults for new users of this forum.

We're seeing this error at toolkit.radicalroutes.org.uk, e.g. at
https://toolkit.radicalroutes.org.uk/index.php?title=Different_types_of_housing_co-ops&action=edit

I'm fairly new to this so hopefully it's something simple that we're missing or that I'm misunderstanding. Any help appreciated. Thanks!

Resolved before this post was approved!
I needed to update JsonConfig - prev: 1.1.1 (01a703e), now: 1.2.0 (f3e7ec2)

Hey folks, can I get an invite to git.cloudron.io please? (dannygarside@proton.me)
It looks like there's no way to manually sign up, and @girish said to ask here.

I just want to fix a couple of broken links in the docs.

FWIW I'd prefer a manual sign-up process or federated SSO with gitlab.com (or other SSO?).

Just to come back to the previously suggested solutions -

1. Would it be a big feature request to add group name parsing into the mailing list input box? E.g. instead of (or in addition to) a list of email addresses it could take something like "group:foo" and then this would dynamically pull in the email addresses of all users in group foo as needed.

2. Is there a way that cloudron user group info could be pulled in @roundcube (or another mail system), so that instead of setting up forwarding rules that go to a list of emails it could go to "group:foo".

3. Is there a way that we could run a cron job (or similar) which could hackily create either of the above functionalities by generating and inserting the lists (rather than these lists being dynamically generated), with the downside that this would only ever be as up-to-date as the frequency with which the cron job runs.