Cloudron Forum

Hello @milohiss @milohiss said: Are maintenance emails sent only when a notice is first created? Can its dashboard timestamp change without another email being sent? Yes to both, and that is exactly what you are seeing. Email fires when the notification is first created, or when an already-acknowledged notice is re-raised. An unacknowledged notice that keeps re-pinning gets its creationTime bumped every run and the dashboard renders that field and sorts by it, so it looks brand-new at the top of the bell while no mail is generated. The August email was the original send, nothing has been "missed" since, by design. @milohiss said: What read-only diagnostic can distinguish expected suppression of repeat notifications from a failure to generate or send the email? In the box.log you could find lines like: mailer: Email "..." sent to ... for a successful send Error sending Email ... for a real failure notifications: add: <type> <title> for a notification being added logged only on insert not on update @milohiss said: All available email notification categories are now enabled. Does this cover every new bell notification? If not, which are dashboard-only? They cover every notification that can produce an email. But several bell notices have no mailer and are dashboard-only and these are: cloudronInstalled, cloudronUpdated, ubuntuUpdate (for EOL warnings like Ubuntu 20), mailStatus (Email configuration error), domainConfigCheckFailed, appUpdateCheckFailed Maybe this is something we could improve. @milohiss said: Is there a supported way to receive email reminders for unresolved urgent notices? Currently, there is no reminder/re-nag timer. The one supported lever is the acknowledge transition: dismiss the notice in the bell, and the next check (≤24h for reboot, ≤4h for updates) re-raises it and sends a fresh email.

Yes, we used to have this, and I think/ hope they'll be back (along with other improvements) in the next release, see this thread https://forum.cloudron.io/post/117521

Oh no, sorry about that regression and thanks for reporting again! This is fixed then for next release with https://git.cloudron.io/platform/box/-/commit/8a65d11fd176d54f868c2b0067087c4ed07e0a24

@girish IMO, the version information wouldn't matter for a notification email. I'd just like to know when a manual updates required

most likely 9.1 as we are done with 9.0 patch releases

@girish said: The messages are fixed now Does that include colours coming back too?

@scooke I have it as a "backup" browser. By that, I mean I use it when I need a fresh browser since I pin/keep open tabs from previous sessions.

This should be fixed in Cloudron 9, where a backup failure notification email can be configured per user.

Thanks! Can't wait to see the light

Hi @James - Many thanks for this. The changes already looks great and promising. May I make a suggestion ? I think, in this case, Freescout approach offers a greater granularity between email notification and in-app notification, with potential for further development based on the communication channel (Mobile if ever, API ? etc..), leaving the end admin users decide what works best for them Here is the screen I am referring to in Freescout. [image: 64145699-7f368480-ce22-11e9-9ead-1ac3ef29ba9b.png] If it is not too late in the development of this, maybe it might be worth considering?

@d19dotca said in Shouldn't we get an alert when a service container fails / is unhealthy?: checking so that it ignores any entries of the current Docker networking ranges such as 172.18.xxx.xxx addresses For the moment, I have added validation to not accept such addresses . Ignoring this properly is more complicated (since we have to filter it at apply time) but atleast it won't let you save the blocklist easily .

@SansGuidon I think your approach is the best as of right now. We will have to add automatic restart built into Cloudron at some point.

@joseph said in Frequent Email is not configured properly notice: Maybe DNS is periodically failing on your servers. Do you know which DNS servers your server is using? You can use resolvectl to figure this. Thanks for the explanation! my DNS servers are : Current DNS Server: 1.1.1.1 DNS Servers: 1.1.1.1 9.9.9.9

We are reworking the notification UI for Cloudron 9 at the moment and the reboot required hint will be fixed accordingly there. It has caused quite a few misunderstandings in the past as it currently is

"Thank's" is like.... [image: image.png]

In case anyone needs it, I added support to dismiss the notification. After the if node, assuming true, add another connection, a 'Loop over items' node, with a batch size of 1. Connect the node's "loop" connection to a new function node with this code. // Access the input JSON data const item = $json; // Ensure the structure is correct and 'filteredID' exists if (item.filteredID && Array.isArray(item.filteredID) && item.filteredID.length > 0) { const notificationId = item.filteredID[0]; // Extract the first ID // Return the data for the HTTP Request node return { json: { notificationId: notificationId, acknowledged: true } }; } else { throw new Error("Invalid JSON structure or 'filteredID' not found."); } Then, connect the function node to a new HTTP request node with the method of 'POST', URL of "https://my.cloudron.site/api/v1/notifications/{{ $json.notificationId }}" (As an expression), same authorization header as the first HTTP request nodes, with the (JSON) body of: { "acknowledged": true } I'm pretty sure this process can be written better, but this approach was quick and dirty. I've also adjusted the notifications to be sent via email rather than using NFTY, but that's a pretty straightforward step. [image: 0338dc53-6d5a-4d2b-9071-5849f552439b-image.png]

@girish Ah okay... Thanks.

Yes this is done.