Cloudron Forum

I have fixed the crash itself. I think the 38k rows is causing the timeout. Maybe your disk or CPU is slow? But the default transaction lock is 50 seconds, and I can't think why reading 38k rows will take that long. I have changed the transaction's isolation level that should at least make it faster. Let's see how it is in the next release.

Fixed in 6796854d1ad74ce45f7e11f716a69f6eced75021

Fixed in 890b27bd9efd762c8454779c6db4bffeb78fca5b

ok, we now have:

https://ca.cloudron.io/app/io.github.ravolar.cap
https://ca.cloudron.io/app/io.ente.cloudronapp

Conflicting titles - https://ca.cloudron.io/app/cap

@andreasdueren oof. I didn't expect CA to become that popular that tile will start conflicting. I will change the URI scheme to use the app ids which are unique.

Instead of making a new setting, I think it's better to simply disable zip downloads when public listing is disabled. I have made this fix. Will release shortly.

Right, this is a bug. I have fixed it now.

• Redis in non-persistent mode deletes the dump on start up
• Box code will skip backup and restore of non-persistent redis
• Box code deletes the dump when the redis non-persistent flag is set

As mentioned, I split off the previous 10.1 thread into this.

10.1 is being rolled out. There are no real features in this release but just software upgrades which is necessary and often nothing very exciting.

I made a separate post for 10.1 - https://forum.cloudron.io/topic/16099/what-s-coming-in-10.1

• New base image based on Ubuntu 26.04
• This will bump postgres to 18
• dovecot to 2.4
• mongodb 8.3
• Add notification for failed email status check
• IP based certs for setup UI and post installation page
• Remove email requirement for Let's Encrypt

Upstream bug - https://github.com/OpenMarshal/npm-WebDAV-Server/issues/146

Fixed!

This works on GNOME too. I happen to have a Mac, let me check...

Good catch. Was easy to create a test and fix.

Alright, impersonate is back. I removed the option to create app password for another user since this is causing much confusion. The feature was not well-thought-out.

Yes, the patch is applied at restore time, so restore from some old backup and archive will work. I would say you should take a more recent backup though after upgrading to 10.1.x. It will create dumps with the correct quoting. I don't think we will maintain this taiga specific patch for many releases. It's just a hack right now to move forward.

Admittedly, I have lost track. @james can you take a look at what's needed here?

OK, so I had AI go in and check over 70 of our packages if they will hit any keyword conflicts. 2 hours later...

Taiga is the only Cloudron PostgreSQL app whose shipped schema will fail this upgrade. Every other app at the pinned version is clear.

I checked this on PostgreSQL 18.6 first, because it changes what is worth testing. A table column named json, json_table, merge_action, and the rest is legal. These names fail only as a function or procedure argument, or as a RETURNS TABLE column. CREATE TABLE t (json varchar(16)) succeeds. CREATE FUNCTION f(json json) and RETURNS TABLE(json int) fail. So a user column named json in Grist, NocoDB, Baserow, or Directus does not break the restore.

The scan looked for those argument and RETURNS TABLE names in each upstream tree at the Cloudron pin. Taiga 6.10.2 is the only hit: json_object_delete_keys("json" json, ...) in the custom-attribute migrations (the same shape with jsonb in the later migration). A PostgreSQL 16 pg_dump writes that argument unquoted, and PostgreSQL 18 rejects it.

Nothing else matched. That includes GitLab 19.3.2 (1322 functions), Immich (123), NocoDB (51), AFFiNE (32), Baserow (26), Discourse (15), and the ONLYOFFICE 9.4.0 and ONLYOFFICE EE 9.4.0 packages (one function, merge_db, with ordinary argument names). Moodle, Nextcloud, and the rest of the PostgreSQL app list have no function argument or RETURNS TABLE column with these names.

App password based login does not send emails.

However, I think, as you pointed out I think the UI is may be confusing already. I will bring back the old impersonate and then it's clearer.

How does an admin get that app password: can an admin create one for another user, or does the user have to create it and share it?

Yes, admins can now create app passwords for another user from the Users page. Many of our app like Surfer, Container registry, Cubby etc integrate with this feature. So you can use create an app password as another user and use it in those apps. For example, say you have "devops" user which you use in the CI. Then you can go to devops user and create an app password for surfer deployment. Then the surfer History will show that the deploy was done by "devops" user.

Thanks for reporting, best to fix this before we do a wider rollout.

There was a bug that the importer "hung" if the other side (postgres) errored out. That is also fixed now. Will make a new path releases with the fixes.