subadmin and make him subadmin of a group new-groupperform curl http://subadmin:[email protected]/ocs/v1.php/cloud/groups -d groupid="newgroup"
and see there is status code is 100 in API-v1 and 200 in API-v2
newgroupSubadmin should not be able to create new group
Subadmin can create new group
Operating system: 17.10
Web server: Apache
Database: MySQL
PHP version: 7.1
ownCloud version: (see ownCloud admin page) 10.1.0
Where did you install ownCloud from: git
When I ran
curl http://subadmin:123456@localhost:80/core/ocs/v1.php/cloud/groups -d groupid="newgroup"
I got
<?xml version="1.0"?>
<ocs>
<meta>
<status>ok</status>
<statuscode>100</statuscode>
<message/>
</meta>
<data/>
</ocs>
GitMate.io thinks the contributor most likely able to help you is @phil-davis.
Possibly related issues are https://github.com/owncloud/core/pull/31263 (API test to test userprovisioning API-v2), https://github.com/owncloud/core/issues/29698 (a group called "0" cannot be created by provisioning API), https://github.com/owncloud/core/issues/31276 (Unusual response(997) from userprovisioning api-v2 ), https://github.com/owncloud/core/pull/29712 (Allow group 0 to be created by provisioning API), and https://github.com/owncloud/core/issues/4885 (Create a version for each public api class).
We were a bit surprised about this. But I suppose that it just allows sub-admins to create group names without needing to bother the all-powerful admin.
Is there a requirements spec somewhere for what sub-admins should and should not be able to do?
Then we will know if the behavior is by design, or unintended.
Does the subadmin have the option of creating groups in the web UI ? This is unlikely.
I don't think this is by design...
In the webUI a subadmin does not see the add group box. So cannot add groups.
Note: we have not yet tested the "private" API that the webUI uses to do all this sort of user/group provisioning stuff. So it is possible that that "private" API behaves in some interesting ways. But that is hidden from the everyday webUI user, unless they hack around changing the AJAX/POST etc stuff that happens from their browser. When we get the provisioning API behavior sorted, then we should test equivalent actions attempted via the "private" API.
馃槧 - I hope with phoenix we can finally get rid of "public" vs "private" api - and only have api so there can't be any difference
Agree - and the term "private API" is a misnomer. It is open-source code, so hardly "private". Anyone can read the code and then try interesting ways to make use of it.
I was more interested in having a unified codepath to be used by frontend and other parts
@PVince81 Estimate : 1md.
Closing this issue as the changes got merged
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
馃槧 - I hope with phoenix we can finally get rid of "public" vs "private" api - and only have api so there can't be any difference