As you say, it may be a copy paste error.

Thank you.

<% = invite Link %>

a space between % and = as well as invite Link without the space
or

<%= inviteLink%>

and this also, where between inviteLink and % a whitespace was missing. Fixed version is now at https://translate.cloudron.io/translate/cloudron/dashboard/es/?offset=1&q=inviteLinkActionText&sort_by=-priority%2Cposition&checksum=

Most likely just autocorrect of your browser or copy and paste issue, so easy to fix once I found out. But would be nice if we could make weblate catch this somehow for us.

Ejs, which is the template engine we use here, is quite picky.

[6.3.6]

• Fix broken reboot button
• app updated notification shown despite failure
• Update translation for sso login information
• Hide groups/tags/state filter in app listing for normal users
• filemanager: Ensure breadcrumbs and hash are correctly updated on folder navigation
• cloudron-setup: check if nginx/docker is already installed
• Use the addresses of all available interfaces for port 53 binding
• refresh config on appstore login
• password reset: check 2fa when enabled
• Fix crash due to wrong Spanish translation for invitation email

a small ui glitch (at least it seems so to me) I just noticed in 6.3.4. When there is the update symbol for an app on the dashboard, clicking on it always brought you directly to the update screen in the past. In fact it still does, but additionally it now opens the app in a new tab.

edit:
i moved this topic to https://forum.cloudron.io/topic/5291/problem-with-sending-and-receiving-message-s-android-windows

FYI it looks like, at least in Firefox, the update button might be inside the <a> tag for the app itself? It always opens the app in a new tab in addition to taking me to the update page.

Actually I am seeing this issue now as well, not sure why it didn't happen when I tested this yesterday. Anyways I've pushed a fix for that now.

Relevant thread spin-off: https://forum.cloudron.io/topic/5277/spam-messages-forwarding-correctly-via-forwarding-sieve-rule/1

Until those extra controls arrive (it's understandable that'll take a while), the new feature can cause some unintended consequences for some since it didn't come with the ability to at least disallow spam filtering on a mailing list. There will certainly be cases where the spam filtering should be done on the recipients end, not Cloudron's end because at least if their spam filter catches it they can still see it in their junk box, but if the mailing list on Cloudron catches it then it's gone forever, so there's a bigger risk of Cloudron doing it for some types of accounts.

I would strongly encourage that ability to disallow spam filtering on mailing lists for those who need it at least until the better spam filtering is added to Cloudron along with all the other important mail features we've been clamouring for. Right now, that feature - while useful in probably 90-95% of cases - is also now a detriment to the remaining percentage without extra controls in place.

To be fair, maybe I'm misusing mailing lists though. I used them because it was much easier to manage for accounts which need to simply forward on to a different mailing address. Maybe I always should have been using mailboxes for that use-case? So I'll admit maybe part of the issue here is more the way I'm using it, but I still stand by the fact that the feature is a bit "half baked" without the ability to disallow spam filtering on them for sensitive accounts, and I hope that will be fixed until the time that the spam features are added down the road.

spam still cannot be handled by user's sieve filters because the spam filtering is done before user sieve filters are run

Just for clarity... are you saying Spam will never forward from a mailbox either then if marked as Spam by SpamAssassin since it "cannot be handled by users sieve filters"? Or are you saying if the mailbox is set to just redirect all messages that it'll still include spam message forwarding then too?

For what it's worth, until all the spam filtering improvements appear in a future release, it may be better to focus on making that optional for mailing lists until such spam improvements are made. Spam filtering should never be forced on anyone (I've made calls for that too when discussing Spamhaus for example), there should always be a way to bypass spam filtering when needed whether mailbox or mailing list, and that option should exist for any admins.

To be fair, I just re-read my original feature request and don't think I made it obvious at all it should have been an option, so that's on me as I may have unintentionally mislead you to thinking it should be a forced setting for all. It was definitely my intention for it to be optional. Similarly, I had also noted in that very same feature request "the ability to set a threshold number to avoid false-positives" specifically because if it's marked as spam to the mailing list it's then completely lost and can't be seen later unlike a mailbox that still keeps it in the spam folder for viewing, meaning it may be necessary to set a less-rigid spam threshold (from 5 default to say 8 for example) when it comes to rejecting mail to mailing lists.

Just some food for thought anyways.

In the meantime, I've created a mailbox again (moved away from mailing list) for this particular user and hoping that all messages (including spam) are redirected to them. Sorry again Girish for possibly misleading the feature request and having an issue right away, haha, I admit it's a bit of an edge case because of the sensitivity of this particular recipient's job (a doctor) which means that all spam filtering should be on their side, not mine which is why I needed that option.