I'm sure something similar has been asked already but I couldn't find it on the forum.

Would it be possible to add to following features of User & Groups in future version of Cloudron:

• subscribe users to a specific domain (say with another drop down option for each users: default being "all" but with the possibility to select domains individually - as it is down for selecting group membership). Those users would then only be allowed to login on apps which are installed under that/those particular domain(s). Effectively this is no different that manually creating a group for each domain and then manually setting the correct access permission when installing apps, except that it would automate that process by creating those groups in the background for each domain and setting the correct rights automatically. Also it would be helpful for implementing the "3. per domain user management" aspect of the "domain admin" feature below

• create a "domain admin" role to give some members admin rights but only on certain domains so that they can (and only can): 1. access all apps and email settings on a given domain(s); 2. an managed all of apps on that/those domain(s) 3. can see all users subscribed to that/those domain(s) and can invite new users to that/those domain(s). So as role we'd have: Owner, Admin (would automatically be administrates all domains), Domain Admin (which when selected would open the drop down menu to select domains without the "All" option), Users (which when selected would open the drop down menu to select domains, with default choice on the "All" option).

It feels these two features would greatly enhance cloudron management for cases where you don't necessarily want to have admins able to administrate all domains (either for security reasons and for reducing admin time) but still want someone able to configure email accounts / lists, manage apps and invite people.

Here is just some concepts and some ideas on how it could work on the UI side. Hope this proves useful.

Hello,

Is it possible to integrate mailman to cloudron to be able to manage email lists?

It would be a great feature to have.

Could be useful, don't think we have already an app for this.
https://www.signserver.org/
https://hub.docker.com/r/primekey/signserver-ce

@girish Yes you are right that the post started with different domains but this is because I had in mind the case of an organisation that uses separate domains for different activities, with different people being in charge of those different activities. While you are right that Cloudron does a fantastic job as isolating access to apps with the Group feature, as soon as if you give Admin right to someone, then they get full access to everything irrespectively of group / user access rules (which is of course kinda of the point of an admin!).
The issue is that in the case I mentioned, it would still be useful to give some people the ability to at least managed emails, users and apps for their particular domain / area of the organisation.
While this may not be a "common" case, I reckon it is not super rare either.

That said, the thread though as kinda of evolved into looking at ways to fine tune the rights of the Admin role rights rather than a split per domain as it started original. Lots of ideas in there. Maybe another intermediate Admin role could be step in that direction to delegate some rights (like email management) to people which would be useful in large organisations (see my second post) without granting full admin rights ?

@scooke I too would very much like to use Kopano Meet with external users (without them to login into my Cloudron), so like you I think it would be a great feature to have but still, I think we should be grateful on the fact some developer bothered making a Cloudron package even if there are limitations for now and not be too harsh or focused on criticisms and enjoy that we got a videoconference app running on Cloudron. And maybe kindly ask for support if you're trying to do something which you cannot do on your own (I believe the Kopano Meet Cloudron app has an open source code which you could be modify to add the functions you want, if you know how to do it).

As @fbartels explained, Kopano does have this functionality, it "just" needs to be configured. Now the "just" doesn't seem very straightforward and yes it'd be great if someone could package the app with that function turned on. Maybe @fbartels can help? Personally I'm not a developer so I can't help with this but appreciate any work anyone can put into this or into anything else that makes Cloudron better.

@jdaviescoates said in Meet Kopano (unstable version) - a few questions & problems :

with full p2p WebRTC apps like Kopano Meet all users need to have enough bandwidth for all streams or something

Here is a nice explanation of the pros and cons of the three main typologies used for video conference: p2p / MCU / SFU

Is there any update on this app? It would be awesome to have it!

I like the idea of having more app filters!

SSO great idea.

When it comes to an "open source" filter, I think the open code based makes more sense, rather than looking at all add-ons or price. We are talking about filters on Cloudron App Store, therefore think the question is, "is the app actually installed from cloudron app store opened of closed?", not any add-ons people may choose to install later on.

Other options could be to have:

• a Free Software filter for program without any proprietary add-ons
• a "close sourced" filter for apps where the code of the base app is not available (i.e. that app actually installed from the app store)
• a $ filter for program that require a paid license

Mainly I think we should NOT conflate price/money and license type / openness of source case. Take Teamspeak, for e.g., it can be used for free, on a free (as in free beer) license, yet it is proprietary software.

I think that whatever filter option we choose, the openness of the code that is actually being installed from the Cloudron App Store (i.e. without add-ons) is the thing that users should be made aware of / able to easily choose from. So as a first implementation of any filter, I thing the open/closed source filter would be the priority.

Also might be of interest:

An article which test a methodology to compare SFUs, and then test a few of them. Results probably do not reflect real case scenario though.

@girish Thanks for the reply and explanation Girish. I actually didn't imply I wanted a fully featured multi-organisation approach to Cloudron management, and even less if it implies major changes to Cloudron core design. I actually like that the current design is oriented to single user / organisation as it prevents centralisation.

The use case I had in mind was mainly for a single organisation that has several domains and a fluctuating users base of about 200. By default all users have access to all apps (unless you configure manually as I mentioned in the post).
The issue is that with users coming and going, you must make sure not to make mistakes with permissions and correctly isolate them from each domains by manually managing groups.
The other issues is that these users make regular requests to create email list, email accounts, adding or removing users. So it'd be handy to be able to give more people admin rights just for these particular aspects and restricted to a specific domain.

I thought what I had described was not a fully featured multi domains function for cloudron, but "just" (says someone who doesn't code) some additional domain management capabilities that could be implemented with functions that already exist in cloudron (namely with User Groups and different role levels). But I can imagine that when it comes down to doing, it becomes more complicated.

@murgero Sorry it took a while, done now!

@girish Many thanks Girish. It must have been a space problem indeed. Looking at the log, the processed froze while downloading the last big part of the image (~570MB). I tried to duplicate the app, which worked fine but and the process also froze when trying to update it (also while downloading that part the image).

Anyway, I had a about 3GB of free space which I though would be enough to update Wekan but after doing some cleaning up on the server (like deleting old apps I wasn't using), I went to about 7GB of free space and the update started working again.

In one of my Cloudron, I have just noticed that Wekan stayed stuck v4.57 (auto update are NOT disabled) with an error message. I have used the "Retry update task" button and that restored the app to a working state but still on version 4.57 and showing "Update available" label.

I have tried to update and it only proposes to update to v4.58 instead of latest v.4.63 and then fail when downloading the image with the following error:
Error : Task Error - Task 2662 crashed with code 7 and signal null

Any idea what I should do?

Many thanks

PS: it's all fine on all of my other Cloudrons

@girish Yes you are right that the post started with different domains but this is because I had in mind the case of an organisation that uses separate domains for different activities, with different people being in charge of those different activities. While you are right that Cloudron does a fantastic job as isolating access to apps with the Group feature, as soon as if you give Admin right to someone, then they get full access to everything irrespectively of group / user access rules (which is of course kinda of the point of an admin!).
The issue is that in the case I mentioned, it would still be useful to give some people the ability to at least managed emails, users and apps for their particular domain / area of the organisation.
While this may not be a "common" case, I reckon it is not super rare either.

That said, the thread though as kinda of evolved into looking at ways to fine tune the rights of the Admin role rights rather than a split per domain as it started original. Lots of ideas in there. Maybe another intermediate Admin role could be step in that direction to delegate some rights (like email management) to people which would be useful in large organisations (see my second post) without granting full admin rights ?

@marcusquinn said in Zulip - Powerful open source group chat:

Zulip threads aren't that clever, you can recreate that with sub-channels in any other chat platform,

Except that you cannot create sub-channels in Rocket.chat. You could see "Discussions" as sub-channels but they're not in terms of ux, there is no hierarchy displayed. Plus the idea is that Zulip forces to sort each message someone within a topic or as a new topic (like on email) which greatly helps with keeping the whole instance organised.
Channels in Zulip are more like placeholders within which you have topics and not somewhere you type messages, which is a level hierarchy to organise discussion that rocket.chat does not have (you could say that "Teams" in Mattermost are kinda similar in that respect - though the intended purpose is different).

@girish Particularly for Nextcloud that would be great. Apparently Nextcloud is able to sync LDAP groups, are Cloudron groups not LDAP?

@jdaviescoates I've found Collabora much better in terms of performance with recent versions (even though I am still dubious about their design choice when it comes to server / client processing). It's got also much less restrictions and prefer the default compatibility with odfs (the development seem to be faster these days too). I have stopped using OnlyOffice for quite a few month now and I don't regret it.

@fbartels Oops sorry, I should have at least tried to restart. It working fine just with restarting the app (no need to even reinstall). Thanks

@fbartels Thanks!

@fbartels it feels there is a problem with the recent version of the app. Creating public group is not available any more and people have to sign in.

I had a public group set-up, joined the call, sent the link invite but the person was asked to login. I tried the link myself in a private browser window and it was the same, I was asked to sign in (whereas usually, it worked directly).

So I deleted that group and tried to create a new one but there isn't the option any more to make the group public. Is this a bug??