<div dir="ltr"><div><div>Is there any reason why we don't use an full RBAC(Role Based Access Control) implementation so that groups could be granted any priviledges? We could separate many admin functions so that different use cases could pick and choose what certain users could create. For example, help desks should be able to create users and modify but not do much more to the installation itself.<br>
<br></div>If we went to an RBAC model, many of the questions that come up(can I make a group/user only have this permission) would be addressed.<br></div>Mike<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Apr 24, 2013 at 6:31 AM, Erwin Rennert <span dir="ltr"><<a href="mailto:rennert@zsi.at" target="_blank">rennert@zsi.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 04/24/2013 11:52 AM, Andreas Ergenzinger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello everyone,<br>
<br>
I would like to know what people's feelings are about the ability of<br>
subadmins (a.k.a. group admins) to create new user accounts. Should<br>
all subadmins always be able to do that? Or should that privilege<br>
require explicit permission from the (super) admin, possibly on an<br>
individual basis.<br>
</blockquote>
<br></div>
Hi!<br>
I believe use cases vastly differ.<br>
I would prefer the super admin being able to decide, whether the group admin may create users.<br>
<br>
However, there are a number of other questions regarding groups and their administration.<br>
<br>
* As of now, IF a group admin knows the exact user ID of another user on the system, s/he may actually add this user to his/her group by "creating" a userID with a random password.<br>
** Is this desirable?<br>
* The group admin may also extend or reduce the user's quota.<br>
** In my view this is definitely undesirable. The quota should stick at the default setting, or even better, the site admin should set a group quota.<br>
* Group quota: Here we go!<br>
** there is a feature request: <a href="https://github.com/owncloud/core/issues/1347" target="_blank">https://github.com/owncloud/<u></u>core/issues/1347</a><br>
** Now in my view, existing users should be exempt from the group quota; after all they may be members of various groups.<br>
<br>
Lots of difficult questions.<br>
<br>
Yours,<br>
Erwin<div class="im HOEnZb"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am asking because I see a conflict here, between using groups with<br>
subadmins and the admin's desire to manage the whole user base with<br>
user backends.<br>
<br>
Since I would like to have both, I would be willing to implement the<br>
necessary changes, but I would like to know the exact requirements<br>
first and whether this has any chance of making it to the core.<br>
<br>
Cheers, Andreas ______________________________<u></u>_________________<br>
Owncloud mailing list <a href="mailto:Owncloud@kde.org" target="_blank">Owncloud@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/owncloud" target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/owncloud</a><br>
</blockquote>
<br>
<br></div><span class="HOEnZb"><font color="#888888">
-- <br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
Erwin Rennert, IT Services<br>
Center for Social Innovation<br>
<br>
A-1150 Wien, Linke Wienzeile 246<br>
Austria, Europe<br>
<br>
Phone: ++43-1-495 04 42 - 61<br>
Facsimile: ++43-1-495 04 42 - 40<br>
<a href="http://www.zsi.at/" target="_blank">http://www.zsi.at/</a></font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Owncloud mailing list<br>
<a href="mailto:Owncloud@kde.org" target="_blank">Owncloud@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/owncloud" target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/owncloud</a><br>
</div></div></blockquote></div><br></div>