Cloudron Forum

I ran into two issues with the eventlog pages (/system-eventlog and /email-eventlog).

When search results don't fill the result element enough to create a scrollbar, infinite scroll breaks. If you search for something that returns only a few results, there's no scrollbar and no way to easily trigger loading more entries. You can technically work around this by expanding detail rows until a scrollbar appears and then scroll down to trigger the process of loading the next entries.

The second issue is a pagination bug in the email-eventlog. If you've scrolled down before searching, the new search keeps the old page number instead of resetting to page 1. You end up missing earlier entries, and the reload button also doesn't fix it. Looks like this is just a simple case of a missing reset of the page value as it is there in system-eventlog but missing in email-eventlog.

As far as I can tell, this only affects the system-eventlog and email-eventlog pages, there might be other pages I missed though.

A regulation with the very German name "Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff", abbreviated as GoBD, requires comprehensive archiving of all business communications. I struggled to find good English documentation on this, but Stripe provides a very brief overview here if you're interested: https://stripe.com/en-de/resources/more/gobd-in-germany.

I've been trying to implement compliant email archiving on Cloudron, but whatever I try, I'm running into roadblocks. The main issue is that we need to archive all emails, both incoming and outgoing, especially transactional emails from apps like Invoice Ninja, which handles sending invoices, which are extremely critical in regards to the GoBD.

I know there have been previous requests for an "Always BCC" feature:
https://forum.cloudron.io/topic/4785/bcc-all-outgoing-mail
https://forum.cloudron.io/topic/8836/is-the-always-bcc-now-is-avaiable-from-haraka-now

The suggested workaround in these threads (client-side BCC rules) unfortunately won't work for compliance because:

• Users can accidentally delete or modify the rules
• Users could use the webmailer instead of their email client intermittently, mails sent there wouldn't be archived
• App-generated emails bypass user mailboxes entirely

A few months back, I tried writing a small Haraka plugin that implements a functionality like the always_bcc one from postfix for outgoing emails. I think I can handle incoming emails in a similar way. The plugin worked when I tested it manually, but there's no apparent way to integrate it with Cloudron's mail addon since any changes in the container get lost on the next restart and I then got side-tracked with other projects.

The issue now resurfaced for me and I wanted to ask if it would be possible to add support for custom Haraka plugins in the mail addon? I'm not looking for anything fancy, something like a directory mount into the container where we could place custom plugins that persist across updates would be incredibly helpful.

In combination with a working haraka plugin, this would solve our archiving compliance issue and even open up other customization possibilities for users with specific mailing requirements.

@nostrdev said in BTCpayserver:

The problem we're having is packaging two containers (NBXplorer + BTCPay Server) inside the same cloudron container. Does anyone have examples where this has been done on other apps?

Without knowing specific technical details: You could install both applications (not as containers but as binaries/from source) into a single package, then use supervisor to start both of them.

There are a lot of examples on cloudron packages with multiple services in them, these two for example:

• https://git.cloudron.io/packages/librechat-app (Librechat & Meilisearch)
• https://git.cloudron.io/packages/gitlab-app (Gitaly, nginx, puma, sidekiq & sshd)

+1

It would be really great if we could have a second configuration field in the "Branding" tab that can explicitly set the value of the CLOUDRON_OIDC_PROVIDER_NAME with a fallback to the Cloudron name. Setting the same Cloudron name for all instances that connect to an LDAP just isn't a feasible solution in my opinion and makes administration chaotic. Non-Technical Users could also really benefit from a name like "Login with One-Click" - and naming the whole instance One-Click just feels like a bad idea.

@nebulon said in Cloudron 9: UI Issues in the system and email eventlog:

Still working on the refresh, when search changes and results do not fill up the view. Overall we have to rework eventlogs (both system and mail). Currently the pagination does not work well with the fetchMore(), especially when one tries to track down an issue with a combination of search and filters. It is very hard to get context around those events, as the pagination works with the query not the time of the events

I might be misunderstanding you, but the issue happens even without using a combination of search or filters. The email-eventlog has per_page set to 10, which isn't enough to create a scrollbar on a modern monitor with the browser being maximized, so infinite scroll can basically never work when you search for anything. The system-eventlog has the same problem on larger displays despite using per_page of 40. Maybe providing the user with a button to manually trigger the loading of more items is the way to go here? Or maybe you could just load more items "per page"?

Apologies, I got hung up on your point about the 'combination of search and filters' since I'm experiencing only getting the amount of entries that's set in the per_page value even when using only the search box without any additional filters active. I'm really looking forward to the rework then because right now even basic stuff like checking if a specific email was delivered or if a specific user logged in is a bit of a pain since I have to unfold the details of the first entries just to make the scrollbar appear to load more.