@ekevu123 So far, we've had 1:1 appointment types (user books a slot, slot is no longer available). I have a 1:many use case (webinar) and wish tymeslot could handle that. Maybe it fits within the scope of the application? What do you think?
It's already in development, but requires some bigger infrastructure changes and good testing. It should land within the next 2 weeks for sure!
Correct, that should work!
Also, you can now manage environment variables directly in Cloudron.
Thank you, that gave me something to work through!
I want to create a custom terminal-based cloudron app and connect to it using SSH. This app will process sensitive data, so I need to think about heightened security. The goal is to allow SSH access only, no public access whatsoever is needed.
Are there any good processes I could follow? I was thinking of restricting access only via Cloudron's VPN app, how would I implement this?
Yeah, that makes sense!
Writing should be possible, I have just released an intermediary step for testing. Thank you for the advise with the delete button and the jumping, I'll look into this today as well!
I want to be able to schedule e-mails to one recipient. So, when I send an e-mail, I want to be able to choose a date and time when it is being sent. This should be on the server, not on my laptop, so a webmail app would be the perfect place for that.
I need to send occasional one-off scheduled e-mails. So, I have an e-mail that shouldn't be sent immediately, but at a scheduled time. Also, my computer shouldn't have to be online at that time, so I want to schedule and forget.
I was using Missive for that reason, a free web app for e-mails, but it terminated their free plan, and I have no other reason to pay for it.
I can think of ways to code something to solve this, but it seems overkill. I wonder how else I could solve this?
My setup:
Actually, if there's no better solution, I would even be fine to code a small relay and host it on Cloudron. But maybe I am overcomplicating this here?
the
time-slot intervalsis a great feature of cal.com
It ends in :
This will be deployed this week!
Exchange Webservices as as additional calendar type would be nice, but there does not seem to be something in elixir for this.
This as well, but I couldn't test this well myself, feel free to check it out. I used an open-source exchange server for testing.
No worries, I appreciate you pointing this out and using Tymeslot as well.
All I can say is - it worked for me without "caldav", and the last update should have fixed that, so please try again. Happy to look into this again if needed.
Hi, I was on vacation for a week and promised myself not to look at code for a week.
I have now installed the calendar app and tried it myself. Can you try the server URL without the additional /caldav? This should work.
In the meantime, I'll check how I can make the initial URL work, this will be fixed next week.
Biggest Feature would probably be Teams with automatic routing etc.
I have started working on it, but expect it will take a few more weeks until it can be reliably shipped.
Exchange Webservices as as additional calendar type would be nice, but there does not seem to be something in elixir for this.
That's not an issue! That can also be done in the foreseeable future.
Tymeslot author here.
If you have any feature requests, anything you wish for, use this thread!
For issues, please create separate threads.
I have just run into the same issue.
Isn't the issue that the build process forks into different processes per worker and the sum of it takes too much memory? I had to set my memory limit to 5 GB to get the app to start again. It looks to me like the workers are given 75 % of the memory assigned to umami each, which leads to the issue. Also, does the app have to recompile every single time it restarts?
Maybe the default memory could also be raised above 2 GB considering that several people (also in another thread) faced memory issues before.
@joseph That is it (source: I just tried it myself and directly deleted the app again)
Thank you, who would have thought ... I think some better error messages would be good to help the user understand what the issue is.
@ekevu123 hasn't this just been added to the official app store?
Not sure it needs to be in both?
It apparently was added, I was never notified of that ... that's better then!
Does that mean we don't need the cloudron versions file anymore, assuming any Cloudron user would prefer the app store install over the manual community package?
I was trying to add my app Tymeslot to the Community App Store using this link to the CloudronVersions.json: https://github.com/Tymeslot/tymeslot/blob/main/CloudronVersions.json
However, it says that the JSON is invalid. Am I missing something? It looks fine to me.
Okay, I will check that!
EDIT: I checked it, but as I see it, this requires to make changes to the OS Cloudron is running on, assuming it would even work. I think that's a bit too much manipulation.
How? I have tried to make it run, but I don't think it works. Gitea Runners need the opportunity to dynamically run docker containers.
