Cloudron Forum

@nebulon said in RocketChat requires version 6.7 for app support but in back end we have Rocket.Chat 6.3.2:

Newer Cloudron versions should show when a platform update is blocked by an old Ubuntu version. We just can't update already shipped versions.

Glad to hear it. Not having that notification caused us endless trouble with Rocket.Chat over the last six months, including a couple of support requests to you. Your answers were effectively nonsense ("update rocket.chat"), as we could not update Rocket.Chat.

Thanks @nebulon for the quick answer. It does look like you are shipping a more recent version than the internal version number suggests. We'll have another go at it tomorrow to try to figure out why the Cloudron version reports an earlier version number than
CustomContentBundle-2.2.0 and
CustomContentBundle-2.3.0 allow.

@nebulon said in Automated env configuration destroys InvoiceNinja custom mail configuration on every restart:

In an ideal world, we would probably hide that UI to avoid all this, but we are not the developers of those apps and contributing upstream

This is a backwards approach. It would be completely in Cloudron's control to check the .env variables for every app. If those variables change, Cloudron should:

notify the admin user with a screen on first startup alerting the user that key variables have changed (which ones) send an email to the admin user alerting the user that key variables have been changed

I don't think local admins should have control over database settings but we should certainly be alerted if they are being changed back and forth.

It would also be very simple to allow users to enable or disable centralised email rewritten in each app. It's just one checkmark in the admin interface for the particular install.

That you have not spent the time to think about these issues and/or fix them is deeply disappointing. Your insouciance about how awful the situation is now is a deep indictment of the open source model (and this is from someone who has spent most of his adult life both creating open source and funding it).

Cloudron is sinking under too many apps and not enough care and housekeeping around the key ones you do support. I know the too-much-to-support issue first-hand. Due to WordPress making it ever more painful to keep our FOSS plugins both up to date and active in the directory (there were code change barriers, but even more administrative barriers), we had to retire about ten of them. Users can't find them or use them.

@girish does a great job running around to help us all and give us tips. It's outstanding. Systemic issues like this need to be addressed in a deeper way and not waved away with one blithe hand, or swept under the carpet.

Don't let the yes-men flatter you into complaisance. Unmerited pats-on-the-back is not how one improves a system or makes progress.

@foliovision it's in https://docs.cloudron.io/apps/#email 🙂 See the note. But to be fair, it's hard to read through all the docs in detail.

@foliovision maybe alternately, you can change the storage to file system. It's somewhere in attachment configuration under rocket.chat settings. But IMPORTANT note: I think this makes the existing attachments inaccessible. I think someone asked for a script to migrate but this is not an easy task.

@foliovision Cloudron should create the DKIM records if you're using the DO API for your domains. Cloudron does not delete existing records so if you add something in manually, rest assured it won't get wiped by Cloudron.

https://docs.cloudron.io/email/#dkim

BTW, if you go to your Cloudron dashboard --> Email --> Status --> and click on "Redo DNS Setup", that should add in the required records. It should be listed as a TXT record in DO's DNS.

Example:

TXT cloudron._domainkey "v=DKIM1; t=s; p=TIDfKL7GCS...