9662
commented
7 years ago Please see https://github.com/owncloud/core/issues/3362, which appears to be the same issue.
Closed 9662 closed 3 years ago
9662
commented
7 years ago Please see https://github.com/owncloud/core/issues/3362, which appears to be the same issue.
MorrisJobke
commented
7 years ago @nickvergessen Is this fixed with #3141?
nickvergessen
commented
7 years ago I didn't touch deleting, but just removing people from groups. Or did I misunderstand that issue?
nickvergessen
commented
7 years ago 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
commented
7 years ago @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
commented
6 years ago @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 https://github.com/owncloud/core/issues/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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago @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
commented
6 years ago The current use-case should not be broken.
skjnldsv
commented
6 years ago So we close this? Or do we add some kind of permission for subadmins?
tessus
commented
6 years ago @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
commented
6 years ago 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 https://github.com/owncloud/core/issues/8244) and we are no closer to solving this group admin disaster.
skjnldsv
commented
6 years ago @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
commented
6 years ago 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:
delete and disable from group adminsThis should be fairly easy to accomplish and could be an interim solution while a real hierarchical solution is designed and implemented.
skjnldsv
commented
6 years ago @tessus Thanks, we'll take it in consideration! :) This was actually one of the possibilities we listed!
MorrisJobke
commented
6 years ago So we discussed a bit about this and there are multiple options how sub admins can work:
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
commented
6 years ago 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
commented
6 years ago I really do feel very strongly about this topic, thus I feel it necessary to comment on these items.
- 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.
- 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.
- 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:
- 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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.
as storage for the company The same problem tessus described with groups for projects.
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.
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
commented
6 years ago @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?
9662
commented
6 years ago @MorrisJobke
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.
Then they should not be called group admins, call them something else. Group admin implies administrative oversight over a group, not over its members—and especially not as concerns those members' rights and privileges outside the group.
carboneater
commented
6 years ago As a reporter of a duplicate of that very bug, I have to agree with @tessus' points.
My deployment scheme for NextCloud is an organization, with about 30 subgroups, of which many have intersecting users.
Those few users I have that would fit the profile of a sub-admin/limited admin, I already granted them full admin accesses already.
I can see a use case where sub-admins (because, as it's already been pointed out multiple times, they should not be termed group admins) can use as a second line to free up the big admin.
However, I believe the current naming scheme hints to what could be a third administrative layer : group managers. That's how I understood it. And it seems here there are many more that do.
The way I see it, this problem could be solved in two steps:
Rename group admins to sub admins (as @MorrisJobke calls them). This will have the added benefit of being self-explanatory. 1.1. I do however share @9662's concerns regarding the sub admins should not be able to affect users which also exist outside of their scope. Not all hierarchy is strictly vertical! (Mine sure ain't!)
Duplicate sub-admins into group managers, whose role is pretty much limited to adding/removing (not deleting) users from groups. Again, the number of bug reports filed for that very issue show a need for such a role within Nextcloud.
skjnldsv
commented
6 years ago Rename group admins to sub admins (as @MorrisJobke calls them). This will have the added benefit of being self-explanatory.
Fun fact, in our code, groups admins are define by the keyword 'subadmin' :)
carboneater
commented
6 years ago That would explain the core of the misunderstanding between NC team and the users... Renaming the role on the interface shouldn't be such a breaking change, then...
tessus
commented
6 years ago @carboneater 'renaming' is not enough, since they mix user groups with organizational groups.
You've either not read my https://github.com/nextcloud/server/issues/3630#issuecomment-380696298 or you missed some of the meaning.
No matter what, something conceptional has to be done. e.g the 1:1 relationship between a sub admin and its users and groups must be enforced.
phil-davis
commented
6 years ago When you make someone a "subadmin" of a group, then (as the full admin), you are delegating all privilege to "manage" members of that group to the "subadmin". The "subadmin" cannot add any existing users to their group, so they cannot "grab control" of anyone's account.
If a user happens to be in the "HR" group and the "Finance" group and both groups have a subadmin(s), then any of those subadmins can do privileged things to that user. The full admin decided that when they delegated authority to the "HR" subadmin and the "Finance" subadmin.
subadmin privilege is meant to let you have admin priv over a set if users. So the people with subadmin accounts, getting this delegated priv, had better be trustworthy and trained to understand their power and responsibility. If that does not happen, then do not use subadmins!
The tricky case is if you are adding "executive-director" to the HR, Finance, Administration, Factory, Warehouse... groups in order to give them access to lots of files. If that is happening, then you need to use spearate groups for file access and for subadmin-privs - e.g. have a "Finance" group that has all the people that get access to Finance files (a larger group than just Finance staff). Then have a "Finance-staff" group, of which "finance-subadmin" is the subadmin. That "Finance-staff" group is not used for granting file access, but is used as an "effectively organizational unit". Then "finance-subadmin" can manage finance-staff accounts without accidentally getting priv over the "executive-director" account.
tessus
commented
6 years ago @phil-davis that's pretty much the same thing I explained in https://github.com/nextcloud/server/issues/3630#issuecomment-380696298
This entire thing will only work, iff Nextcloud adds an additional organizational layer that also makes sure that certain areas do not intersect and/or keeps track of sets and relations.
phil-davis
commented
6 years ago Yes, but in some ways it is terminology. You can create groups that you effectively use as "organizational units" and appoint subadmins of those. And then another set of groups that you use for file access permissions and keep the 2 usages separate. As long as you manage the 2 different things, you can still have a win.
9662
commented
6 years ago You can create groups that you effectively use as "organizational units" and appoint subadmins of those. And then another set of groups that you use for file access permissions and keep the 2 usages separate.
And why would you do that? Why not identify and tackle the root cause instead?
tessus
commented
6 years ago 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
commented
5 years ago 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
commented
5 years ago @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
commented
5 years ago @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
commented
5 years ago @skjnldsv I had more than just one constructive comment. see:
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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago @skjnldsv
We have plenty of people using the groups admin the way it is currently implemented.
Evidence, please.
mtippmann
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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! :v:
John
jospoortvliet
commented
5 years ago 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:
Please note that just ranting isn't one of the options that gets either you or us any closer to a solution.
Signing status
``` Integrity checker has been disabled. Integrity cannot be verified. ```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 ```Config report
``` N/A ```Web server error log
``` Insert your webserver log here ```Nextcloud log
``` Insert your Nextcloud log here ```Browser log
``` Insert your browser log here, this could for example include: a) The javascript console log b) The network log c) ... ```