Cloudron Forum

I figured it out now, see below.

At apptask.js:693, updateCommand calls omit() on the old manifest's addons field without guarding against it being absent. When the installed manifest has no addons
key, addons is undefined, causing Object.entries(undefined) to throw:

TypeError: Cannot convert undefined or null to object
at Object.entries (<anonymous>)
at Object.omit (file:///home/yellowtent/box/src/underscore.js:17:38)
at updateCommand (file:///home/yellowtent/box/src/apptask.js:693:28)

Because this is a plain TypeError rather than a BoxError, the catch block in run passes it to makeTaskError, which asserts error instanceof BoxError and crashes —
surfacing a secondary assertion error to the user instead of the real one.

To reproduce:

1. Install an app whose CloudronManifest.json has no addons field
2. Add "addons": {} to the manifest and push a new image
3. Trigger an update from the dashboard

Expected: Update succeeds, or fails with a descriptive error about the manifest change.
Actual: Task crashes immediately with AssertionError: assert(error instanceof BoxError), hiding the real cause.

I re-installed the app, which solved the issue. I still believe the views should be consistent in error handling though.

Yes, I have a few of them. But I think the right behaviour should be that Cloudron flags that in the UI, perhaps even with an icon, so I'll know which app that concerns. And I still find it odd that the grid works, but the list doesn't.

I am having an issue with Cloudron version 9.2.0. In the app overview, the app list appears empty, but the app grid works.
Can this browser console error be related?

TypeError: can't access property "email", app.manifest.addons is undefined

It would be odd, though, that this crashes only the app list, but not the grid.

Can you check the logs for any error? Regarding the e-mail, the issue could be a wrong email setup.
Have you installed it as a Cloudron community app?

Hi, thank you for the suggestion!
Regarding customising availability, I'll note this for the nearest future. Regarding localisation, do you want to get e-mails translated? The booking experience is already supposed to be international for the user booking (with EN/DE/FR/IT/UK supported), but you can't change the text. Would you like to change the text, are you looking for a new language or would you like to see the whole app localised? The latter will happen, but not yet.

As an alternative, I suggest customisable groups. I have about 30 apps, but only one long list.
If Cloudron offered groups that I could customise by certain factors, the original problem would be resolved, but there would be much gained for other use cases as well!

@sponch said:

@ekevu123 Hi. Caldav via SoGo and mailbox.org
The calendars do appear when I enter my login credentials, but the appointments aren't syncing. at least with one account - the other only sync partially.
"Some calendars have never been synced" - refreh doenst help.

Okay, I got it, the next update will support mailbox.org as well, but this might require 2-3 days to implement!
From what I am seeing, you would want to create an app-specific password in mailbox.org, though, as Sogo acts as another frontend, but correct me if I am wrong here.

@sponch So far, Sogo and mailbox.org aren't officially supported, and some Caldav providers handle things differently.

I'll create accounts and see if I can test it and see what happens!

@james said:

Hello @ekevu123
If you'd like some examples for how we do that, you could check out the start.sh of the mirotalk app or the start.sh form the Kutt URL shortener app to just name two examples.

---

One small note on that topic.
When merging env files together like we sometimes do, ensure that a newline is present otherwise it could end up appended to the last string.
See: https://git.cloudron.io/packages/twenty-app/-/merge_requests/6/diffs

Without the linked diff, if a new line in /app/data/env is missing the string gets appended.
So if your last line in /app/data/env is STORAGE_LOCAL_PATH=/app/data/local-storage and it gets appended to /run/twenty-server/.env it results in:

STORAGE_LOCAL_PATH=/app/data/local-storageIS_CONFIG_VARIABLES_IN_DB_ENABLED=false

so to ensure this never happens the adding a newline after the cat >> /run/twenty-server/.env <<EOT is enough.

Thank you, I will look into that!

@james said:

Hello @ekevu123

Since not everyone is comfortable using the cloudron cli maybe you could add a .env.sh handler like we do with many packages.
Many Cloudron users also know this flow from us, guess that is why @enerch tried that approach first.

I didn't know people use it usually like that, will do!

@sponch said:

thanks for it! Just tested. It connects to my caldav calendar shows the diefferent calendars but doesnt sync them. Any idea?

Which Caldav calendar are you using? And how do you assume it doesn't sync them?

Try using the Cloudron CLI to set these!

@andreasdueren said:

@ekevu123 Cool app, toying with it right now. One observation:

• when trying to connect to my nextcloud calendar, it connects and recognizes the different calendars but when I press Add integration, it returns Base url Must be a valid HTTP or HTTPS URL (e.g., https://example.com) nonetheless.

This is fixed in the next release coming up today!

I am not against AI content, if the quality is good.

Via a custom script - when I change a version, I have to do this in several places in the app, so I wrote a script where I specify the version number and it does this automatically.

Both. I want to understand if both are correct programmatically, but I can't test them against having an existing docker image, because I find that counter-intuitive - why would I build the docker image before knowing if everything is correct?

It works again. Something else was broken as well, it was a bit of trial-and-error, so some form of file verification would be really helpful before deploying.

cloudron appstore verify-manifest requires a docker image, doesn't it? It would be ideal to have a verifier for both cases that don't need that. My logic would be that I want to fix any issues before building the image? I just want to see if it technically works?

Fair enough - mine seems to be working fine, though, since I rewrote my test script, so I guess I triggered it myself on my end.

I would like to be able to validate the CloudronVersions.json via Cloudron CLI, ideally with a simple boolean response, it's either valid or it isn't, and if the latter, why. This would allow an app developer to validate the file without having to go into their own Cloudron and test it manually. This way, it could also be part of automated validation processes like a test suite.