What's coming in 5.2
-
Here's what you can expect from 5.2. We are still working actively on a few more apps and the apps have more priority. Specifically @nebulon is working on Bitwarden and I am trying to get Jitsi/BBB.
- Update base image - this should update many packages, the vim/bash history configuration etc.
- Some user onboarding flow - don't have concrete plans here. But sometimes new users are confused by all the automation we do - like db, email, user management. Feels very magical, so we have to put in some videos/images to re-assure them/explain what's happening.
- Add support for member-only mailing lists.
- Support for external volumes for apps
- Default to ECC certs from Let's Encrypt.
- App firewall (protect login screens and login routes of apps)
Any more suggestions?
-
@echokos Currently, there is no way for an app to access data on the host/server. For example, let's say you have lots of photos or videos in an external drive or accessible via NFS, there is no way for the app to access it because of the containerization. Volumes will provide a way to mount host paths into containers. If we implement volume sharing, one use case is you can download a file via torrent and have the media immediately viewable via emby.
-
@echokos Currently, there is no way for an app to access data on the host/server. For example, let's say you have lots of photos or videos in an external drive or accessible via NFS, there is no way for the app to access it because of the containerization. Volumes will provide a way to mount host paths into containers. If we implement volume sharing, one use case is you can download a file via torrent and have the media immediately viewable via emby.
-
-
@yusf I guess you mean creating a symlinking straight in the appsdata directory? That won't work because the container can see what the symlink resolves to but cannot access the resolved path itself since it can only see within it's own file system.
-
@echokos Currently, there is no way for an app to access data on the host/server. For example, let's say you have lots of photos or videos in an external drive or accessible via NFS, there is no way for the app to access it because of the containerization. Volumes will provide a way to mount host paths into containers. If we implement volume sharing, one use case is you can download a file via torrent and have the media immediately viewable via emby.
-
Like I've mentioned via email, I'd really appreciate email aliases - I have a couple of domains where I receive an email, so - mario@{domain1.com,domain2.com,domain3.com,..} is essential for my workflow.
-
Like I've mentioned via email, I'd really appreciate email aliases - I have a couple of domains where I receive an email, so - mario@{domain1.com,domain2.com,domain3.com,..} is essential for my workflow.
@mario said in What's coming in 5.2:
Like I've mentioned via email, I'd really appreciate email aliases - I have a couple of domains where I receive an email, so - mario@{domain1.com,domain2.com,domain3.com,..} is essential for my workflow
Same here, this would be great and hopefully not too hard to implement. But there are most likely higher priorities in future development work to get done first.
-
Would it be possible to get a measurement of bandwidth used per month per container (in and out)?
-
Like I've mentioned via email, I'd really appreciate email aliases - I have a couple of domains where I receive an email, so - mario@{domain1.com,domain2.com,domain3.com,..} is essential for my workflow.
-
-
-
On notifications, when Redis runs out of memory, we get just a GUID - that takes time to track down which app that is to increase memory. Any way to tie that back to the deployed app name or URL?
-
On notifications, when Redis runs out of memory, we get just a GUID - that takes time to track down which app that is to increase memory. Any way to tie that back to the deployed app name or URL?
@doodlemania2 Yes, redis changes are coming in https://git.cloudron.io/cloudron/box/-/issues/671
-
Because I just gave a user the "User Manager" role (I thought this would enable a user to manage the users of a certain group): It would be awesome to lock that user-manager to a specific domain/group, so all other users won't be visible to that person.
Same goes for admin vs. group-admin (admin = global, group admin can only install/manage apps, email and users on the (primary-) groups he's added. This way you can let people manage their own users without interfering with other groups. Does that explanation make sense?
-
Another +1 for group managers (I've mentioned this before of course
). This would relieve a lot of my reservation on granting user manager to certain folks in some organizations!
Exactly what @jimcavoli said.
-
I think Jitsi and/or BigBlueButtom would be great!
I hope you don't loose the timing for it, because after somebody chooses a platform for its users is difficult to change. If it were ready now I'm sure Cloudron would have many more new users. -
Wanted to give some progress on the release here. Both @nebulon and I are taking a bit of break for Jitsi
We will revisit once we finish some more enjoyable tasks.
-
Update base image - this is done! Apps are slowly getting updated one by one.
-
Add support for member-only mailing lists - done!
-
Default to ECC certs from Let's Encrypt - done!
-
Redis status - Under services, you can now tune redis instance of each app
App firewall will not make it this release since the changes are stacking up.
-