@mmolivier yes, I think your interpretation is correct. One quick question, why not use the sendgrid/mailgun credentials directly in your app? You don't need to go via cloudron mail server in this case, no?
A setting that would help in your specific case is to allow apps to send without MAIL FROM validation . This would avoid the whole dance around creating relay tokens cc @girish
This might be an excellent feature for the new webmail app, no?
@mmolivier I think the mail relay token does what you want. All you have to do is create a token and this give you permission to send email as whatever you want for that domain (just like mailjet/sendgrid tokens work). Fix your setup to use relay@yourdomain.com as username and the token as the password. You can then send any email as anyone@yourdomain.com .
@mmolivier so you have an app that is sending out email with arbitrary ids? can you give more info about the app or plugin ?
Cloudron 10 removed the domain level flag for security reasons. Instead, you have to either use relay tokens (under Email -> domain -> SMTP relay) or via the mailbox.
@mmolivier the flag is now at a mailbox level. Go to the mailbox -> edit -> Disable FROM validation .
Tested this now and it seems to work. Does it work with aliases on the same domain?
@umnz there is no timeline as such, I think it's just made stable when we have some user reports that it's working well.
Agreed, either the feature needs to change or the text . This change was made in Cloudron 9 - https://git.cloudron.io/platform/box/-/blob/master/CHANGES?ref_type=heads#L2959 .
I think Cloudron OIDC now exposes the avatar to apps and it's not a purely personal thing anymore since other user's will now see the avatar if the app supports it. This was the reason for the change iirc.
You mean the Lock profile option, correct? That also locks down the avatar. I think the idea of that option is that it locks down the profile so that your users don't attempt "goofy things" like setting some funny image as avatar or some funny name.
The mail relay requires STARTTLS - https://docs.cloudron.io/email/#relay-outgoing-mails . Is that enabled in Proxmox?
as in, you want the Cloudron dashboard to indicate that the app has it's own robots.txt ? That would be complicated given that an app can choose to handle paths however it wants. It's all dynamic.
The mail service seems running fine. But it seem like may be all non-http ports got blocked on your server (if you are unable to connect to SSH port and the Email ports) ? Did some new firewall deploy? Networking change?
And my question is how to make the update process automatically from Cloudron dashboard?
Do you mean you want Cloudron to track upstream releases and make new packages and have an update available? If so, there is no such feature. An idea is to automate this in your CI (Cloudron team uses renovate for it's packages).
https://github.com/plankanban/planka/releases/tag/v2.2.0
There is a discussion at https://github.com/plankanban/planka/issues/1754
⚠️ Breaking changes — read before updating
1. OIDC/SSO has been removed from PLANKA Community.
After updating, all SSO-based users are deactivated, because they no longer
have a password login.
An admin can restore access by setting a password for each affected user and
reactivating them.
If your only admin account is SSO-based, you will be locked out. Create a
new admin user first (via script or environment variables) before updating:
https://docs.planka.cloud/docs/configuration/admin-user
If SSO is critical for your team, plan this migration before you update.
Background and reasoning: #1754 · OIDC/SSO is now part of PLANKA Pro:
https://planka.app/pro
Works here. Can you check the value with the instructions at https://forum.cloudron.io/topic/2969/how-can-i-increase-the-maximum-size-of-an-email-with-the-build-in-smtp/2 . Maybe try restarting mail server? Services -> Restart ?
hi @nozy i replied from support.
Using the backup should be straightforward . https://docs.cloudron.io/backups#move-cloudron-to-another-server is the necessary docs.
The license will automatically move, yes. (it moved with the domain name during migration and is not IP based)
Feel free to ask any question here and we can help.
Same I don't see the screenshots
@nckne correct, the restore process always starts from scratch. But there is a workaround.
Once the restore has failed, ssh into the server and edit the mysql dump directly. This file is /home/yellowtent/appsdata/<appid>/mysqldump . Specifically, from the error message it seems this is around line 2047. Maybe comment out that line?
After that, using the CLI tool (on your laptop and not on the server), run cloudron import --in-place --app humhub. This does a restore of the app without redownloading the backup. So, it will reimport your modified sql dump.