What's coming in 7.0 (was 6.4)
-
Wooo! Finally the big mail-focused release I (and many others) have been waiting for!
Looking forward to it. Any way I can help, just let me know. -
@jdaviescoates Oh yeah great catch! I'm sure that was a copy/paste mix-up as it's stating that in the older 6.3 announcement too. Wouldn't make sense to announce something that's not actually coming.
haha -
That operator role will be AMAZING. ALso mail backups
-
@jdaviescoates said in What's coming in 6.4:
After the email stuff, but I think that's just a copy/ paste oversight, right @girish ?
whoops, fixed
-
This will mostly have email related improvements. There's also a few last mail related migrations to do for multi-host in Cloudron 8 (everything else is migrated, yay).
- Better email monitoring/visibility for admins. @d19dotca raised many important posts and there's also existing ones. We have to read the posts in more detail and discuss internally before we give more details on what we plan to do here.
- Add easier way to setup mailbox redirects
- Add way to setup sieve rules for mailboxes from the dashboard itself. One way we are thinking of doing this is to simply expose mail data via the file manager. Just like how app data is also exposed via file manager. Just to make it easier to use, we will probably add "download"/"restore" action in the mailbox view to add on top of this.
- Backup mail data separately (instead of as part of box code). This will allow restoring and backing up mail stuff separately just like it's an app.
- Add a way to run cronjobs (per app?)
- Operator role for specific app. This new role will allow assigning a user as "operator" for some apps and that user can then view logs, restart app, increase memory limit etc but without being a cloudron admin as such.
- Make it easy to install non-appstore apps.
EDIT: Since we stop supporting Ubuntu 16 from this release, we decided to call this Cloudron 7.0 and not 6.4.
@girish said in What's coming in 6.4:
Operator role for specific app. This new role will allow assigning a user as "operator" for some apps and that user can then view logs, restart app, increase memory limit etc but without being a cloudron admin as such.
any chance that this update in management comes with a "group admin", who can install/operate apps and add users for specific groups only?
-
@girish said in What's coming in 6.4:
Operator role for specific app. This new role will allow assigning a user as "operator" for some apps and that user can then view logs, restart app, increase memory limit etc but without being a cloudron admin as such.
any chance that this update in management comes with a "group admin", who can install/operate apps and add users for specific groups only?
@msbt Personally, I think the best approach is an unlimited number of customizable roles with a set of permissions you can give those roles.
So like discord for instance:
This is definitely more work so I get if its not a thing that will make it in.
-
@girish said in What's coming in 6.4:
Operator role for specific app. This new role will allow assigning a user as "operator" for some apps and that user can then view logs, restart app, increase memory limit etc but without being a cloudron admin as such.
any chance that this update in management comes with a "group admin", who can install/operate apps and add users for specific groups only?
-
@msbt Will look into that. I think there was also request for a role to just create mailboxes.
@girish as I remember that was about adding the ability to create mailboxes to the existing User Manager role (given that very often new Users also need an mailbox).
-
This will mostly have email related improvements. There's also a few last mail related migrations to do for multi-host in Cloudron 8 (everything else is migrated, yay).
- Better email monitoring/visibility for admins. @d19dotca raised many important posts and there's also existing ones. We have to read the posts in more detail and discuss internally before we give more details on what we plan to do here.
- Add easier way to setup mailbox redirects
- Add way to setup sieve rules for mailboxes from the dashboard itself. One way we are thinking of doing this is to simply expose mail data via the file manager. Just like how app data is also exposed via file manager. Just to make it easier to use, we will probably add "download"/"restore" action in the mailbox view to add on top of this.
- Backup mail data separately (instead of as part of box code). This will allow restoring and backing up mail stuff separately just like it's an app.
- Add a way to run cronjobs (per app?)
- Operator role for specific app. This new role will allow assigning a user as "operator" for some apps and that user can then view logs, restart app, increase memory limit etc but without being a cloudron admin as such.
- Make it easy to install non-appstore apps.
EDIT: Since we stop supporting Ubuntu 16 from this release, we decided to call this Cloudron 7.0 and not 6.4.
@girish said in What's coming in 6.4:
- Make it easy to install non-appstore apps.
I see what you did there...
-
@atridad I added a last item "Make it easy to install non-app store apps". We are hoping to atleast make it easy for people to install from something like your repo.
@girish said in What's coming in 6.4:
I added a last item "Make it easy to install non-app store apps".
That is great news. In case you do not yet have a better idea how this could be designed, I want to pitch the way this is organised in Portainer again. I explained it already a while back in https://forum.cloudron.io/topic/4485/proposal-the-cur-cloudron-user-repository/14?_=1626194230000. Basically a local admin can override/extend the entries from their official "appstore". Additional entries are defined in a json structure. When opening the Cloudron appstore it makes a request to
https://my.cloudron.host/api/v1/appstore/appswhich gets a json response with all the appstore data. What if opening the store would in addition to this also make a request tohttps://user:password@store.my.domain/apps.jsonand also show a category "community" that lists apps from this json listing. Plus points if the listing can be password protected (like the private docker registry). This could also be a nice revenue model for external app developers. -
G girish pinned this topic on
-
@girish said in What's coming in 6.4:
I added a last item "Make it easy to install non-app store apps".
That is great news. In case you do not yet have a better idea how this could be designed, I want to pitch the way this is organised in Portainer again. I explained it already a while back in https://forum.cloudron.io/topic/4485/proposal-the-cur-cloudron-user-repository/14?_=1626194230000. Basically a local admin can override/extend the entries from their official "appstore". Additional entries are defined in a json structure. When opening the Cloudron appstore it makes a request to
https://my.cloudron.host/api/v1/appstore/appswhich gets a json response with all the appstore data. What if opening the store would in addition to this also make a request tohttps://user:password@store.my.domain/apps.jsonand also show a category "community" that lists apps from this json listing. Plus points if the listing can be password protected (like the private docker registry). This could also be a nice revenue model for external app developers.@fbartels Agreed! This workflow would be excellent!
-
@girish said in What's coming in 6.4:
I added a last item "Make it easy to install non-app store apps".
That is great news. In case you do not yet have a better idea how this could be designed, I want to pitch the way this is organised in Portainer again. I explained it already a while back in https://forum.cloudron.io/topic/4485/proposal-the-cur-cloudron-user-repository/14?_=1626194230000. Basically a local admin can override/extend the entries from their official "appstore". Additional entries are defined in a json structure. When opening the Cloudron appstore it makes a request to
https://my.cloudron.host/api/v1/appstore/appswhich gets a json response with all the appstore data. What if opening the store would in addition to this also make a request tohttps://user:password@store.my.domain/apps.jsonand also show a category "community" that lists apps from this json listing. Plus points if the listing can be password protected (like the private docker registry). This could also be a nice revenue model for external app developers. -
@girish said in What's coming in 6.4:
Make it easy to install non-appstore apps.
Can someone point me to any prior discussions based around this topic?
Even though I myself like to use these non-appstore apps, partly to help test, partly because it is an app I'd like to use (I just installed the Paperless-ng app), the amount of troubleshooting that goes on seems like alot. And, as I've expressed before in other posts, I love the stability and ease of Cloudron, and the amazingly quick and attentive help the main devs give, particularly on this forum.
So I don't see how adding the option for more people, likely many who are even less skilled than I (and I am barely keeping my head above water here!), to start messing around with apps that need tweaking, is going to help keep all that we love about Cloudron at the fore. I mean, the tech barrier (code barrier? comprehension barrier?) in front of building and installing non-app store apps I imagine acts as a gate to limit the number of Help requests connected to these apps. Do we need another type of gate?
I am impressed by how quickly and neighbourly the other posters are to help, both myself, and I can see them helping others. Is there not some other way to keep this third-party option alive, maybe even another subscroption level?
Sub-reddits often require posters to have a certain life-span before you can post; lowendtalk also has a minimum activity level for posting. But I can see how that could seem too exclusive for new comers, and maybe even for old-timers now.
Any thoughts?
A life lived in fear is a life half-lived
-
@girish said in What's coming in 6.4:
Make it easy to install non-appstore apps.
Can someone point me to any prior discussions based around this topic?
Even though I myself like to use these non-appstore apps, partly to help test, partly because it is an app I'd like to use (I just installed the Paperless-ng app), the amount of troubleshooting that goes on seems like alot. And, as I've expressed before in other posts, I love the stability and ease of Cloudron, and the amazingly quick and attentive help the main devs give, particularly on this forum.
So I don't see how adding the option for more people, likely many who are even less skilled than I (and I am barely keeping my head above water here!), to start messing around with apps that need tweaking, is going to help keep all that we love about Cloudron at the fore. I mean, the tech barrier (code barrier? comprehension barrier?) in front of building and installing non-app store apps I imagine acts as a gate to limit the number of Help requests connected to these apps. Do we need another type of gate?
I am impressed by how quickly and neighbourly the other posters are to help, both myself, and I can see them helping others. Is there not some other way to keep this third-party option alive, maybe even another subscroption level?
Sub-reddits often require posters to have a certain life-span before you can post; lowendtalk also has a minimum activity level for posting. But I can see how that could seem too exclusive for new comers, and maybe even for old-timers now.
Any thoughts?
@scooke I think I’m with you on that. Having ‚inofficial‘ apps or a second AppStore doesn’t help quality on the long run - unless it’s just testing ground for officially supported apps. Otherwise it’s easy to habe the Nextcloud or Yunohost mess on your hand with unofficial apps breaking all sorts of stuff….
-
@girish said in What's coming in 6.4:
Make it easy to install non-appstore apps.
Can someone point me to any prior discussions based around this topic?
Even though I myself like to use these non-appstore apps, partly to help test, partly because it is an app I'd like to use (I just installed the Paperless-ng app), the amount of troubleshooting that goes on seems like alot. And, as I've expressed before in other posts, I love the stability and ease of Cloudron, and the amazingly quick and attentive help the main devs give, particularly on this forum.
So I don't see how adding the option for more people, likely many who are even less skilled than I (and I am barely keeping my head above water here!), to start messing around with apps that need tweaking, is going to help keep all that we love about Cloudron at the fore. I mean, the tech barrier (code barrier? comprehension barrier?) in front of building and installing non-app store apps I imagine acts as a gate to limit the number of Help requests connected to these apps. Do we need another type of gate?
I am impressed by how quickly and neighbourly the other posters are to help, both myself, and I can see them helping others. Is there not some other way to keep this third-party option alive, maybe even another subscroption level?
Sub-reddits often require posters to have a certain life-span before you can post; lowendtalk also has a minimum activity level for posting. But I can see how that could seem too exclusive for new comers, and maybe even for old-timers now.
Any thoughts?
@scooke Yeah, great points. I should have been more clear. We don't intend to add a way to add a 3rd party app store. While this is possible, apart from it being some technical achievement, will most likely just frustrate users.
What I meant by that feature was that it will be useful to have a way to quckly install apps that are packaged by others without having to step into the CLI. i.e skip the whole CLI install+build+push image+install cycle. This workflow requires the user to know nodejs, docker, CLI use among other things, quite complicated. We also have a selfish reason to do this. When someone suggests that something is "packaged", we would like to have a quick look as to what state the app is in and we have to do this CLI workflow ourselves.
I don't know how this looks like but maybe there is some simple install UI where one can just put upload a manifest file + docker image name and that's it.
-
@scooke Yeah, great points. I should have been more clear. We don't intend to add a way to add a 3rd party app store. While this is possible, apart from it being some technical achievement, will most likely just frustrate users.
What I meant by that feature was that it will be useful to have a way to quckly install apps that are packaged by others without having to step into the CLI. i.e skip the whole CLI install+build+push image+install cycle. This workflow requires the user to know nodejs, docker, CLI use among other things, quite complicated. We also have a selfish reason to do this. When someone suggests that something is "packaged", we would like to have a quick look as to what state the app is in and we have to do this CLI workflow ourselves.
I don't know how this looks like but maybe there is some simple install UI where one can just put upload a manifest file + docker image name and that's it.
@girish Yeah. An entire third party store built in might cause confusion.
-
@girish said in What's coming in 6.4:
I added a last item "Make it easy to install non-app store apps".
That is great news. In case you do not yet have a better idea how this could be designed, I want to pitch the way this is organised in Portainer again. I explained it already a while back in https://forum.cloudron.io/topic/4485/proposal-the-cur-cloudron-user-repository/14?_=1626194230000. Basically a local admin can override/extend the entries from their official "appstore". Additional entries are defined in a json structure. When opening the Cloudron appstore it makes a request to
https://my.cloudron.host/api/v1/appstore/appswhich gets a json response with all the appstore data. What if opening the store would in addition to this also make a request tohttps://user:password@store.my.domain/apps.jsonand also show a category "community" that lists apps from this json listing. Plus points if the listing can be password protected (like the private docker registry). This could also be a nice revenue model for external app developers.Yes, depending on quality this could of course cause some confusion. But there are a few examples of working third party repositories out there that extend a main product. The external app stores on Synology come to mind for example. Plus since apps are running in read-only containers and are mostly isolated from the host I don't think an app can mess up a server at all. But the most important part for me was in the last sentence:
@fbartels said in What's coming in 6.4:
This could also be a nice revenue model for external app developers.
-
@scooke Yeah, great points. I should have been more clear. We don't intend to add a way to add a 3rd party app store. While this is possible, apart from it being some technical achievement, will most likely just frustrate users.
What I meant by that feature was that it will be useful to have a way to quckly install apps that are packaged by others without having to step into the CLI. i.e skip the whole CLI install+build+push image+install cycle. This workflow requires the user to know nodejs, docker, CLI use among other things, quite complicated. We also have a selfish reason to do this. When someone suggests that something is "packaged", we would like to have a quick look as to what state the app is in and we have to do this CLI workflow ourselves.
I don't know how this looks like but maybe there is some simple install UI where one can just put upload a manifest file + docker image name and that's it.
@girish said in What's coming in 6.4:
We also have a selfish reason to do this. When someone suggests that something is "packaged", we would like to have a quick look as to what state the app is in and we have to do this CLI workflow ourselves.
This makes a lot of sense actually. With whatever process you come up with, the goal would be that knowing when someone says the app is packaged, "ready", it most likely is because they've had to do the correct steps, get auto-checked. So in the long run it would actually help the AppStore by freeing up your time checking things before making them Official.
I imagine there'll still be alot of troubleshooting involved getting to the Packaged state though.
