@marcusquinn I think DNS automation (provider specific) atleast needs to come from elasticemail itself ideally. It's not possible to keep track of all the DNS records each provider wants to set and if it's even available with API. It's basically impossible to test on our side atleast.

Are you telling me that apt install screen is going to break updates? 😆

@jimcavoli A hack for the moment of course is to simply docker restart <container>. Not ideal, agreed.

@girish hinted, that this needs more vetting here. So if that app would have been auto-updated, then a backup would have been made, regardless of automatic backups or not.

That in its own may or may not be what one would expect.

Either way to be consistent at least, I will change that to have the skip backup checkbox set by default only if automatic updates and backups are disabled.

Edit: pushed the new fix

@robi If you wish, I was thinking contact details of the maintainer, not the brand themselves.

For those checking this later, the apps that have automatic backups are disabled are listed in the Backups view (under Location).

5a24bfd9-5e53-42f7-b62a-e509e2ab4671-image.png

@atrilahiji Not sure, I just liked the look of it and thought could be useful, so this section seemed as good as any. Could be in Discuss as well I guess.

@nebulon would it be too much to make sure, either just from a visual stand point to encourage people to save that encryption password offline/somewhere ?

This is implemented in Cloudron 6 ! https://forum.cloudron.io/topic/3205/what-s-coming-in-6-0-take-2/99

@marcusquinn see my post about n8n at https://forum.cloudron.io/topic/1939/n8n-io-zappier-ifttt-integromat-alternative/13?_=1605126531115 - short version is that it's been packaged, it's just not primetime-ready

Maybe interesting:

Maybe a NodeJS alternative:

@robi said in Add new App notifications:

@lonk no, monthly doesn't make sense apart from an email, like the new Cloudron release emails.

Weekly maybe, but ideally the day it is released.

From there those interested in those can subscribe to the stable Apps or unstable Apps notifications.

I like that. Opting into app updates without having them installed. Often times user's don't want to be the early adopters (I do, but I'm me 😂) so they wouldn't install anything initially, and getting release notifications even though the app isn't installed might eventually prompt them to. It's not even too difficult a change since it already exists for installed apps.

@fbartels said in MySQL tuning with my.cnf settings optimisation:

@lonk said in MySQL tuning with my.cnf settings optimisation:

when do we run / apply it?

Mysql tuning is best applied after a few days of database usage. Applications usually have different load patterns.

Gotcha, thanks for the tip! ☺️

@nebulon My bad, I created a discussion in the discussion because I felt it was loosely related to password management.

@robi Installing apps from the store en masse can't be common. I think rn it's flow is best for an average user, but it could be a little more mobile app store like with an "installing" progress bar while you discover other apps, and then it pops up with "installed, click to open" or something via Notifications. I could see it, but again - installing apps isn't common enough I don't think to worry about this since installing is a one-time task.

But I'm glad you brought it up because it would add a bit of polish to have a more "app store" feel to it. Still allowing app discovery while an app's installing. I think Cloudron should be able to do that one day even if it doesn't feel like a priority rn.

@nebulon said in Extra fields in LDAP:

The phonenumber for Mattermost is one such use-case, but that can be also solved without custom fields.

Assuming there might be a need for this in the future - what was the solution you thought of?

Also, even if app's don't use the fields, just having the Cloudron User directory more fleshed out might be a good thing for reference sake.

thanks @fbartels!

Hey guys, sorry for the delay

I've updated the fork and the providers function, if I get permission to create a new branch or you open one I can open an MR with the new branch and let you review

@MooCloud_Matt said in tmpfs support in the manifest:

@Lonk
you mean for a private docker registry ?

Though I could do that yes, I was speaking more in terms to an actual alternative App Store, private or public registries wouldn’t matter. I’d probably originally make it only public registries at first.

Like, I’ve been wanting to create Dot the Repair Bot Cloudron app but it’s more of a Cloudron add-on and probably doesn’t belong in the official store (maybe, not sure). But if it didn’t and I still wanted it to be accessible - I could build an alternative App Store with the docker add-on and put apps on there.

Orrrr, the official App Store could gain sources in which case I would just host a JSON file on BackBlaze and give people the source’s URL to use and it would pop up in the store as a third party app.

It would make beta testing apps with people wildly easier if the Cloudron App Store allowed for more “app sources” than just its hard coded internal source that @girish and @nebulon maintain alone.

@luckow That’s super cool. Glad to hear it works that way with external LDAP. Thanks for sharing your story! ☺️