From a8c434e29a47a04df684e0dfda1b960f05f10a32 Mon Sep 17 00:00:00 2001 From: sakshamgurung Date: Wed, 18 Aug 2021 17:23:32 +0545 Subject: [PATCH] adds @notToImplementOnOCIS tag for subadmin scenarios --- .../apiProvisioning-v1/addUser.feature | 6 +++--- .../apiProvisioning-v1/createSubAdmin.feature | 8 ++++---- .../apiProvisioning-v1/deleteUser.feature | 18 +++++++++--------- .../apiProvisioning-v1/disableUser.feature | 4 ++-- .../apiProvisioning-v1/editUser.feature | 6 +++--- .../apiProvisioning-v1/getSubAdmins.feature | 2 +- .../apiProvisioning-v1/getUser.feature | 4 ++-- .../resetUserPassword.feature | 8 ++++---- .../apiProvisioning-v2/addUser.feature | 6 +++--- .../apiProvisioning-v2/createSubAdmin.feature | 2 +- .../apiProvisioning-v2/deleteUser.feature | 10 +++++----- .../apiProvisioning-v2/disableUser.feature | 8 ++++---- .../apiProvisioning-v2/editUser.feature | 6 +++--- .../apiProvisioning-v2/enableUser.feature | 8 ++++---- .../apiProvisioning-v2/getSubAdmins.feature | 2 +- .../apiProvisioning-v2/getUser.feature | 6 +++--- .../resetUserPassword.feature | 8 ++++---- .../apiProvisioningGroups-v1/addGroup.feature | 4 ++-- .../addToGroup.feature | 6 +++--- .../deleteGroup.feature | 2 +- .../apiProvisioningGroups-v1/getGroup.feature | 4 ++-- .../apiProvisioningGroups-v1/getGroups.feature | 2 +- .../getSubAdminGroups.feature | 2 +- .../getUserGroups.feature | 2 +- .../removeFromGroup.feature | 4 ++-- .../apiProvisioningGroups-v2/addGroup.feature | 4 ++-- .../addToGroup.feature | 6 +++--- .../deleteGroup.feature | 2 +- .../apiProvisioningGroups-v2/getGroup.feature | 4 ++-- .../apiProvisioningGroups-v2/getGroups.feature | 2 +- .../getSubAdminGroups.feature | 2 +- .../getUserGroups.feature | 2 +- .../removeFromGroup.feature | 4 ++-- 33 files changed, 82 insertions(+), 82 deletions(-) diff --git a/tests/acceptance/features/apiProvisioning-v1/addUser.feature b/tests/acceptance/features/apiProvisioning-v1/addUser.feature index d51346f340fb..0671e9b2d7b6 100644 --- a/tests/acceptance/features/apiProvisioning-v1/addUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/addUser.feature @@ -155,7 +155,7 @@ Feature: add user | 123 | | -123 | | 0.0 | - + @notToImplementOnOCIS Scenario: subadmin should not be able to create a new user Given user "brand-new-user" has been deleted And user "subadmin" has been created with default attributes and without skeleton files @@ -174,7 +174,7 @@ Feature: add user Then the OCS status code should be "997" And the HTTP status code should be "401" And user "brand-new-user" should not exist - + @notToImplementOnOCIS Scenario: subadmin should be able to create a new user into their group Given user "brand-new-user" has been deleted And user "subadmin" has been created with default attributes and without skeleton files @@ -185,7 +185,7 @@ Feature: add user Then the OCS status code should be "100" And the HTTP status code should be "200" And user "brand-new-user" should exist - + @notToImplementOnOCIS Scenario: subadmin should not be able to create a new user into other group Given user "brand-new-user" has been deleted And user "subadmin" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature index c9584cd055b3..2b34fead7b94 100644 --- a/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature +++ b/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature @@ -1,4 +1,4 @@ -@api @provisioning_api-app-required @skipOnLDAP +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS Feature: create a subadmin As an admin I want to be able to make a user the subadmin of a group @@ -47,9 +47,9 @@ Feature: create a subadmin Scenario: normal user should not be able to make another user a subadmin Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | + | username | + | Alice | + | Brian | And group "group101" has been created When user "Alice" makes user "Brian" a subadmin of group "group101" using the provisioning API Then the OCS status code should be "997" diff --git a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature index 0d455b30895a..7bda8a1e6e5a 100644 --- a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature @@ -65,14 +65,14 @@ Feature: delete users Scenario: administrator deletes another admin user Given these users have been created with default attributes and without skeleton files: - | username | - | another-admin | + | username | + | another-admin | And user "another-admin" has been added to group "admin" When the administrator deletes user "another-admin" using the provisioning API Then the OCS status code should be "100" And the HTTP status code should be "200" And user "another-admin" should not exist - + @notToImplementOnOCIS Scenario: subadmin deletes a user with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -86,7 +86,7 @@ Feature: delete users Then the OCS status code should be "100" And the HTTP status code should be "200" And user "another-subadmin" should not exist - + @notToImplementOnOCIS Scenario: subadmin should not be able to delete another subadmin of same group Given these users have been created with default attributes and without skeleton files: | username | @@ -99,12 +99,12 @@ Feature: delete users Then the OCS status code should be "997" And the HTTP status code should be "401" And user "another-subadmin" should exist - + @notToImplementOnOCIS Scenario: subadmin should not be able to delete a user with admin permissions in their group Given these users have been created with default attributes and without skeleton files: - | username | - | subadmin | - | another-admin | + | username | + | subadmin | + | another-admin | And user "another-admin" has been added to group "admin" And group "new-group" has been created And user "another-admin" has been added to group "new-group" @@ -113,7 +113,7 @@ Feature: delete users Then the OCS status code should be "997" And the HTTP status code should be "401" And user "another-admin" should exist - + @notToImplementOnOCIS Scenario: subadmin should not be able to delete a user not in their group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioning-v1/disableUser.feature b/tests/acceptance/features/apiProvisioning-v1/disableUser.feature index 03d99fca5dfb..3e1aa193fdce 100644 --- a/tests/acceptance/features/apiProvisioning-v1/disableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/disableUser.feature @@ -256,7 +256,7 @@ Feature: disable user | old | | new | - + @notToImplementOnOCIS Scenario: Subadmin should be able to disable user with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -271,7 +271,7 @@ Feature: disable user And the HTTP status code should be "200" And user "another-subadmin" should be disabled - + @notToImplementOnOCIS Scenario: Subadmin should not be able to disable another subadmin of same group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioning-v1/editUser.feature b/tests/acceptance/features/apiProvisioning-v1/editUser.feature index 91961bf3fa52..62ff67e646c9 100644 --- a/tests/acceptance/features/apiProvisioning-v1/editUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/editUser.feature @@ -127,7 +127,7 @@ Feature: edit users And the attributes of user "brand-new-user" returned by the API should include | quota definition | default | And the quota definition of user "brand-new-user" should be "default" - + @notToImplementOnOCIS Scenario: the administrator can edit user information with admin permissions Given these users have been created with default attributes and without skeleton files: | username | @@ -139,7 +139,7 @@ Feature: edit users Then the display name of user "another-admin" should be "Anne Brown" And the email address of user "another-admin" should be "another-admin@example.com" And the quota definition of user "another-admin" should be "12 MB" - + @notToImplementOnOCIS Scenario: a subadmin should be able to edit user information with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -155,7 +155,7 @@ Feature: edit users Then the display name of user "another-subadmin" should be "Anne Brown" And the email address of user "another-subadmin" should be "brand-new-user@example.com" And the quota definition of user "another-subadmin" should be "12 MB" - + @notToImplementOnOCIS Scenario: a subadmin should not be able to edit user information of another subadmin of same group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature b/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature index d6eb5c2e6b6c..59f79f00a345 100644 --- a/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature +++ b/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature @@ -1,4 +1,4 @@ -@api @provisioning_api-app-required @skipOnLDAP +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS Feature: get subadmins As an admin I want to be able to get the list of subadmins of a group diff --git a/tests/acceptance/features/apiProvisioning-v1/getUser.feature b/tests/acceptance/features/apiProvisioning-v1/getUser.feature index d1755844a282..89512dc422d5 100644 --- a/tests/acceptance/features/apiProvisioning-v1/getUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/getUser.feature @@ -151,7 +151,7 @@ Feature: get user And the HTTP status code should be "200" And the display name returned by the API should be "Admin Alice" And the quota definition returned by the API should be "default" - + @notToImplementOnOCIS Scenario: a subadmin should be able to get information of a user with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -166,7 +166,7 @@ Feature: get user And the HTTP status code should be "200" And the display name returned by the API should be "Regular User" And the quota definition returned by the API should be "default" - + @notToImplementOnOCIS Scenario: a subadmin should not be able to get information of another subadmin of same group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature index 43ff06f96edc..aa18525102a5 100644 --- a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature +++ b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature @@ -24,7 +24,7 @@ Feature: reset user password Then the OCS status code should be "997" And the HTTP status code should be "401" - @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57 @toImplementOnOCIS + @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS Scenario: subadmin should be able to reset the password of a user in their group Given these users have been created with small skeleton files: | username | password | displayname | email | @@ -39,7 +39,7 @@ Feature: reset user password And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" - @toImplementOnOCIS + @notToImplementOnOCIS Scenario: subadmin should not be able to reset the password of a user not in their group Given these users have been created with small skeleton files: | username | password | displayname | email | @@ -109,7 +109,7 @@ Feature: reset user password And the content of file "textfile0.txt" for user "Alice" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line But user "Alice" using password "%regular%" should not be able to download file "textfile0.txt" - @skipOnEncryptionType:user-keys @encryption-issue-57 + @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS Scenario: subadmin should be able to reset the password of a user with subadmin permissions in their group Given these users have been created with small skeleton files: | username | password | displayname | email | @@ -125,7 +125,7 @@ Feature: reset user password And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" - + @notToImplementOnOCIS Scenario: subadmin should not be able to reset the password of another subadmin of same group Given these users have been created with small skeleton files: | username | password | displayname | email | diff --git a/tests/acceptance/features/apiProvisioning-v2/addUser.feature b/tests/acceptance/features/apiProvisioning-v2/addUser.feature index 65f0da6a38c8..0b9b7e9921b7 100644 --- a/tests/acceptance/features/apiProvisioning-v2/addUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/addUser.feature @@ -155,7 +155,7 @@ Feature: add user | 123 | | -123 | | 0.0 | - + @notToImplementOnOCIS Scenario: subadmin should not be able to create a user Given user "brand-new-user" has been deleted And user "subadmin" has been created with default attributes and without skeleton files @@ -174,7 +174,7 @@ Feature: add user Then the OCS status code should be "997" And the HTTP status code should be "401" And user "brand-new-user" should not exist - + @notToImplementOnOCIS Scenario: subadmin should be able to create a new user into their group Given user "brand-new-user" has been deleted And user "subadmin" has been created with default attributes and without skeleton files @@ -185,7 +185,7 @@ Feature: add user Then the OCS status code should be "200" And the HTTP status code should be "200" And user "brand-new-user" should exist - + @notToImplementOnOCIS Scenario: subadmin should not be able to create a new user into other group Given user "brand-new-user" has been deleted And user "subadmin" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature index d1dd0ac1863b..696ddbe92a3c 100644 --- a/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature +++ b/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature @@ -1,4 +1,4 @@ -@api @provisioning_api-app-required @skipOnLDAP +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS Feature: create a subadmin As an admin I want to be able to make a user the subadmin of a group diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature index 9ad3c7450ef9..647c51f365c0 100644 --- a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature @@ -63,7 +63,7 @@ Feature: delete users Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should exist - + @notToImplementOnOCIS Scenario: administrator deletes another admin user Given these users have been created with default attributes and without skeleton files: | username | @@ -73,7 +73,7 @@ Feature: delete users Then the OCS status code should be "200" And the HTTP status code should be "200" And user "another-admin" should not exist - + @notToImplementOnOCIS Scenario: subadmin deletes a user with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -87,7 +87,7 @@ Feature: delete users Then the OCS status code should be "200" And the HTTP status code should be "200" And user "another-subadmin" should not exist - + @notToImplementOnOCIS Scenario: subadmin should not be able to delete another subadmin of same group Given these users have been created with default attributes and without skeleton files: | username | @@ -100,7 +100,7 @@ Feature: delete users Then the OCS status code should be "997" And the HTTP status code should be "401" And user "another-subadmin" should exist - + @notToImplementOnOCIS Scenario: subadmin should not be able to delete a user with admin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -114,7 +114,7 @@ Feature: delete users Then the OCS status code should be "997" And the HTTP status code should be "401" And user "another-admin" should exist - + @notToImplementOnOCIS Scenario: subadmin should not be able to delete a user not in their group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature index bd830b53f813..ab64353d1fee 100644 --- a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature @@ -47,7 +47,7 @@ Feature: disable user And the HTTP status code should be "200" And user "Alice" should be disabled - @issue-31276 @skipOnOcV10 + @issue-31276 @skipOnOcV10 @notToImplementOnOCIS Scenario: Subadmin should not be able to disable an user not in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -63,7 +63,7 @@ Feature: disable user And the HTTP status code should be "401" And user "Alice" should be enabled - @issue-31276 @skipOnOcV10 + @issue-31276 @skipOnOcV10 @notToImplementOnOCIS Scenario: Subadmins should not be able to disable users that have admin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -253,7 +253,7 @@ Feature: disable user | old | | new | - + @notToImplementOnOCIS Scenario: Subadmin should be able to disable user with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -268,7 +268,7 @@ Feature: disable user And the HTTP status code should be "200" And user "another-subadmin" should be disabled - + @notToImplementOnOCIS Scenario: Subadmin should not be able to disable another subadmin of same group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioning-v2/editUser.feature b/tests/acceptance/features/apiProvisioning-v2/editUser.feature index 18d73b5bdc2e..65f87e2c2f75 100644 --- a/tests/acceptance/features/apiProvisioning-v2/editUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/editUser.feature @@ -127,7 +127,7 @@ Feature: edit users And the attributes of user "brand-new-user" returned by the API should include | quota definition | default | And the quota definition of user "brand-new-user" should be "default" - + @notToImplementOnOCIS Scenario: the administrator can edit user information with admin permissions Given these users have been created with default attributes and without skeleton files: | username | @@ -139,7 +139,7 @@ Feature: edit users Then the display name of user "another-admin" should be "Anne Brown" And the email address of user "another-admin" should be "another-admin@example.com" And the quota definition of user "another-admin" should be "12 MB" - + @notToImplementOnOCIS Scenario: a subadmin should be able to edit user information with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -155,7 +155,7 @@ Feature: edit users Then the display name of user "another-subadmin" should be "Anne Brown" And the email address of user "another-subadmin" should be "brand-new-user@example.com" And the quota definition of user "another-subadmin" should be "12 MB" - + @notToImplementOnOCIS Scenario: a subadmin should not be able to edit user information of another subadmin of same group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature index ed628cb1f076..0f00fb99b52b 100644 --- a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature @@ -106,7 +106,7 @@ Feature: enable user Then the OCS status code should be "997" And the HTTP status code should be "401" And user "Alice" should be disabled - + @notToImplementOnOCIS Scenario: subadmin should be able to enable user in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -120,7 +120,7 @@ Feature: enable user Then the OCS status code should be "200" And the HTTP status code should be "200" And user "Alice" should be enabled - + @notToImplementOnOCIS Scenario: subadmin should not be able to enable user not in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -133,7 +133,7 @@ Feature: enable user Then the OCS status code should be "997" And the HTTP status code should be "401" And user "Alice" should be disabled - + @notToImplementOnOCIS Scenario: subadmin should be able to enable user with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -148,7 +148,7 @@ Feature: enable user Then the OCS status code should be "200" And the HTTP status code should be "200" And user "Alice" should be enabled - + @notToImplementOnOCIS Scenario: subadmin should not be able to enable another subadmin of same group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature b/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature index 225406bc4bea..86ce862a3cfc 100644 --- a/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature +++ b/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature @@ -1,4 +1,4 @@ -@api @provisioning_api-app-required @skipOnLDAP +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS Feature: get subadmins As an admin I want to be able to get the list of subadmins of a group diff --git a/tests/acceptance/features/apiProvisioning-v2/getUser.feature b/tests/acceptance/features/apiProvisioning-v2/getUser.feature index 1a02eff2e7e8..7dde09708045 100644 --- a/tests/acceptance/features/apiProvisioning-v2/getUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/getUser.feature @@ -141,7 +141,7 @@ Feature: get user And the HTTP status code should be "200" And the display name returned by the API should be "New User" And the quota definition returned by the API should be "default" - + @notToImplementOnOCIS Scenario: admin gets information of a user with admin permissions Given these users have been created with default attributes and without skeleton files: | username | displayname | @@ -152,7 +152,7 @@ Feature: get user And the HTTP status code should be "200" And the display name returned by the API should be "Admin Alice" And the quota definition returned by the API should be "default" - + @notToImplementOnOCIS Scenario: a subadmin should be able to get information of a user with subadmin permissions in their group Given these users have been created with default attributes and without skeleton files: | username | @@ -167,7 +167,7 @@ Feature: get user And the HTTP status code should be "200" And the display name returned by the API should be "Regular User" And the quota definition returned by the API should be "default" - + @notToImplementOnOCIS Scenario: a subadmin should not be able to get information of another subadmin of same group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature b/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature index 8ed6be483649..8fd1fdb6efe3 100644 --- a/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature +++ b/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature @@ -39,7 +39,7 @@ Feature: reset user password And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" - @toImplementOnOCIS + @notToImplementOnOCIS Scenario: subadmin should not be able to reset the password of a user not in their group Given these users have been created with small skeleton files: | username | password | displayname | email | @@ -97,7 +97,7 @@ Feature: reset user password Then the OCS status code should be "998" And the HTTP status code should be "404" - @skipOnEncryptionType:user-keys @encryption-issue-57 + @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS Scenario: admin resets password of user with admin permissions Given these users have been created with small skeleton files: | username | password | displayname | email | @@ -109,7 +109,7 @@ Feature: reset user password And the content of file "textfile0.txt" for user "Alice" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line But user "Alice" using password "%regular%" should not be able to download file "textfile0.txt" - @skipOnEncryptionType:user-keys @encryption-issue-57 + @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS Scenario: subadmin should be able to reset the password of a user with subadmin permissions in their group Given these users have been created with small skeleton files: | username | password | displayname | email | @@ -125,7 +125,7 @@ Feature: reset user password And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" - + @notToImplementOnOCIS Scenario: subadmin should not be able to reset the password of another subadmin of same group Given these users have been created with small skeleton files: | username | password | displayname | email | diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature index 18603248df6f..4df4a0f9f8d2 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature @@ -123,7 +123,7 @@ Feature: add groups # A group name must not end in "/subadmins" because that would create ambiguity # with the endpoint for getting the subadmins of a group - @issue-31015 @skipOnOcV10 + @issue-31015 @skipOnOcV10 @notToImplementOnOCIS Scenario: admin tries to create a group with name ending in "/subadmins" Given group "brand-new-group" has been created When the administrator tries to send a group creation request for group "priv/subadmins" using the provisioning API @@ -144,7 +144,7 @@ Feature: add groups Then the OCS status code should be "997" And the HTTP status code should be "401" And group "brand-new-group" should not exist - + @notToImplementOnOCIS Scenario: subadmin tries to create a group Given user "subadmin" has been created with default attributes and without skeleton files And group "brand-new-group" has been created diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature index 67cfe15e1986..a3fffb4f5f6c 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature @@ -172,7 +172,7 @@ Feature: add users to group And the HTTP status code should be "200" And the API should not return any data - @skipOnLDAP + @skipOnLDAP @notToImplementOnOCIS Scenario: a subadmin cannot add users to groups the subadmin is responsible for Given these users have been created with default attributes and without skeleton files: | username | @@ -185,7 +185,7 @@ Feature: add users to group And the HTTP status code should be "200" And user "brand-new-user" should not belong to group "brand-new-group" - @skipOnLDAP + @skipOnLDAP @notToImplementOnOCIS Scenario: a subadmin cannot add users to groups the subadmin is not responsible for Given these users have been created with default attributes and without skeleton files: | username | @@ -199,7 +199,7 @@ Feature: add users to group And the HTTP status code should be "200" And user "brand-new-user" should not belong to group "brand-new-group" - @skipOnLDAP @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 + @skipOnLDAP @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @notToImplementOnOCIS Scenario: a subadmin can add users to other groups the subadmin is responsible for Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature index 3f97508fc203..3c6fea07b21a 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature @@ -95,7 +95,7 @@ Feature: delete groups Then the OCS status code should be "997" And the HTTP status code should be "401" And group "brand-new-group" should exist - + @notToImplementOnOCIS Scenario: subadmin of the group tries to delete the group Given user "subadmin" has been created with default attributes and without skeleton files And group "brand-new-group" has been created diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature index 4992176fa0f4..faab843c48c2 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature @@ -51,7 +51,7 @@ Feature: get group | CASE-SENSITIVE-GROUP | Case-Sensitive-Group | | CASE-SENSITIVE-GROUP | case-sensitive-group | - @smokeTest + @smokeTest @notToImplementOnOCIS Scenario: subadmin gets users in a group they are responsible for Given these users have been created with default attributes and without skeleton files: | username | @@ -68,7 +68,7 @@ Feature: get group And the users returned by the API should be | Alice | | Brian | - + @notToImplementOnOCIS Scenario: subadmin tries to get users in a group they are not responsible for Given user "subadmin" has been created with default attributes and without skeleton files And group "brand-new-group" has been created diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature index a614f9d9618c..1b6ab18781ef 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature @@ -71,7 +71,7 @@ Feature: get groups | sysusers | | sailing-lovers | - + @notToImplementOnOCIS Scenario: subadmin gets all the groups Given user "subadmin" has been created with default attributes and without skeleton files And group "brand-new-group" has been created diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature index c031b265c977..2f3b1815c823 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature @@ -1,4 +1,4 @@ -@api @provisioning_api-app-required @skipOnLDAP +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS Feature: get subadmin groups As an admin I want to be able to get the groups in which the user is subadmin diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature index 9f24dbc7fbea..4ae10a8f8416 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature @@ -52,7 +52,7 @@ Feature: get user groups And the OCS status code should be "100" And the HTTP status code should be "200" - @smokeTest + @smokeTest @notToImplementOnOCIS Scenario: subadmin tries to get other groups of a user in their group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature index 7736a0b0f2aa..28427c60a09b 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature @@ -183,7 +183,7 @@ Feature: remove a user from a group And the HTTP status code should be "200" And the API should not return any data - @smokeTest + @smokeTest @notToImplementOnOCIS Scenario: a subadmin can remove users from groups the subadmin is responsible for Given these users have been created with default attributes and without skeleton files: | username | @@ -196,7 +196,7 @@ Feature: remove a user from a group Then the OCS status code should be "100" And the HTTP status code should be "200" And user "brand-new-user" should not belong to group "brand-new-group" - + @notToImplementOnOCIS Scenario: a subadmin cannot remove users from groups the subadmin is not responsible for Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature index 05a3c8120155..2b9495069494 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature @@ -118,7 +118,7 @@ Feature: add groups # A group name must not end in "/subadmins" because that would create ambiguity # with the endpoint for getting the subadmins of a group - @issue-31015 @skipOnOcV10 + @issue-31015 @skipOnOcV10 @notToImplementOnOCIS Scenario: admin tries to create a group with name ending in "/subadmins" Given group "brand-new-group" has been created When the administrator tries to send a group creation request for group "priv/subadmins" using the provisioning API @@ -140,7 +140,7 @@ Feature: add groups Then the OCS status code should be "401" And the HTTP status code should be "401" And group "brand-new-group" should not exist - + @notToImplementOnOCIS Scenario: subadmin tries to create a group Given user "subadmin" has been created with default attributes and without skeleton files And group "brand-new-group" has been created diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature index bcb686e64581..dfd269d3f0eb 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature @@ -163,7 +163,7 @@ Feature: add users to group And the HTTP status code should be "400" And the API should not return any data - @skipOnLDAP + @skipOnLDAP @notToImplementOnOCIS Scenario: subadmin adds users to groups the subadmin is responsible for Given these users have been created with default attributes and without skeleton files: | username | @@ -176,7 +176,7 @@ Feature: add users to group And the HTTP status code should be "403" And user "brand-new-user" should not belong to group "brand-new-group" - @skipOnLDAP + @skipOnLDAP @notToImplementOnOCIS Scenario: subadmin tries to add user to groups the subadmin is not responsible for Given these users have been created with default attributes and without skeleton files: | username | @@ -190,7 +190,7 @@ Feature: add users to group And the HTTP status code should be "403" And user "brand-new-user" should not belong to group "brand-new-group" - @skipOnLDAP @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 + @skipOnLDAP @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @notToImplementOnOCIS Scenario: a subadmin can add users to other groups the subadmin is responsible for Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature index 5b426d626376..42000eb4307e 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature @@ -97,7 +97,7 @@ Feature: delete groups And the HTTP status code should be "401" And group "brand-new-group" should exist - @issue-31276 @skipOnOcV10 + @issue-31276 @skipOnOcV10 @notToImplementOnOCIS Scenario: subadmin of the group tries to delete the group Given user "subadmin" has been created with default attributes and without skeleton files And group "brand-new-group" has been created diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature index 7c05500323aa..d8c4354d2914 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature @@ -51,7 +51,7 @@ Feature: get group | CASE-SENSITIVE-GROUP | Case-Sensitive-Group | | CASE-SENSITIVE-GROUP | case-sensitive-group | - @smokeTest + @smokeTest @notToImplementOnOCIS Scenario: subadmin gets users in a group they are responsible for Given these users have been created with default attributes and without skeleton files: | username | @@ -69,7 +69,7 @@ Feature: get group | Alice | | Brian | - @issue-31276 @skipOnOcV10 + @issue-31276 @skipOnOcV10 @notToImplementOnOCIS Scenario: subadmin tries to get users in a group they are not responsible for Given user "subadmin" has been created with default attributes and without skeleton files And group "brand-new-group" has been created diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature index e25c80fd9983..d0f1a7e7896e 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature @@ -71,7 +71,7 @@ Feature: get groups | sysusers | | sailing-lovers | - + @notToImplementOnOCIS Scenario: subadmin gets all the groups Given user "subadmin" has been created with default attributes and without skeleton files And group "brand-new-group" has been created diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature index 6b67e30f8d47..5e20fef2229d 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature @@ -1,4 +1,4 @@ -@api @provisioning_api-app-required @skipOnLDAP +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS Feature: get subadmin groups As an admin I want to be able to get the groups in which the user is subadmin diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature index d993c8df0e3c..14953a89f5e3 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature @@ -52,7 +52,7 @@ Feature: get user groups And the OCS status code should be "200" And the HTTP status code should be "200" - @smokeTest + @smokeTest @notToImplementOnOCIS Scenario: subadmin tries to get other groups of a user in their group Given these users have been created with default attributes and without skeleton files: | username | diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature index 1c5a5bed05cc..13e784b85c9a 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature @@ -183,7 +183,7 @@ Feature: remove a user from a group And the HTTP status code should be "400" And the API should not return any data - @smokeTest + @smokeTest @notToImplementOnOCIS Scenario: a subadmin can remove users from groups the subadmin is responsible for Given these users have been created with default attributes and without skeleton files: | username | @@ -196,7 +196,7 @@ Feature: remove a user from a group Then the OCS status code should be "200" And the HTTP status code should be "200" And user "brand-new-user" should not belong to group "brand-new-group" - + @notToImplementOnOCIS Scenario: a subadmin cannot remove users from groups the subadmin is not responsible for Given these users have been created with default attributes and without skeleton files: | username |