@girish said in Due date email notifications: @MarchinBunny This feature should work out of the box if Wekan supports it. Does it not work? What is the setting that you mention in docker-compose.yml? Cloudron does not use docker compose, we have our own packaging. Nope, I don't think it works out of the box from what I can tell. I certainly have never received an email for due dates. If you scroll through the file I mentioned, there is a section called "==== EMAIL DUE DATE NOTIFICATION =====" Below that you will see the settings are commented out with hashtags. Here is a copy and paste of the specific section I am talking about. # ==== EMAIL DUE DATE NOTIFICATION ===== # https://github.com/wekan/wekan/pull/2536 # System timelines will be showing any user modification for # dueat startat endat receivedat, also notification to # the watchers and if any card is due, about due or past due. # # Notify due days, default is None, 2 days before and on the event day #- NOTIFY_DUE_DAYS_BEFORE_AND_AFTER=2,0 # # Notify due at hour of day. Default every morning at 8am. Can be 0-23. # If env variable has parsing error, use default. Notification sent to watchers. #- NOTIFY_DUE_AT_HOUR_OF_DAY=8

Once upon a time there was an awesome app called "Rollbase" - which was unlimited and a pleasure to use for rapid development of relation database apps. Then Progress.com bought them and the whole thing became too commercial and unlikeable. Directus reminds me of what Rollbase was and could have been and I have been hunting high and low since for something like it. Then when finding Directus I saw developers that just got this need. It's similar to Strapi.io in some ways - but the way that it can work with any existing DB and any DB created with it can be used in any other way is what truly appeals for openness and non-proprietary data-structure locking that is seemingly quite rare in a sector that usually pursues SaaS and vendor-locking through proprietary data structuring that would otherwise be expensive to move. I see Directus as fast for modelling a relational database, as Cloudron is for modelling app infrastructure so certainly a kinship for the kind of things this community appreciates I'm sure. It was a random fins for me from a Reddit comment so I don't think so well known but Cloudron has also introduced me to many other apps I might never have found otherwise, so the curation Cloudron and the community is gathering into the suite is certainly a valuable part of Cloudron's offering as a brand for these standards and open self-hosted and managed objectives.

@jdaviescoates I think most hosts offer load balancers - but keeping the LB within the app would keep it more portable. I respect that D2C has overlap but I still see them as distinct and potential cross-pollination. Any example of the clustered app setups and minimum containers can be seen here: https://docs.d2c.io/getting-started/stack-hub/ D2C is still a hosted and proprietary solution including support services, whereas Clouron is open-source but less GUI to tinker or be intimidating, so the target audiences are different, and it might be that the way D2C works not being open-source is not compatible and Kubernetes (a la https://kubeapps.com) would be a more compatible approach?

@girish I mean primarily sponsoring packaging an App for Cloudron - some people are obviously more experienced and capable to work on that, and some of us that can't yet could contribute respectfully to keep devs fed. I think it is only right to sponsor in a way that the community benefits from the App, although I guess there could be scenarios where it might be a custom-version of an existing app, for which I don't think you should change your approval process just because someone paid for development as the curation of the App selection is part of your trust. I suppose something to consider might be whether quoting is public or private to be respectful, I don't mind either way but it's your forum so that's for you to choose if you wanted to moderate or guide there. I suppose if people didn't want the development to be contractual its worth looking at how GitHub Sponsoring works, whereby it is a donation but does not imply any warranty or support. I don't think Cloudron itself should be a party to transactions as that's just overhead and risk I managing and implying warranties, so this is strictly about making it OK to donate for development or offer development for donations with respect to it being your forum and ecosystem.

When the database restarts, some apps cannot deal with the loss of connectivity. In fact, we have special code on Cloudron to restart all the corresponding apps whenever the database is updated. I guess we need similar logic for database restart. I think docker has some way to get these event notifications. Something to keep in mind when debugging this.

We probably won't merge it into Cloudron itself but as a stand alone project which is packaged for Cloudron, we have no problems. Happy to publish it in our App Store as well (but it has to be a stand alone project like the rest of the apps we package).

Much appreciated!

@girish This is an interesting observation. I was just looking to see if this was a real security threat or not, and I suppose it isn't but can offer a bit more privacy using the wildcard approach. Any particular reason why the Let's Encrypt wildcard support can't be done through the actual Cloudron wildcard DNS approach? Is there a way to support this? I'd really like to take advantage of a smaller DNS provider which has some great monitoring features included, but it isn't supported via any API by Cloudron yet, so if I go that route I can only use the Wildcard option, but those don't actually allow for the wildcard certificates. Edit: Nevermind, I see why in the docs: "Let's Encrypt only allows obtaining wildcard certificates using DNS automation. Cloudron will default to obtaining wildcard certificates when using one of the programmatic DNS API providers."

@jdaviescoates said in YOURLS: /me goes to try and re-register that nice short url I once owned... Got it! (as a short .coop it is very hard for anyone else to get) Now own https://ud.coop again!

@jdaviescoates Fair enough. I'm with you on keeping data on a platform you control though. Outline looks cool, so that LDAP pull request gets merged. Certainly interested in what else comes from this thread.

@girish I understand, thank you!

Thanks, new version is published now.

I finally tested on a fresh install... and it works. So I dug some more, comparing the two installations, and realized at some point is a JS error on my regular install, linked to the chat integration plugin. In the end the code was outdated (it relied on a deprecated API), so I pulled the last version from git and... it worked. Long story short: this was a plugin bug Sorry for the noise, and thanks for suggesting testing a separate install!

@girish The screenshot was within mailtrain. I have the email partially working now: it can receive email and I can read it on thunderbird, but I haven't been able to successfully send one yet. Some of the logs say something about the domain being too new. I'll try the wordpress built-in email for now and see how far I get

@girish Got it. So as long as I stick with the Cloudron LDAP, all is well. Thanks for the explanation, and also for the update to the docs.

@girish said in How to disable user signup?: Bbut if you click register and try to register, one cannot login without an invite code. Ah, I see. I just tested this and you are correct. That is good enough! I do still have these two extra "blank" users (one admin and one not) that I cannot figure out how to get rid of and cannot edit (I tried to set them to Inactive, but the Save button doesn't appear to do anything), but I also cannot login as them, so I think it's okay. (These users are only in wekan, not in cloudron. My cloudron users are just the ones I expect to see.) Thanks for the help, and for the update to the docs. You are doing wonderful work trying to make self-hosting feasible for folks willing to try.