Group admin can delete users outside his group

[9662]

Steps to reproduce

1. Create groups Management, Engineering
2. Create a user, let's call her Ana
3. Make Ana a member of Engineering
4. Make Ana a group admin for Engineering (do not make her a super admin!)
5. Create another user, Bertrand
6. Make Bertrand a member of Management and Engineering
7. Log in as Ana
8. As user Ana, delete user Bertrand

Expected behaviour

Either:

• Ana should not have the option to delete user Bertrand, or
• Ana's "deletion" action should only remove Bertrand from the groups Ana is an admin of, instead of deleting the user.

Actual behaviour

Ana deletes Bertrand (without so much as a confirmation message!)

Server configuration

Operating system: openSUSE Leap 42.1 (x86_64)

Web server: nginx 1.11.9-69.1

Database: sqlite

PHP version: PHP 5.6.30

Nextcloud version: 11.0.1.2

Updated from an older Nextcloud/ownCloud or fresh install: updated from 10 or so

Where did you install Nextcloud from: Nextcloud website

Signing status:

Signing status

Integrity checker has been disabled. Integrity cannot be verified.

List of activated apps:

App list

Enabled:
  - activity: 2.4.1
  - admin_audit: 1.1.0
  - calendar: 1.5.0
  - comments: 1.1.0
  - contacts: 1.5.3
  - dav: 1.1.1
  - deck: 0.1.1
  - direct_menu: 0.10.0
  - federatedfilesharing: 1.1.1
  - federation: 1.1.1
  - files: 1.6.1
  - files_accesscontrol: 1.1.2
  - files_automatedtagging: 1.1.1
  - files_external: 1.1.2
  - files_pdfviewer: 1.0.1
  - files_retention: 1.0.1
  - files_sharing: 1.1.1
  - files_texteditor: 2.2
  - files_trashbin: 1.1.0
  - files_versions: 1.4.0
  - files_videoplayer: 1.0.0
  - firstrunwizard: 2.0
  - gallery: 16.0.0
  - logreader: 2.0.0
  - lookup_server_connector: 1.0.0
  - nextcloud_announcements: 1.0
  - notifications: 1.0.1
  - password_policy: 1.1.0
  - provisioning_api: 1.1.0
  - serverinfo: 1.1.1
  - sharebymail: 1.0.1
  - survey_client: 0.1.5
  - systemtags: 1.1.3
  - tasks: 0.9.4
  - theming: 1.1.1
  - twofactor_backupcodes: 1.0.0
  - updatenotification: 1.1.1
  - user_external: 0.4
  - workflowengine: 1.1.1
Disabled:
  - documents
  - encryption
  - external
  - templateeditor
  - user_ldap
  - user_saml

The content of config/config.php:

Config report

N/A

Are you using external storage, if yes which one: No

Are you using encryption: No

Are you using an external user-backend, if yes which one: None

Client configuration

Browser:

Operating system:

Logs

Web server error log

Web server error log

Insert your webserver log here

Nextcloud log (data/nextcloud.log)

Nextcloud log

Insert your Nextcloud log here

Browser log

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log
c) ...

[9662]

Please see owncloud/core#3362, which appears to be the same issue.

[MorrisJobke]

@nickvergessen Is this fixed with #3141?

[nickvergessen]

I didn't touch deleting, but just removing people from groups.
Or did I misunderstand that issue?

[nickvergessen]

I think you can argue that both ways are desired behaviour.
Some people might want subadmins to be able to delete users once they are not needed anymore.
Others might not. Since I'm not a fan for adding a config option for this I vote for "close as desired behaviour".

[9662]

@nickvergessen I must disagree with the following statement:

Some people might want subadmins to be able to delete users once they are not needed anymore.
Others might not.

The problem is that if deletion is allowed, the actions of subadmins are not confined to their areas of authority, hence it is not a matter of preference¹, it is a matter of deficient design.

¹ "Subadmins" with permission to delete users site-wide would be made admins of every group in the system, although in reality the problem may stem again from a suboptimal design. It appears to me that either there should be at least two kinds of administrative user: "site admin" and "group admin", or every user should be forced to belong to at least one group (at the moment it is possible for users to not belong to any groups).

[tessus]

@9662

The problem is that if deletion is allowed, the actions of subadmins are not confined to their areas of authority, hence it is not a matter of preference¹, it is a matter of deficient design.

I opened this as a bug years ago owncloud/core#8244 but unfortunately nobody took it seriously. It's a bug that destroys data. It can't be intentional, otherwise the design is so way off that the designers should never, ever touch a SW project again.

I gave up on this ever being resolved and stopped using group admins altogether. So did everybody else I know who hosts their own nextcloud/ownclud installation.

[9662]

I gave up on this ever being resolved and stopped using group admins altogether. So did everybody else I know who hosts their own nextcloud/ownclud installation.

Same here.

@nickvergessen

Some people might want subadmins to be able to delete users once they are not needed anymore.
Others might not. Since I'm not a fan for adding a config option for this I vote for "close as desired behaviour".

The fact that you are referring to those users as subadmins made me think that your mental model is possibly different than mine. For a subadmin, the current behaviour is (probably / arguably) OK-ish.

However, in my mental model, note that I am referring to Ana as a group admin, and I believe so does the user interface. As a group admin, her actions should be confined to those groups she is an admin for. Possibly including deleting the groups but without other site-wide side effects.

More than a config option, looks like what would be needed here is either clarifying the requirements and the naming (what does a "subadmin" / "group admin" do? and what is that role called?), or having two separate roles.

In my experience, I have found “group admins”¹ more useful than “subadmins”², but maybe it just depends on the specific scenarios I am familiar with.

¹ defined as “a user with administrative privileges over the specific groups he/she is an admin for, including adding and removing users from that group, and configuring other group options.”

² “a user with administrative privileges, not necessarily confined to specific groups, at a level lower than a ‘super admin.’”

[Schmuuu]

Hi,

I opened issue #7381 because I didn't notice this one right here. I'm really wondering why nothing happened here for such a long time.
When one group admin deleted another group admin with all his data by accident on my server I was really shocked and wondering how this was possible. While the intention was to "delete" the other user (actually group admin of another group) only from that very group, the user was totally deleted from the server. Of course it was possible to restore the data, but this is not funny at all.

My problem here is - and I mentioned that in my issue:
I have many groups configured on my server and each group has a group admin. Some group admins are members of other groups and furthermore there are users, who are members of many groups.
Group admins are necessary so that they can add new users to the server (and to their group). They should also be allowed to remove users from their group again and delete (in the meaning of remove) them. Remove them either from their group only or completely from the server if these users don't belong to another group any longer.
The big problem now is, that many of my users with group admin rights are not very experienced with IT stuff and a "delete" is pretty much the same as "remove" for them. Another group admin was already deleted by mistake and we need to avoid that. I can write mails to explain and I can remind the group admins of this weird behavior, but sooner or later, somebody will forget about that again.

[skjnldsv]

@MorrisJobke @nickvergessen @rullzer since I'm right in the middle of this, can we decide what behavior we want? Do we want to allow subadmins to delete users? Or should e leave it to admins only?

[nickvergessen]

The current use-case should not be broken.

[skjnldsv]

So we close this?
Or do we add some kind of permission for subadmins?

[tessus]

@nickvergessen @skjnldsv Can you please elaborate what you mean by the current use-case should not be broken?

As long as a group admins can delete users, which are a) group admin themselves or b) also belong to another group as normal users, group admins cannot be used.
Currently one can only use group admins, if all users on the system only belong to one group and there's no intersection whatsoever, which makes this feature useless in the first place - unless you want to lose data, then it's perfectly fine to use it.

[tessus]

I really would like to know in which crazy scenario the developers would seriously consider using group admins as they are currently implemented.

I mean you make me a group admin and you add yourself to that group. Then I delete your user and all your data is gone, even though you are also a group admin and belong to other groups. How do you like this? Does this make any sense?

I'm truly puzzled by this kind of design, if you can call it that. I'm sorry, if I sound a bit negative, but this issue has been open for 4 years (see owncloud/core#8244) and we are no closer to solving this group admin disaster.

[skjnldsv]

@tessus we'll have a discussion about this today :)
We all agree we need to do some work on this because there is some confusing behavior

[tessus]

I know that this is a very hot topic and there are a handful great concepts that could make group admins a very useful feature.

However, I am afraid the design and implementation will rather take a long time and as an interim workaround (see it as a pain relief) I'd suggest the following:

• deactivate delete and disable from group admins
• allow only the following 2 actions
  • add user to group
  • remove user from group

This should be fairly easy to accomplish and could be an interim solution while a real hierarchical solution is designed and implemented.

[skjnldsv]

@tessus Thanks, we'll take it in consideration! :)
This was actually one of the possibilities we listed!

[MorrisJobke]

So we discussed a bit about this and there are multiple options how sub admins can work:

1. sub admins can create users and delete users in their "view". This implies that if a user is part of a group of that admin it could be deleted. <- current way it works
2. sub admins can create users but the deletion only results in the user not being part of that group anymore. The implication is, that sub admins can add users, but a full admin is required to delete a user again.
3. there is the option to combine somehow those two: if the user is only part of the group(s) the subadmin has access to the deletion still works, but if the user is also part of another group outside of the reach of this subadmin, then the group membership is only removed. This could be made clear in the UI by showing the label according to it or not show the delete at all (because the group can also be unassigned over the group drop down)
4. the same as 2. + an option to raise the permissions of sub admins to be like in 1. again

IMO disable should always be possible for group admins but also enabled should still be possible, because then it's a non-descructive operation and should be fine.

@skjnldsv Do I have everything covered from our discussion yesterday?

@nickvergessen @blizzz Opinions?

[blizzz]

I'd 3 to stay away from config options, however it would change the current behaviour… that can be only maintained with four. I can understand the issues the reporters have, therefore leaving it like it is, is likely not that great. So → 4.

The thing with disable/enable is that it is having effects outside of the group. Yet another option? Tend to leave it instead, but it should be made clear what the action does effectively.

[tessus]

I really do feel very strongly about this topic, thus I feel it necessary to comment on these items.

1. sub admins can create users and delete users in their "view". This implies that if a user is part of a group of that admin it could be deleted. <- current way it works

In this case a user can also be deleted, when this user is part of another group. This option will create the same mess and confusion that currently exist. Also, this option means basically, leave it as is.

2. sub admins can create users but the deletion only results in the user not being part of that group anymore. The implication is, that sub admins can add users, but a full admin is required to delete a user again.

This is a much better solution, but the action should not be called 'Delete', but rather Remove.

3. there is the option to combine somehow those two: if the user is only part of the group(s) the subadmin has access to the deletion still works, but if the user is also part of another group outside of the reach of this subadmin, then the group membership is only removed. This could be made clear in the UI by showing the label according to it or not show the delete at all (because the group can also be unassigned over the group drop down)

Also a good solution, but the hardest to implement. Especially since this option also has a few additional challenges which have not been put up for discussion and unless this option is carefully designed, it will result in major troubles at some point in the future:

a few examples:

• subadmin should only be allowed to delete the user, if the user was created by the subadmin (yes/no/maybe)
  • what happens though, if the user is later also added to another group? in this case a delete would be counterproductive and will most likely not yield the desired result
• the subadmin should have the option to choose between delete and remove
• or live users created by the subadmin exclusively in the group and cannot be assigned to other groups?

4. the same as 2. + an option to raise the permissions of sub admins to be like in 1. again

This can be confusing and potentially dangerous.

IMO disable should always be possible for group admins but also enabled should still be possible, because then it's a non-descructive operation and should be fine.

Disabling is almost as bad as deleting, if the user also belongs to another group, What right does the subadmin have to revoke my access to the system? The subadmin can remove me from the group, but disabling my user, just because I'm also part of his/her group is not ok.

I really think that the term group admin or sub admin should be well defined.
Please note that this is only true for option 2. All other options allow undesired results.

Whenever a user can delete someone else, this action must be thoroughly guarded. As mentioned so many times before, it cannot be part of the design that a user can delete another user just because that user is also part of the subadmin's group.

I believe the only valid solution (out of the 4 options described above, unless these items are fleshed out and the delete action is properly guarded) is option number 2.
All other solutions will raise the same issues as we see now with the current implementation.

[MorrisJobke]

Disabling is almost as bad as deleting, if the user also belongs to another group, What right does the subadmin have to revoke my access to the system? The subadmin can remove me from the group, but disabling my user, just because I'm also part of his/her group is not ok.

I don't see this as a problem. It's basically the same as a group admin can change the quota to 0 and you are also quite limited then. That's what an group admin can do. Nothing we should be afraid of. Group admins should distribute the load of user management to more people and not restrict them, because they "have too much power". That's the whole point of group admins - they should be able to administrate.

[tessus]

I don't see this as a problem. It's basically the same as a group admin can change the quota to 0 and you are also quite limited then. That's what an group admin can do. Nothing we should be afraid of. Group admins should distribute the load of user management to more people and not restrict them, because they "have too much power". That's the whole point of group admins - they should be able to administrate.

This is eactly my point. If you want to share the load, just create a few admins. A group admin should be able to administer a group, but not affect things that are out of their purview. Quota is another example. Why should group admins be allowed to reduce my quota, just because I'm part of their group. In that case I never want to be part of someone's group, if all of a sudden, I can be deleted or my quota be reduced, even though my user existed before this group was even created.

This is what I'm talking about. A group admin must be well defined.

It comes down to one simple rule which can be used as a starting point for all other decisions. But this rule is key and paramount to access control:

A group admin must never be allowed to affect permissions/credentials/rights/access/settings out of their purview.

[MorrisJobke]

This is eactly my point. If you want to share the load, just create a few admins. A group admin should be able to administer a group, but not affect things that are out of their purview. Quota is another example. Why should group admins be allowed to reduce my quota, just because I'm part of their group. In that case I never want to be part of someone's group, if all of a sudden, I can be deleted or my quota be reduced, even though my user existed before this group was even created.

Then this is the wrong concept for you. We will not remove all the permissions of group admins. That was never the idea of group admins.

A group admin must never be allowed to affect permissions/credentials/rights/access/settings out of their purview.

Quota is still something a group admin should be able to change. Same as name or email address.

[tessus]

Then this is the wrong concept for you.

This might very well be the case, but I believe I'm starting to understand what you and the developers want this feature to be and what I and other users think it is.

I believe there's a fundamental misunderstanding, especially due to the fact that Nextcloud mixes concepts which are mutually exclusive.

How the developers see this feature

Allow users to be administered by a separate admin, in which the "group admin" can do everything an admin can do. Although I will call this an organization and its admin an org admin from now on, so that these terms are clearly distinguishable from a group and a group admin.
This can only work, if a user or a group belongs to exactly one organization (1:1).

Please note that this is not the case in Nextcloud and this is the reason for the confusion. Nextcloud mistakes organizations for groups.

How the rest of the world sees groups

For people who come from system or database administration roles, a group is a way to grant access to several people at once (or remove/revoke) that access.
A user can belong to one or more groups. A group admin is a person who can add and remove people from the group and sets privileges for resources/files/data.
A group admin can never affect data/information/rights/priviledges outside their purview.

A real life example

A company is using Nextcloud groups for different projects. Users who work on a project are a member of the project's group.
Some employees work on several projects at once, thus they are added to all groups for those projects.
All of a sudden, a group admin for project A can delete a user (or change their meta data, or change their quota, or disable a user) in project B.

Conclusion

I really would love to be able to use a whiteboard right about now.

         O                   O'                  O''        
       / | \               / | \               / | \       
     /   |   \           /   |   \           /   |   \    
    U1   U2   U3        U1'  U2'  U3'       U1'' U2'' U3''  
     \  / \   /          \  / \   /          \  / \   /   
      G1   G2             G1'  G2'            G1'' G2''     

Your concept (as Nextcloud developers see groups) will only work, if O can only manage U1, U2, U3, G1, G2. But in Nextcloud O can manage also U1', U2', U3', G1', G2', O', U1'', U2'', U3'', G1'', G2'', O''.

Therefore Nextcloud must understand set theory and relations.

There must not be any intersection between sets and there must be a distinction between a group and an organization.

e.g.: Any ' users or groups can ever intersect with non ' users and groups.
This means that U1' can never be a member of G1 or G2 or O, nor a member of G1'' or G2'' or O''.

[Schmuuu]

Hi,

I agree with tessus. Beside using NC privately myself, I'm also evaluating NC for my company; and group admins are one of a few things that still don't work for our business use cases. But neither does it work for my private installation.

1. as storage for the company
   The same problem tessus described with groups for projects.

2. as storage for customers
   Some customers (the users) belong to two companies or let's say projects as well and would need access to the data of both companies projects. While administrating that by adding and moving users every once in a while is a pain for us, it sounds like a good idea to grant this right to the customer himself via group admins. Removing the user from the group by accidentally deleting the user completely would be fatal for us.

3. my family NC server
   Please see my post far above where I already described my problem with group admins.

It seems that use cases of some functions/ features in NC are getting idealized too much. In real life scenarios permissions need to be more granular because there are a lot users out there, who know how to work with Excel, Powerpoint and Sharepoint but are in general very insecure when using computers. Software need to be foolproof to a certain point to avoid stupid mistakes of their users. At least in my point of view. But even apart from that it feels totally wrong that a group admin can delete users that belong to another group as well and should be out of scope actually.

[9662]

@blizzz commented

however it would change the current behaviour…

Which is only relevant if people are using the current behaviour in a multi-group configuration. Is there any evidence of that at all?

[tessus]

Months later....

...what has been the outcome of your internal discussions?

As mentioned before, this topic has been an issue in ownCloud for years, now it seems it will be the same with Nextcloud.

Do you guys at least understand after the comments in this issue how people outside the Nextcloud development team understand groups and how administration works? (This was not sarcasm, nor being facetious. This is an honest question.)

[TomTurnschuh]

I also expected another concept of group admins for a long time. Now I'm not using it anymore as I don't see a benefit but rather a risk in the current implementation. Still, I would appreciate a new "logical" concept of group administration.

[tessus]

@TomTurnschuh almost everyone who is in IT and understands groups has an issue with Nextcloud's group admin implementation. Unfortunately this is one of the topics that have been ignored for years. I opened the first one 4 or 5 years ago with owncloud. there's always some sort of promise that the developers will review and look into it, but then the discussions are suspended and the problem ignored due to more important, new features.

IMO they are afraid to admit that their design in this regard is utterly flawed and should have never been implemented in this way. some devs still think that their concept makes sense and therefore this will never be resolved or fixed. It is working as designed. It's unfortunate, but true.

The only thing you can do is NOT using group admins (like the rest of the world).

The developers have never proven or even stated that anyone in their right mind is actually using their group admin implementation. Yet again, I believe the only people who are using it are themselves.

I have given up and don't even try to touch this topic anymore. Now and then I add a comment to vent a little, but that's it.

[skjnldsv]

@tessus you're the opposite of being constructive and I really hate that.

IMO they are afraid to admit that their design in this regard is utterly flawed and should have never been implemented in this way. some devs still think that their concept makes sense and therefore this will never be resolved or fixed. It is working as designed. It's unfortunate, but true.

Oh no, we completely agree that there is something to be done here. Otherwise this topic would have been close for a long time. We have plenty of people using the groups admin the way it is currently implemented. That doesn't mean we don't need to change something anyway, but this is a blocker for us.

I have given up and don't even try to touch this topic anymore. Now and then I add a comment to vent a little, but that's it.

Please stop, unless you really have a real solution for this.
If you plan to just go here and rant, we'll just close this ticket or hide your messages. We're a collaborative project. Feel free to do something concrete. Insulting the work of others won't do anything else than insulting the people that worked for this project.

[tessus]

@skjnldsv I had more than just one constructive comment. see:

1. Group admin can delete users outside his group #3630 (comment)
2. Group admin can delete users outside his group #3630 (comment)
3. Group admin can delete users outside his group #3630 (comment)

They just got ignored as always. The only time one of you devs are responding is when you are angry about my comments. And yes, it is a community project. This also means you should be listening to the community instead of mocking anyone who thinks that there's room for improvement and points out the issues.

Oh no, we completely agree that there is something to be done here.

Seriously, you devs have been agreeing for several years now that something has to be done? You must be joking.

Please stop, unless you really have a real solution for this.

I do and I have already written down the solution. (see section Conclusion in 3. above)

If you plan to just go here and rant, we'll just close this ticket or hide your messages.

I don't plan to just rant, but maybe you want to read my comments where I don't rant. It's not fair just looking at those and threaten to block me.

[skjnldsv]

You do realise that because no work have been done on this feature yet doesn't mean we disagree with what have been suggested, right?
There are like 500+ features requests all over this repo, do you expect us to fill them all?

Whatever your opinion is on this, your messages are really out of place and hurtful.
We thought about this issue, we came up with various solutions, including yours, and we still don't have this as one of our priority. End of story. Please stop posting messages that make us loose the will to work on this issue or make us feel like sh**. That would be nice, thanks.

[tessus]

There are like 500+ features requests all over this repo, do you expect us to fill them all?

No I don't, but since this has been open for almost 5 years (this group admin discussion started when the project was still ownCloud) one could expect that it has the highest priority. Instead new features are implemented instead of fixing this one.

No worries, I have unsubscribed from this thread. I won't be posting anymore.

[9662]

@skjnldsv

We have plenty of people using the groups admin the way it is currently implemented.

Evidence, please.

[mtippmann]

This bug is a huge problem if you run a decentralized nextcloud instance with lot's of different groups that can and should govern itself. It's not an issue if you just plug Nextcloud into the corporate LDAP/university shibboleth...

It probably won't happen because most users that need this can't pay for it but if you think about re-organising the permission system please design it in such a way that such decentralized usecases are possible.

I'm writing this comment after mailing this issue with a warning to be careful in group-admin to the tenth person over the past year now...

You are doing great work, but I think stuff like this should just work (tm) out of box or at least should be possible in the permission model. talk is cheap, I know but powerful decentralized administration would be a huge feature for Nextcloud.

[Fiech]

Without wanting to tread on poisoned ground, I still want to at least chime in with my 2cents:

I too would and did not expect group admins to be able to register / remove users from the instance, but much rather manage the group. So adding / removing users to and from groups. Nothing more.

And in our use case of a collaboration tool for a somewhat large volunteer organization and only a small team of (equally volunteer) support agents this would actually be how we'd love to employ this, but cannot due to the current high permission set of group admins.

Maybe this is what the circles app is supposed to be for in the future? Although without the ability to create your own circles unsupervised.

So my question: Is the concept of a single checkbox (defaults to false), which removes the group admin's permission to register / remove users to / from the instance completely out of the question? Or would it be a feature which it would be worthwhile to work on or at least come up with a plan?

[teqqat]

Good morning,

being the systems administrator of an educational facility we use Nextcloud for our file sharing needs, avoiding sharepoint like the devil. :)

Aside from the usual smaller problems, not having what was called Group MANAGERS, meaning admins that can add and remove users from the group they are given manager rights is indeed quite a problem. We are using circles by now, but not all apps can use them (eg. Talk), and it seems the development of the circles has somewhat faded away.

Reading this thread and the time that passed since this issue was brought up seems to leave only the way of programming something using the OCC API which can create groups and add / remove users from them - without letting the group admins in the main GUI delete people from the whole system. Either a separate php script with EXECs will be needed - or an App that adds the functionality to the main system. We will see into that.

In total NC is a great system that we use on a very large scale, also considerung buying a support contract to support what we use (we have an OpenSource policy here), but why there is not, as mentioned, a new layer that allows groups to be maintained by such group managers and having a separate sub admin level as it is by now is a bit beyond my understanding.

With regards, teqq.at

[richard-dg]

Good Morning Everyone,

I just stumbled about this issue. For me it is a big problem that my group admins can completely delete users and all their data even if they are members in other groups as well.

Let's say Paul is member of GroupA and GroupB. In Group A he is not needed anymore so groupadminA thinks it is fine to delete Paul. But groupadminA doesn't know that Paul is the owner of a calendar and some important files that he shares with group B. So groupadminA can interfere with Group B's work without even knowing. Even if Paul is groupadmin for GroupB groupadminA can delete him.

I consider this very dangerous and in no case desired behaviour so I would be very glad if there could you developers could think this over and keep this on the roadmap.

Thanks a lot,

Richie

[teqqat]

Good morning,

it IS dangerous. We are an educational institution with 500 employees and over 4000 students, and you can imagine my surprise when students were deleted not only from groups by our tutors but from the complete system. Took quite some time to find out what happened there and almost gave our SharePoint-Advocates a good edge...

We are currently using Circles, with the drawback that we have no OCC hook to automatically add students to their circles and giving them file share access to the departments and tutors shares. The latter are done by OCC semi-manually. LDAP is in reconstruction, thou - but that still does not allow self-management by the tutors for their very own groups.

Have a nice day, teqq

[9662]

In the meanwhile, I'm still waiting for evidence from @skjnldsv that

We have plenty of people using the groups admin the way it is currently implemented.

As I understand, that sole assertion is the entire reason why nothing has been done in this matter, but not a shred of evidence has been provided that the assertion is indeed true (let alone germane), as opposed to the many statements from actual, everyday users presented in this discussion.

[skjnldsv]

As I understand, that sole assertion is the entire reason why nothing has been done in this matter, but not a shred of evidence has been provided that the assertion is indeed true (let alone germane), as opposed to the many statements from actual, everyday users presented in this discussion.

That is not how I'm used to collaborate with people. Please keep it civil or we'll lock this thread.
I won't implement this feature as this is not my priority nor my will at the moment.
This project does not belong to me but to everyone. If you want a feature, you can still code it yourself and suggest a pull request. For now this won't receive any work from my part.

Thanks for everyone that replied with constructive comments! ✌️

John

[jospoortvliet]

Hi,

Can I ask everyone to stay friendly please? Consider everyone here a volunteer, including Nextcloud GmbH employees - we are only employed to work for our customers, not everyone on the internet. If a customer had an issue with this feature, we would of course have resolved it. As that is not the case, we have to focus our efforts on the countless other things to work on.

Also, while I realize it is work and takes time for you, please dont' consider adding your opinions or needs a contribution. We have plenty of opinions and feature ideas that we are working on, so generally we only implement what fits our strategic plans or what customers ask for. As this turned out to be expected and intended behavior, this issue is a feature request and thus low priority. Anyhow, on to the subject.

I think that the use case many of you have, as described by @teqqat is indeed covered by circles. I know circles doesn't work in all apps, we've got this on our roadmap to improve and integrate deeper. Nextcloud 16 will already make some steps in that direction. Another part will be the guest app, which is ready for 16 as well.

Renaming the 'group admin' to 'sub admin' will probably take care of most of the confusion here and we'll probably do that.

For the rest - well, if you have needs that are not covered (and I'm sure some of you do), you have no less than five options:

• contribute code (or pay someone to do so)
• purchase a Subscription to influence our roadmap
• hire us to make the changes
• wait until somebody else does one of the above
• use another product (of course, that would be 😢 )

Please note that just ranting isn't one of the options that gets either you or us any closer to a solution.

[nickvergessen]

STOP!

[szaimen]

As this sounds like a nice feature, currently there are no plans to implement such a feature. Thus I will close this ticket for now. This does not mean we don't want this feature, but it is simply not on our roadmap for the near future. If somebody wants to implement this feature nevertheless we are happy to assist and help out.

If you wish to have this feature implemented by the Nextcloud GmbH there is the option for consulting work on top of your Nextcloud Enterprise subscription to get your features implemented.