From fe41b1dff517f0bb3980c608466116f678d08b0e Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Mon, 5 Oct 2020 18:00:23 +0545 Subject: [PATCH] Refactor to put the bug-demo tests into the individual feature files --- .../acceptance/features/apiAuth/cors.feature | 56 +++++++----------- .../apiAuth/corsOc10Issue34664.feature | 16 ++--- .../apiAuth/corsOc10Issue34679.feature | 40 ++++++++----- .../features/apiAuthOcs/ocsDELETEAuth.feature | 5 +- ...re => ocsDELETEAuthOc10Issue32068.feature} | 8 +-- .../features/apiAuthOcs/ocsGETAuth.feature | 12 ++-- .../ocsGETAuthOc10Issue32068.feature | 15 +++-- .../features/apiFavorites/favorites.feature | 27 +++------ .../favoritesOc10Issue33840.feature | 10 ++-- .../federatedOc10Issue35839.feature | 18 ------ .../apiFederationToRoot1/federated.feature | 8 +-- .../federatedOc10Issue31276.feature | 11 ++-- .../apiFederationToRoot2/federated.feature | 20 ++----- .../federatedOc10Issue35839.feature | 59 +++++++++++++++++++ .../apiFederationToShares1/federated.feature | 8 +-- .../apiFederationToShares2/federated.feature | 20 ++----- .../features/apiMain/external-storage.feature | 4 +- .../external-storageOc10Issue37723.feature | 14 ----- .../apiProvisioning-v2/createSubAdmin.feature | 5 +- .../createSubAdminOc10Issue31276.feature | 8 +-- .../apiProvisioning-v2/deleteUser.feature | 5 +- .../deleteUserOc10Issue31276.feature | 8 +-- .../apiProvisioning-v2/disableApp.feature | 10 ++-- .../disableAppOc10Issue31276.feature | 11 ++-- .../apiProvisioning-v2/disableUser.feature | 15 ++--- .../disableUserOc10Issue31276.feature | 14 +++-- .../apiProvisioning-v2/enableApp.feature | 10 ++-- .../enableAppOc10Issue31276.feature | 11 ++-- .../apiProvisioning-v2/enableUser.feature | 5 +- .../enableUserOc10Issue31276.feature | 8 +-- .../apiProvisioning-v2/getSubAdmins.feature | 10 ++-- .../getSubAdminsOc10Issue31276.feature | 11 ++-- .../apiProvisioning-v2/getUser.feature | 5 +- .../getUserOc10Issue31276.feature | 19 ++---- .../apiProvisioning-v2/getUsers.feature | 5 +- .../getUsersOc10Issue31276.feature | 20 +++++++ .../apiProvisioning-v2/removeSubAdmin.feature | 10 ++-- .../removeSubAdminOc10Issue31276.feature | 11 ++-- .../apiProvisioningGroups-v1/addGroup.feature | 27 ++------- .../addGroupOc10Issue31015.feature | 26 +++++--- .../createShareWithDisabledUser.feature | 7 +-- ...hareWithDisabledUserOc10Issue32068.feature | 14 +++-- .../moveReceivedShare.feature | 17 +++--- .../moveReceivedShareOc10Issue30325.feature | 24 +++++--- 44 files changed, 336 insertions(+), 331 deletions(-) rename tests/acceptance/features/apiAuthOcs/{ocsDELETEAuthOc01Issue32068.feature => ocsDELETEAuthOc10Issue32068.feature} (91%) delete mode 100644 tests/acceptance/features/apiFederation2/federatedOc10Issue35839.feature rename tests/acceptance/features/{apiFederation1 => apiFederationToRoot1}/federatedOc10Issue31276.feature (91%) create mode 100644 tests/acceptance/features/apiFederationToRoot2/federatedOc10Issue35839.feature delete mode 100644 tests/acceptance/features/apiMain/external-storageOc10Issue37723.feature create mode 100644 tests/acceptance/features/apiProvisioning-v2/getUsersOc10Issue31276.feature rename tests/acceptance/features/{apiShareCreateSpecial2 => apiShareCreateSpecialToRoot2}/createShareWithDisabledUserOc10Issue32068.feature (57%) rename tests/acceptance/features/{apiShareManagement => apiShareManagementToRoot}/moveReceivedShareOc10Issue30325.feature (53%) diff --git a/tests/acceptance/features/apiAuth/cors.feature b/tests/acceptance/features/apiAuth/cors.feature index ec313349c332..0bced8b551a2 100644 --- a/tests/acceptance/features/apiAuth/cors.feature +++ b/tests/acceptance/features/apiAuth/cors.feature @@ -38,8 +38,8 @@ Feature: CORS headers | 1 | /cloud/users | 997 | 401 | | 2 | /cloud/users | 997 | 401 | - #merge into previous scenario when fixed - @issue-34664 + #merge into previous scenario when this does not need to be tagged skipOnOcV10 + @issue-34664 @skipOnOcV10 Scenario Outline: CORS headers should be returned when setting CORS domain sending Origin header Given using OCS API version "" And user "Alice" has added "https://aphno.badal" to the list of personal CORS domains @@ -48,12 +48,12 @@ Feature: CORS headers | Origin | https://aphno.badal | Then the OCS status code should be "" And the HTTP status code should be "" - Then the following headers should not be set - | header | - | Access-Control-Allow-Headers | - | Access-Control-Expose-Headers | - | Access-Control-Allow-Origin | - | Access-Control-Allow-Methods | + Then the following headers should be set + | header | value | + | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | + | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | + | Access-Control-Allow-Origin | https://aphno.badal | + | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | Examples: | ocs_api_version | endpoint | ocs-code | http-code | | 1 | /config | 100 | 200 | @@ -141,7 +141,7 @@ Feature: CORS headers | 1 | /cloud/users | 100 | 200 | | 2 | /cloud/users | 200 | 200 | - @issue-34679 @files_sharing-app-required + @issue-34679 @files_sharing-app-required @skipOnOcV10 Scenario Outline: CORS headers should be returned when invalid password is used Given using OCS API version "" And user "Alice" has added "https://aphno.badal" to the list of personal CORS domains @@ -150,18 +150,12 @@ Feature: CORS headers | Origin | https://aphno.badal | Then the OCS status code should be "" And the HTTP status code should be "" - Then the following headers should not be set - | header | - | Access-Control-Allow-Headers | - | Access-Control-Expose-Headers | - | Access-Control-Allow-Origin | - | Access-Control-Allow-Methods | - #Then the following headers should be set - # | header | value | - # | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | - # | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | - # | Access-Control-Allow-Origin | https://aphno.badal | - # | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | + Then the following headers should be set + | header | value | + | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | + | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | + | Access-Control-Allow-Origin | https://aphno.badal | + | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | Examples: | ocs_api_version | endpoint | ocs-code | http-code | | 1 | /apps/files_external/api/v1/mounts | 997 | 401 | @@ -181,7 +175,7 @@ Feature: CORS headers | 1 | /cloud/users | 997 | 401 | | 2 | /cloud/users | 997 | 401 | - @issue-34679 + @issue-34679 @skipOnOcV10 Scenario Outline: CORS headers should be returned when invalid password is used (admin only endpoints) Given using OCS API version "" And the administrator has added "https://aphno.badal" to the list of personal CORS domains @@ -192,18 +186,12 @@ Feature: CORS headers | Origin | https://aphno.badal | Then the OCS status code should be "" And the HTTP status code should be "" - Then the following headers should not be set - | header | - | Access-Control-Allow-Headers | - | Access-Control-Expose-Headers | - | Access-Control-Allow-Origin | - | Access-Control-Allow-Methods | - #Then the following headers should be set - # | header | value | - # | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | - # | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | - # | Access-Control-Allow-Origin | https://aphno.badal | - # | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | + Then the following headers should be set + | header | value | + | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | + | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | + | Access-Control-Allow-Origin | https://aphno.badal | + | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | Examples: | ocs_api_version | endpoint | ocs-code | http-code | | 1 | /cloud/apps | 997 | 401 | diff --git a/tests/acceptance/features/apiAuth/corsOc10Issue34664.feature b/tests/acceptance/features/apiAuth/corsOc10Issue34664.feature index ed4b5fe856f8..c27d573f2705 100644 --- a/tests/acceptance/features/apiAuth/corsOc10Issue34664.feature +++ b/tests/acceptance/features/apiAuth/corsOc10Issue34664.feature @@ -1,5 +1,5 @@ -@api @skipOnOcV10 @notToImplementOnOCIS -Feature: CORS headers correct expected behavior for issue 34664 +@api @notToImplementOnOCIS +Feature: CORS headers current oC10 behavior for issue-34664 @issue-34664 Scenario Outline: CORS headers should be returned when setting CORS domain sending Origin header @@ -11,12 +11,12 @@ Feature: CORS headers correct expected behavior for issue 34664 | Origin | https://aphno.badal | Then the OCS status code should be "" And the HTTP status code should be "" - Then the following headers should be set - | header | value | - | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | - | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | - | Access-Control-Allow-Origin | https://aphno.badal | - | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | + Then the following headers should not be set + | header | + | Access-Control-Allow-Headers | + | Access-Control-Expose-Headers | + | Access-Control-Allow-Origin | + | Access-Control-Allow-Methods | Examples: | ocs_api_version | endpoint | ocs-code | http-code | | 1 | /config | 100 | 200 | diff --git a/tests/acceptance/features/apiAuth/corsOc10Issue34679.feature b/tests/acceptance/features/apiAuth/corsOc10Issue34679.feature index 9111256c1e4f..0871c37fa13b 100644 --- a/tests/acceptance/features/apiAuth/corsOc10Issue34679.feature +++ b/tests/acceptance/features/apiAuth/corsOc10Issue34679.feature @@ -1,5 +1,5 @@ -@api @skipOnOcV10 @notToImplementOnOCIS -Feature: CORS headers correct expected behavior for issue 34679 +@api @notToImplementOnOCIS +Feature: CORS headers current oC10 behavior for issue-34679 Background: Given user "Alice" has been created with default attributes and skeleton files @@ -13,12 +13,18 @@ Feature: CORS headers correct expected behavior for issue 34679 | Origin | https://aphno.badal | Then the OCS status code should be "" And the HTTP status code should be "" - Then the following headers should be set - | header | value | - | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | - | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | - | Access-Control-Allow-Origin | https://aphno.badal | - | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | + Then the following headers should not be set + | header | + | Access-Control-Allow-Headers | + | Access-Control-Expose-Headers | + | Access-Control-Allow-Origin | + | Access-Control-Allow-Methods | + #Then the following headers should be set + # | header | value | + # | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | + # | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | + # | Access-Control-Allow-Origin | https://aphno.badal | + # | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | Examples: | ocs_api_version | endpoint | ocs-code | http-code | | 1 | /apps/files_external/api/v1/mounts | 997 | 401 | @@ -49,12 +55,18 @@ Feature: CORS headers correct expected behavior for issue 34679 | Origin | https://aphno.badal | Then the OCS status code should be "" And the HTTP status code should be "" - Then the following headers should be set - | header | value | - | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | - | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | - | Access-Control-Allow-Origin | https://aphno.badal | - | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | + Then the following headers should not be set + | header | + | Access-Control-Allow-Headers | + | Access-Control-Expose-Headers | + | Access-Control-Allow-Origin | + | Access-Control-Allow-Methods | + #Then the following headers should be set + # | header | value | + # | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,Accept,Authorization,Brief,Content-Length,Content-Range,Content-Type,Date,Depth,Destination,Host,If,If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,Location,Lock-Token,Overwrite,Prefer,Range,Schedule-Reply,Timeout,User-Agent,X-Expected-Entity-Length,Accept-Language,Access-Control-Request-Method,Access-Control-Allow-Origin,ETag,OC-Autorename,OC-CalDav-Import,OC-Chunked,OC-Etag,OC-FileId,OC-LazyOps,OC-Total-File-Length,Origin,X-Request-ID,X-Requested-With | + # | Access-Control-Expose-Headers | Content-Location,DAV,ETag,Link,Lock-Token,OC-ETag,OC-Checksum,OC-FileId,OC-JobStatus-Location,Vary,Webdav-Location,X-Sabre-Status | + # | Access-Control-Allow-Origin | https://aphno.badal | + # | Access-Control-Allow-Methods | GET,OPTIONS,POST,PUT,DELETE,MKCOL,PROPFIND,PATCH,PROPPATCH,REPORT | Examples: | ocs_api_version | endpoint | ocs-code | http-code | | 1 | /cloud/apps | 997 | 401 | diff --git a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature index afa34f2637b8..02b1ee73357f 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature @@ -4,8 +4,9 @@ Feature: auth Background: Given user "another-admin" has been created with default attributes and without skeleton files - @smokeTest @issue-32068 @issue-ocis-reva-30 @issue-ocis-reva-65 + @smokeTest @issue-ocis-reva-30 @issue-ocis-reva-65 @skipOnBruteForceProtection @issue-brute_force_protection-112 + @skipOnOcV10 @issue-32068 Scenario: send DELETE requests to OCS endpoints as admin with wrong password Given user "another-admin" has been added to group "admin" When user "another-admin" requests these endpoints with "DELETE" using password "invalid" about user "Alice" @@ -28,4 +29,4 @@ Feature: auth | /ocs/v1.php/cloud/users/%username%/subadmins | | /ocs/v2.php/cloud/users/%username%/subadmins | Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "997" + And the OCS status code of responses on all endpoints should be "401" diff --git a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc01Issue32068.feature b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc10Issue32068.feature similarity index 91% rename from tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc01Issue32068.feature rename to tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc10Issue32068.feature index 403be9a09e93..f22e99608490 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc01Issue32068.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuthOc10Issue32068.feature @@ -1,6 +1,5 @@ -@api @files_sharing-app-required -@skipOnOcV10 @notToImplementOnOCIS -Feature: auth +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: current oC10 behavior for issue-32068 @smokeTest @issue-32068 @issue-ocis-reva-30 @issue-ocis-reva-65 @skipOnBruteForceProtection @issue-brute_force_protection-112 @@ -27,4 +26,5 @@ Feature: auth | /ocs/v1.php/cloud/users/%username%/subadmins | | /ocs/v2.php/cloud/users/%username%/subadmins | Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "401" + And the OCS status code of responses on all endpoints should be "997" + #And the OCS status code of responses on all endpoints should be "401" diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature index 95aa26dc2bee..2fbf377764a9 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature @@ -4,7 +4,7 @@ Feature: auth Background: Given user "Alice" has been created with default attributes and skeleton files - @issue-32068 + @issue-32068 @skipOnOcV10 @issue-ocis-reva-30 @smokeTest Scenario: using OCS anonymously @@ -27,7 +27,7 @@ Feature: auth | /ocs/v1.php/privatedata/getattribute | | /ocs/v2.php/privatedata/getattribute | Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "997" + And the OCS status code of responses on all endpoints should be "401" @issue-ocis-reva-29 Scenario: ocs config end point accessible by unauthorized users @@ -42,7 +42,7 @@ Feature: auth Then the HTTP status code of responses on all endpoints should be "200" And the OCS status code of responses on all endpoints should be "200" - @issue-32068 + @issue-32068 @skipOnOcV10 @issue-ocis-reva-11 @issue-ocis-reva-30 @issue-ocis-reva-31 @@ -80,9 +80,9 @@ Feature: auth | /ocs/v2.php/cloud/groups | | /ocs/v2.php/cloud/users | Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "997" + And the OCS status code of responses on all endpoints should be "401" - @issue-32068 @issue-ocis-reva-29 @issue-ocis-reva-30 + @issue-32068 @skipOnOcV10 @issue-ocis-reva-29 @issue-ocis-reva-30 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 Scenario: using OCS as normal user with wrong password @@ -105,7 +105,7 @@ Feature: auth | /ocs/v1.php/privatedata/getattribute | | /ocs/v2.php/privatedata/getattribute | Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "997" + And the OCS status code of responses on all endpoints should be "401" When user "Alice" requests these endpoints with "GET" using password "invalid" | endpoint | | /ocs/v1.php/config | diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuthOc10Issue32068.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuthOc10Issue32068.feature index 6316188877e2..7c5f9b72441f 100644 --- a/tests/acceptance/features/apiAuthOcs/ocsGETAuthOc10Issue32068.feature +++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuthOc10Issue32068.feature @@ -1,8 +1,8 @@ -@api @skipOnOcV10 @notToImplementOnOCIS @files_sharing-app-required @issue-32068 -Feature: auth +@api @notToImplementOnOCIS @files_sharing-app-required @issue-32068 +Feature: current oC10 behavior for issue-32068 Background: - Given user "another-admin" has been created with default attributes and without skeleton files + Given user "Alice" has been created with default attributes and without skeleton files @issue-32068 @issue-ocis-reva-30 @@ -27,7 +27,8 @@ Feature: auth | /ocs/v1.php/privatedata/getattribute | | /ocs/v2.php/privatedata/getattribute | Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "401" + And the OCS status code of responses on all endpoints should be "997" + #And the OCS status code of responses on all endpoints should be "401" @issue-32068 @issue-ocis-reva-11 @@ -67,7 +68,8 @@ Feature: auth | /ocs/v2.php/cloud/groups | | /ocs/v2.php/cloud/users | Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "401" + And the OCS status code of responses on all endpoints should be "997" + #And the OCS status code of responses on all endpoints should be "401" @issue-32068 @issue-ocis-reva-29 @issue-ocis-reva-30 @smokeTest @@ -92,7 +94,8 @@ Feature: auth | /ocs/v1.php/privatedata/getattribute | | /ocs/v2.php/privatedata/getattribute | Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "401" + And the OCS status code of responses on all endpoints should be "997" + #And the OCS status code of responses on all endpoints should be "401" When user "Alice" requests these endpoints with "GET" using password "invalid" | endpoint | | /ocs/v1.php/config | diff --git a/tests/acceptance/features/apiFavorites/favorites.feature b/tests/acceptance/features/apiFavorites/favorites.feature index e885d3b02bab..a25aab03c41e 100644 --- a/tests/acceptance/features/apiFavorites/favorites.feature +++ b/tests/acceptance/features/apiFavorites/favorites.feature @@ -75,8 +75,7 @@ Feature: favorite | old | | new | - @smokeTest @toImplementOnOCIS - @issue-ocis-reva-39 + @smokeTest Scenario Outline: Get favorited elements of a folder Given using DAV path When user "Alice" favorites element "/FOLDER" using the WebDAV API @@ -92,8 +91,6 @@ Feature: favorite | old | | new | - @toImplementOnOCIS - @issue-ocis-reva-39 Scenario Outline: Get favorited elements of a subfolder Given using DAV path And user "Alice" has created folder "/subfolder" @@ -115,8 +112,7 @@ Feature: favorite | old | | new | - @files_sharing-app-required @toImplementOnOCIS - @issue-ocis-reva-39 + @files_sharing-app-required Scenario Outline: moving a favorite file out of a share keeps favorite state Given using DAV path And user "Brian" has been created with default attributes and without skeleton files @@ -132,8 +128,7 @@ Feature: favorite | old | | new | - @issue-33840 @toImplementOnOCIS - @issue-ocis-reva-39 + @issue-33840 @skipOnOcV10 Scenario Outline: Get favorited elements and limit count of entries Given using DAV path And user "Alice" has favorited element "/textfile0.txt" @@ -142,8 +137,7 @@ Feature: favorite And user "Alice" has favorited element "/textfile3.txt" And user "Alice" has favorited element "/textfile4.txt" When user "Alice" lists the favorites of folder "/" and limits the result to 3 elements using the WebDAV API - #Then the search result of "Alice" should contain any "3" of these entries: - Then the search result should contain any "0" of these entries: + Then the search result should contain any "3" of these entries: | /textfile0.txt | | /textfile1.txt | | /textfile2.txt | @@ -154,8 +148,7 @@ Feature: favorite | old | | new | - @issue-33840 @toImplementOnOCIS - @issue-ocis-reva-39 + @issue-33840 @skipOnOcV10 Scenario Outline: Get favorited elements paginated in subfolder Given using DAV path And user "Alice" has created folder "/subfolder" @@ -172,8 +165,7 @@ Feature: favorite And user "Alice" has favorited element "/subfolder/textfile4.txt" And user "Alice" has favorited element "/subfolder/textfile5.txt" When user "Alice" lists the favorites of folder "/" and limits the result to 3 elements using the WebDAV API - #Then the search result of "Alice" should contain any "3" of these entries: - Then the search result should contain any "0" of these entries: + Then the search result should contain any "3" of these entries: | /subfolder/textfile0.txt | | /subfolder/textfile1.txt | | /subfolder/textfile2.txt | @@ -184,8 +176,7 @@ Feature: favorite | old | | new | - @files_sharing-app-required @toImplementOnOCIS - @issue-ocis-reva-39 + @files_sharing-app-required Scenario Outline: sharer file favorite state should not change the favorite state of sharee Given using DAV path And user "Brian" has been created with default attributes and without skeleton files @@ -199,8 +190,7 @@ Feature: favorite | old | | new | - @files_sharing-app-required @toImplementOnOCIS - @toImplementOnOCIS @issue-ocis-reva-243 + @files_sharing-app-required Scenario Outline: sharee file favorite state should not change the favorite state of sharer Given using DAV path And user "Brian" has been created with default attributes and without skeleton files @@ -214,7 +204,6 @@ Feature: favorite | old | | new | - @issue-ocis-reva-39 Scenario Outline: favoriting a folder does not change the favorite state of elements inside the folder Given using DAV path When user "Alice" favorites element "/PARENT/parent.txt" using the WebDAV API diff --git a/tests/acceptance/features/apiFavorites/favoritesOc10Issue33840.feature b/tests/acceptance/features/apiFavorites/favoritesOc10Issue33840.feature index 21cc0f4406df..23744bebb094 100644 --- a/tests/acceptance/features/apiFavorites/favoritesOc10Issue33840.feature +++ b/tests/acceptance/features/apiFavorites/favoritesOc10Issue33840.feature @@ -1,5 +1,5 @@ -@api @skipOnOcV10 @notToImplementOnOCIS -Feature: favorite +@api @notToImplementOnOCIS +Feature: current oC10 behavior for issue-33840 Background: Given using OCS API version "1" @@ -22,7 +22,8 @@ Feature: favorite And user "Alice" has favorited element "/textfile3.txt" And user "Alice" has favorited element "/textfile4.txt" When user "Alice" lists the favorites of folder "/" and limits the result to 3 elements using the WebDAV API - Then the search result should contain any "3" of these entries: + #Then the search result should contain any "3" of these entries: + Then the search result should contain any "0" of these entries: | /textfile0.txt | | /textfile1.txt | | /textfile2.txt | @@ -50,7 +51,8 @@ Feature: favorite And user "Alice" has favorited element "/subfolder/textfile4.txt" And user "Alice" has favorited element "/subfolder/textfile5.txt" When user "Alice" lists the favorites of folder "/" and limits the result to 3 elements using the WebDAV API - Then the search result should contain any "3" of these entries: + #Then the search result should contain any "3" of these entries: + Then the search result should contain any "0" of these entries: | /subfolder/textfile0.txt | | /subfolder/textfile1.txt | | /subfolder/textfile2.txt | diff --git a/tests/acceptance/features/apiFederation2/federatedOc10Issue35839.feature b/tests/acceptance/features/apiFederation2/federatedOc10Issue35839.feature deleted file mode 100644 index b82d38648736..000000000000 --- a/tests/acceptance/features/apiFederation2/federatedOc10Issue35839.feature +++ /dev/null @@ -1,18 +0,0 @@ -@api @federation-app-required @files_sharing-app-required -@skipOnOcV10 @notToImplementOnOCIS -Feature: federated - - @issue-35839 - Scenario: enable "Add server automatically" once a federated share was created successfully - Given using server "REMOTE" - And user "Alice" has been created with default attributes and skeleton files - And using server "LOCAL" - And user "Brian" has been created with default attributes and skeleton files - And parameter "autoAddServers" of app "federation" has been set to "1" - And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes" - When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API - And user "Brian" from server "LOCAL" has accepted the last pending share - And using server "LOCAL" - Then url "%remote_server%" should be a trusted server - When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API - Then as "Brian" file "textfile1 (2).txt" should exist diff --git a/tests/acceptance/features/apiFederationToRoot1/federated.feature b/tests/acceptance/features/apiFederationToRoot1/federated.feature index 851711b4c0c2..5475322432ed 100644 --- a/tests/acceptance/features/apiFederationToRoot1/federated.feature +++ b/tests/acceptance/features/apiFederationToRoot1/federated.feature @@ -292,13 +292,13 @@ Feature: federated | 1 | 100 | | 2 | 200 | - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario Outline: Remote sharee tries to delete an accepted federated share sending wrong password Given user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" And user "Brian" from server "LOCAL" has accepted the last pending share And using OCS API version "" When user "Brian" deletes the last federated cloud share with password "invalid" using the sharing API - Then the OCS status code should be "997" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should see the following elements | /textfile0%20(2).txt | @@ -339,12 +339,12 @@ Feature: federated | 1 | 100 | | 2 | 200 | - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario Outline: Remote sharee tries to delete a pending federated share sending wrong password Given user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" And using OCS API version "" When user "Brian" deletes the last pending federated cloud share with password "invalid" using the sharing API - Then the OCS status code should be "997" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should not see the following elements | /textfile0%20(2).txt | diff --git a/tests/acceptance/features/apiFederation1/federatedOc10Issue31276.feature b/tests/acceptance/features/apiFederationToRoot1/federatedOc10Issue31276.feature similarity index 91% rename from tests/acceptance/features/apiFederation1/federatedOc10Issue31276.feature rename to tests/acceptance/features/apiFederationToRoot1/federatedOc10Issue31276.feature index d3b2b7e54de6..b0d2305eacd6 100644 --- a/tests/acceptance/features/apiFederation1/federatedOc10Issue31276.feature +++ b/tests/acceptance/features/apiFederationToRoot1/federatedOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @federation-app-required @files_sharing-app-required -@skipOnOcV10 @notToImplementOnOCIS -Feature: federated +@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: current oC10 behavior for issue-31276 Background: Given using server "REMOTE" @@ -14,7 +13,8 @@ Feature: federated And user "Brian" from server "LOCAL" has accepted the last pending share And using OCS API version "" When user "Brian" deletes the last federated cloud share with password "invalid" using the sharing API - Then the OCS status code should be "401" + #Then the OCS status code should be "401" + Then the OCS status code should be "997" And the HTTP status code should be "401" And user "Brian" should see the following elements | /textfile0%20(2).txt | @@ -43,7 +43,8 @@ Feature: federated Given user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" And using OCS API version "" When user "Brian" deletes the last pending federated cloud share with password "invalid" using the sharing API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should not see the following elements | /textfile0%20(2).txt | diff --git a/tests/acceptance/features/apiFederationToRoot2/federated.feature b/tests/acceptance/features/apiFederationToRoot2/federated.feature index 095f716046ce..007a95f1777e 100644 --- a/tests/acceptance/features/apiFederationToRoot2/federated.feature +++ b/tests/acceptance/features/apiFederationToRoot2/federated.feature @@ -7,11 +7,9 @@ Feature: federated And using server "LOCAL" And user "Brian" has been created with default attributes and skeleton files - @issue-35839 + @issue-35839 @skipOnOcV10 Scenario: "Auto accept from trusted servers" enabled with remote server Given the trusted server list is cleared - # Remove this line once the issue is resolved - And parameter "autoAddServers" of app "federation" has been set to "0" And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes" When the administrator adds url "%remote_server%" as trusted server using the testing API And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API @@ -19,11 +17,9 @@ Feature: federated Then as "Brian" file "textfile1 (2).txt" should exist And url "%remote_server%" should be a trusted server - @issue-35839 + @issue-35839 @skipOnOcV10 Scenario: "Auto accept from trusted servers" disabled with remote server Given the trusted server list is cleared - # Remove this line once the issue is resolved - And parameter "autoAddServers" of app "federation" has been set to "0" And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "no" When the administrator adds url "%remote_server%" as trusted server using the testing API And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API @@ -50,7 +46,7 @@ Feature: federated Then as "Brian" file "textfile1 (2).txt" should exist And url "%remote_server%" should not be a trusted server - @issue-35839 + @issue-35839 @skipOnOcV10 Scenario: enable "Add server automatically" once a federated share was created successfully Given using server "LOCAL" And parameter "autoAddServers" of app "federation" has been set to "1" @@ -60,11 +56,9 @@ Feature: federated And using server "LOCAL" Then url "%remote_server%" should be a trusted server When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API - # Uncomment this line once the issue is resolved - # Then as "Brian" file "textfile1 (2).txt" should exist - Then as "Brian" file "textfile1 (2).txt" should not exist + Then as "Brian" file "textfile1 (2).txt" should exist - @issue-35839 + @issue-35839 @skipOnOcV10 Scenario: disable "Add server automatically" once a federated share was created successfully Given using server "LOCAL" And the trusted server list is cleared @@ -74,9 +68,7 @@ Feature: federated And user "Brian" from server "LOCAL" has accepted the last pending share And using server "LOCAL" Then url "%remote_server%" should not be a trusted server - # Remove this line once the issue is resolved - When the administrator sets parameter "autoAddServers" of app "federation" to "0" - And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API And as "Brian" file "textfile1 (2).txt" should not exist Scenario Outline: federated share receiver sees the original content of a received file diff --git a/tests/acceptance/features/apiFederationToRoot2/federatedOc10Issue35839.feature b/tests/acceptance/features/apiFederationToRoot2/federatedOc10Issue35839.feature new file mode 100644 index 000000000000..ba7b7ec383ad --- /dev/null +++ b/tests/acceptance/features/apiFederationToRoot2/federatedOc10Issue35839.feature @@ -0,0 +1,59 @@ +@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: current oC10 behavior for issue-35839 + + Background: + Given using server "REMOTE" + And user "Alice" has been created with default attributes and skeleton files + And using server "LOCAL" + And user "Brian" has been created with default attributes and skeleton files + + @issue-35839 + Scenario: "Auto accept from trusted servers" enabled with remote server + Given the trusted server list is cleared + # Remove this line once the issue is resolved + And parameter "autoAddServers" of app "federation" has been set to "0" + And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes" + When the administrator adds url "%remote_server%" as trusted server using the testing API + And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + And using server "LOCAL" + Then as "Brian" file "textfile1 (2).txt" should exist + And url "%remote_server%" should be a trusted server + + @issue-35839 + Scenario: "Auto accept from trusted servers" disabled with remote server + Given the trusted server list is cleared + # Remove this line once the issue is resolved + And parameter "autoAddServers" of app "federation" has been set to "0" + And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "no" + When the administrator adds url "%remote_server%" as trusted server using the testing API + And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + And using server "LOCAL" + Then as "Brian" file "textfile1 (2).txt" should not exist + And url "%remote_server%" should be a trusted server + + @issue-35839 + Scenario: enable "Add server automatically" once a federated share was created successfully + Given parameter "autoAddServers" of app "federation" has been set to "1" + And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes" + When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + Then url "%remote_server%" should be a trusted server + When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + #Then as "Brian" file "textfile1 (2).txt" should exist + Then as "Brian" file "textfile1 (2).txt" should not exist + + @issue-35839 + Scenario: disable "Add server automatically" once a federated share was created successfully + Given using server "LOCAL" + And the trusted server list is cleared + And parameter "autoAddServers" of app "federation" has been set to "0" + And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes" + When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + Then url "%remote_server%" should not be a trusted server + # Remove this line once the issue is resolved + When the administrator sets parameter "autoAddServers" of app "federation" to "0" + And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + And as "Brian" file "textfile1 (2).txt" should not exist diff --git a/tests/acceptance/features/apiFederationToShares1/federated.feature b/tests/acceptance/features/apiFederationToShares1/federated.feature index a3b03a883257..aea862036791 100644 --- a/tests/acceptance/features/apiFederationToShares1/federated.feature +++ b/tests/acceptance/features/apiFederationToShares1/federated.feature @@ -296,13 +296,13 @@ Feature: federated | 1 | 100 | | 2 | 200 | - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario Outline: Remote sharee tries to delete an accepted federated share sending wrong password Given user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" And user "Brian" from server "LOCAL" has accepted the last pending share And using OCS API version "" When user "Brian" deletes the last federated cloud share with password "invalid" using the sharing API - Then the OCS status code should be "997" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should see the following elements | /Shares/textfile0.txt | @@ -343,12 +343,12 @@ Feature: federated | 1 | 100 | | 2 | 200 | - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario Outline: Remote sharee tries to delete a pending federated share sending wrong password Given user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" And using OCS API version "" When user "Brian" deletes the last pending federated cloud share with password "invalid" using the sharing API - Then the OCS status code should be "997" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should not see the following elements | /Shares/textfile0.txt | diff --git a/tests/acceptance/features/apiFederationToShares2/federated.feature b/tests/acceptance/features/apiFederationToShares2/federated.feature index bca0f88f0d48..baa5984231cb 100644 --- a/tests/acceptance/features/apiFederationToShares2/federated.feature +++ b/tests/acceptance/features/apiFederationToShares2/federated.feature @@ -11,11 +11,9 @@ Feature: federated And auto-accept shares has been disabled And user "Brian" has been created with default attributes and skeleton files - @issue-35839 + @issue-35839 @skipOnOcV10 Scenario: "Auto accept from trusted servers" enabled with remote server Given the trusted server list is cleared - # Remove this line once the issue is resolved - And parameter "autoAddServers" of app "federation" has been set to "0" And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "yes" When the administrator adds url "%remote_server%" as trusted server using the testing API And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API @@ -23,11 +21,9 @@ Feature: federated Then as "Brian" file "Shares/textfile1.txt" should exist And url "%remote_server%" should be a trusted server - @issue-35839 + @issue-35839 @skipOnOcV10 Scenario: "Auto accept from trusted servers" disabled with remote server Given the trusted server list is cleared - # Remove this line once the issue is resolved - And parameter "autoAddServers" of app "federation" has been set to "0" And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "no" When the administrator adds url "%remote_server%" as trusted server using the testing API And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API @@ -54,7 +50,7 @@ Feature: federated Then as "Brian" file "Shares/textfile1.txt" should exist And url "%remote_server%" should not be a trusted server - @issue-35839 + @issue-35839 @skipOnOcV10 Scenario: enable "Add server automatically" once a federated share was created successfully Given using server "LOCAL" And parameter "autoAddServers" of app "federation" has been set to "1" @@ -64,11 +60,9 @@ Feature: federated And using server "LOCAL" Then url "%remote_server%" should be a trusted server When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API - # Uncomment this line once the issue is resolved - # Then as "Brian" file "Shares/textfile1.txt" should exist - Then as "Brian" file "Shares/textfile1.txt" should not exist + Then as "Brian" file "Shares/textfile1.txt" should exist - @issue-35839 + @issue-35839 @skipOnOcV10 Scenario: disable "Add server automatically" once a federated share was created successfully Given using server "LOCAL" And the trusted server list is cleared @@ -78,9 +72,7 @@ Feature: federated And user "Brian" from server "LOCAL" has accepted the last pending share And using server "LOCAL" Then url "%remote_server%" should not be a trusted server - # Remove this line once the issue is resolved - When the administrator sets parameter "autoAddServers" of app "federation" to "0" - And user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API And as "Brian" file "Shares/textfile1.txt" should not exist Scenario Outline: federated share receiver sees the original content of a received file diff --git a/tests/acceptance/features/apiMain/external-storage.feature b/tests/acceptance/features/apiMain/external-storage.feature index ad14e3165ea1..f862b1cd2d98 100644 --- a/tests/acceptance/features/apiMain/external-storage.feature +++ b/tests/acceptance/features/apiMain/external-storage.feature @@ -46,7 +46,6 @@ Feature: external-storage And as "Alice" file "/local_storage/foo2/textfile0.txt" should not exist And as "Brian" file "/local.txt" should exist - @issue-37723 Scenario: Download a file that exists in filecache but not storage fails with 404 Given user "Alice" has been created with default attributes and skeleton files And user "Alice" has created folder "/local_storage/foo3" @@ -54,8 +53,9 @@ Feature: external-storage And file "foo3/textfile0.txt" has been deleted from local storage on the server When user "Alice" downloads file "local_storage/foo3/textfile0.txt" using the WebDAV API Then the HTTP status code should be "404" + # See issue-37723 for discussion. In this case the server still reports the file exists + # in the folder. The file cache will be cleared after the local storage is scanned. And as "Alice" file "local_storage/foo3/textfile0.txt" should exist -# And as "Alice" file "local_storage/foo3/textfile0.txt" should not exist Scenario: Upload a file to external storage while quota is set on home storage Given user "Alice" has been created with default attributes and skeleton files diff --git a/tests/acceptance/features/apiMain/external-storageOc10Issue37723.feature b/tests/acceptance/features/apiMain/external-storageOc10Issue37723.feature deleted file mode 100644 index feb2040f1e33..000000000000 --- a/tests/acceptance/features/apiMain/external-storageOc10Issue37723.feature +++ /dev/null @@ -1,14 +0,0 @@ -@api @local_storage @skipOnOcV10 @notToImplementOnOCIS -Feature: external-storage - - @issue-37723 - Scenario: Download a file that exists in filecache but not storage fails with 404 - Given using OCS API version "1" - And using old DAV path - And user "Alice" has been created with default attributes and skeleton files - And user "Alice" has created folder "/local_storage/foo3" - And user "Alice" has moved file "/textfile0.txt" to "/local_storage/foo3/textfile0.txt" - And file "foo3/textfile0.txt" has been deleted from local storage on the server - When user "Alice" downloads file "local_storage/foo3/textfile0.txt" using the WebDAV API - Then the HTTP status code should be "404" - And as "Alice" file "local_storage/foo3/textfile0.txt" should not exist diff --git a/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature index da60e28c4e64..90ca8b9c761b 100644 --- a/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature +++ b/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature @@ -31,7 +31,7 @@ Feature: create a subadmin Then the OCS status code should be "400" And the HTTP status code should be "400" - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: subadmin of a group tries to make another user subadmin of their group Given these users have been created with default attributes and skeleton files: | username | @@ -41,7 +41,6 @@ Feature: create a subadmin And user "subadmin" has been made a subadmin of group "brand-new-group" And user "brand-new-user" has been added to group "brand-new-group" When user "subadmin" makes user "brand-new-user" a subadmin of group "brand-new-group" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "brand-new-user" should not be a subadmin of group "brand-new-group" diff --git a/tests/acceptance/features/apiProvisioning-v2/createSubAdminOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/createSubAdminOc10Issue31276.feature index 526043d4f144..356e924ee736 100644 --- a/tests/acceptance/features/apiProvisioning-v2/createSubAdminOc10Issue31276.feature +++ b/tests/acceptance/features/apiProvisioning-v2/createSubAdminOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @provisioning_api-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS -Feature: create a subadmin +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: current oC10 behavior for issue-31276 As an admin I want to be able to make a user the subadmin of a group So that I can give administrative privilege of a group to a user @@ -16,6 +15,7 @@ Feature: create a subadmin And user "subadmin" has been made a subadmin of group "brand-new-group" And user "brand-new-user" has been added to group "brand-new-group" When user "subadmin" makes user "brand-new-user" a subadmin of group "brand-new-group" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And user "brand-new-user" should not be a subadmin of group "brand-new-group" diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature index ba05cbf7be03..8ec370a807c8 100644 --- a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature @@ -50,14 +50,13 @@ Feature: delete users And the HTTP status code should be "200" And user "brand-new-user" should not exist - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: normal user tries to delete a user Given these users have been created with default attributes and skeleton files: | username | | Alice | | Brian | When user "Alice" deletes user "Brian" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should exist diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteUserOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/deleteUserOc10Issue31276.feature index 98ea8f4dfaf6..106e0d119d86 100644 --- a/tests/acceptance/features/apiProvisioning-v2/deleteUserOc10Issue31276.feature +++ b/tests/acceptance/features/apiProvisioning-v2/deleteUserOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @provisioning_api-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS -Feature: delete users +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: current oC10 behavior for issue-31276 As an admin I want to be able to delete users So that I can remove user from ownCloud @@ -13,6 +12,7 @@ Feature: delete users | Alice | | Brian | When user "Alice" deletes user "Brian" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should exist diff --git a/tests/acceptance/features/apiProvisioning-v2/disableApp.feature b/tests/acceptance/features/apiProvisioning-v2/disableApp.feature index 412ce959f1ae..42d01a55719b 100644 --- a/tests/acceptance/features/apiProvisioning-v2/disableApp.feature +++ b/tests/acceptance/features/apiProvisioning-v2/disableApp.feature @@ -15,24 +15,22 @@ Feature: disable an app And the HTTP status code should be "200" And app "comments" should be disabled - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: subadmin tries to disable an app Given user "subadmin" has been created with default attributes and skeleton files And group "brand-new-group" has been created And user "subadmin" has been made a subadmin of group "brand-new-group" And app "comments" has been enabled When user "subadmin" disables app "comments" - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And app "comments" should be enabled - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: normal user tries to disable an app Given user "brand-new-user" has been created with default attributes and skeleton files And app "comments" has been enabled When user "brand-new-user" disables app "comments" - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And app "comments" should be enabled diff --git a/tests/acceptance/features/apiProvisioning-v2/disableAppOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/disableAppOc10Issue31276.feature index 8572b3fddcd5..bd78b5a590f7 100644 --- a/tests/acceptance/features/apiProvisioning-v2/disableAppOc10Issue31276.feature +++ b/tests/acceptance/features/apiProvisioning-v2/disableAppOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @provisioning_api-app-required @comments-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS -Feature: disable an app +@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: current oC10 behavior for issue-31276 As an admin I want to be able to disable an enabled app So that I can stop the app features being used @@ -15,7 +14,8 @@ Feature: disable an app And user "subadmin" has been made a subadmin of group "brand-new-group" And app "comments" has been enabled When user "subadmin" disables app "comments" - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And app "comments" should be enabled @@ -24,6 +24,7 @@ Feature: disable an app Given user "brand-new-user" has been created with default attributes and skeleton files And app "comments" has been enabled When user "brand-new-user" disables app "comments" - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And app "comments" should be enabled diff --git a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature index be6c4ec08985..408ab5fc24a9 100644 --- a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature @@ -44,7 +44,7 @@ Feature: disable user And the HTTP status code should be "200" And user "Alice" should be disabled - @issue-31276 @notToImplementOnOCIS + @issue-31276 @skipOnOcV10 Scenario: Subadmin should not be able to disable an user not in their group Given these users have been created with default attributes and skeleton files: | username | @@ -56,12 +56,11 @@ Feature: disable user And user "Alice" has been added to group "another-group" And user "subadmin" has been made a subadmin of group "brand-new-group" When user "subadmin" disables user "Alice" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Alice" should be enabled - @issue-31276 @notToImplementOnOCIS + @issue-31276 @skipOnOcV10 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 skeleton files: | username | @@ -73,8 +72,7 @@ Feature: disable user And user "another-admin" has been added to group "brand-new-group" And user "subadmin" has been made a subadmin of group "brand-new-group" When user "subadmin" disables user "another-admin" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "another-admin" should be enabled @@ -106,15 +104,14 @@ Feature: disable user And the HTTP status code should be "400" And user "another-admin" should be enabled - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: disable an user with a regular user Given these users have been created with default attributes and skeleton files: | username | | Alice | | Brian | When user "Alice" disables user "Brian" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should be enabled diff --git a/tests/acceptance/features/apiProvisioning-v2/disableUserOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/disableUserOc10Issue31276.feature index 39313dbe4acc..af2abed4f5bc 100644 --- a/tests/acceptance/features/apiProvisioning-v2/disableUserOc10Issue31276.feature +++ b/tests/acceptance/features/apiProvisioning-v2/disableUserOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @provisioning_api-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS -Feature: disable user +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: current oC10 behavior for issue-31276 As an admin I want to be able to disable a user So that I can remove access to files and resources for a user, without actually deleting the files and resources @@ -20,7 +19,8 @@ Feature: disable user And user "Alice" has been added to group "another-group" And user "subadmin" has been made a subadmin of group "brand-new-group" When user "subadmin" disables user "Alice" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Alice" should be enabled @@ -36,7 +36,8 @@ Feature: disable user And user "another-admin" has been added to group "brand-new-group" And user "subadmin" has been made a subadmin of group "brand-new-group" When user "subadmin" disables user "another-admin" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And user "another-admin" should be enabled @@ -47,6 +48,7 @@ Feature: disable user | Alice | | Brian | When user "Alice" disables user "Brian" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should be enabled diff --git a/tests/acceptance/features/apiProvisioning-v2/enableApp.feature b/tests/acceptance/features/apiProvisioning-v2/enableApp.feature index d58cb05a769c..ab913906250a 100644 --- a/tests/acceptance/features/apiProvisioning-v2/enableApp.feature +++ b/tests/acceptance/features/apiProvisioning-v2/enableApp.feature @@ -15,24 +15,22 @@ Feature: enable an app And the HTTP status code should be "200" And app "comments" should be enabled - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: subadmin tries to enable an app Given user "subadmin" has been created with default attributes and skeleton files And group "brand-new-group" has been created And user "subadmin" has been made a subadmin of group "brand-new-group" And app "comments" has been disabled When user "subadmin" enables app "comments" - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And app "comments" should be disabled - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: normal user tries to enable an app Given user "brand-new-user" has been created with default attributes and skeleton files And app "comments" has been disabled When user "brand-new-user" enables app "comments" - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And app "comments" should be disabled diff --git a/tests/acceptance/features/apiProvisioning-v2/enableAppOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/enableAppOc10Issue31276.feature index 7ed873ee1860..bb9c35a0a43a 100644 --- a/tests/acceptance/features/apiProvisioning-v2/enableAppOc10Issue31276.feature +++ b/tests/acceptance/features/apiProvisioning-v2/enableAppOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @provisioning_api-app-required @comments-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS -Feature: enable an app +@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: enable an app - current oC10 behavior for issue-31276 As an admin I want to be able to enable a disabled app So that I can use the app features again @@ -15,7 +14,8 @@ Feature: enable an app And user "subadmin" has been made a subadmin of group "brand-new-group" And app "comments" has been disabled When user "subadmin" enables app "comments" - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And app "comments" should be disabled @@ -24,6 +24,7 @@ Feature: enable an app Given user "brand-new-user" has been created with default attributes and skeleton files And app "comments" has been disabled When user "brand-new-user" enables app "comments" - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And app "comments" should be disabled diff --git a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature index affb0d18c707..15a68e6d770c 100644 --- a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature @@ -60,7 +60,7 @@ Feature: enable user When user "another-admin" tries to enable user "another-admin" using the provisioning API Then user "another-admin" should be disabled - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: normal user tries to enable other user Given these users have been created with default attributes and skeleton files: | username | @@ -68,8 +68,7 @@ Feature: enable user | Brian | And user "Brian" has been disabled When user "Alice" tries to enable user "Brian" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should be disabled diff --git a/tests/acceptance/features/apiProvisioning-v2/enableUserOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/enableUserOc10Issue31276.feature index 2d8feee383cd..2181d404efc7 100644 --- a/tests/acceptance/features/apiProvisioning-v2/enableUserOc10Issue31276.feature +++ b/tests/acceptance/features/apiProvisioning-v2/enableUserOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @provisioning_api-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS -Feature: enable user +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: enable user - current oC10 behavior for issue-31276 As an admin I want to be able to enable a user So that I can give a user access to their files and resources again if they are now authorized for that @@ -14,6 +13,7 @@ Feature: enable user | Brian | And user "Brian" has been disabled When user "Alice" tries to enable user "Brian" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And user "Brian" should be disabled diff --git a/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature b/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature index 8d840faac7b2..b3707dcb9136 100644 --- a/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature +++ b/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature @@ -26,7 +26,7 @@ Feature: get subadmins And the HTTP status code should be "400" And the API should not return any data - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: subadmin tries to get other subadmins of the same group Given these users have been created with default attributes and skeleton files: | username | @@ -36,12 +36,11 @@ Feature: get subadmins And user "subadmin" has been made a subadmin of group "brand-new-group" And user "another-subadmin" has been made a subadmin of group "brand-new-group" When user "subadmin" gets all the subadmins of group "brand-new-group" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And the API should not return any data - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: normal user tries to get the subadmins of the group Given these users have been created with default attributes and skeleton files: | username | @@ -50,7 +49,6 @@ Feature: get subadmins And group "brand-new-group" has been created And user "subadmin" has been made a subadmin of group "brand-new-group" When user "brand-new-user" gets all the subadmins of group "brand-new-group" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And the API should not return any data diff --git a/tests/acceptance/features/apiProvisioning-v2/getSubAdminsOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/getSubAdminsOc10Issue31276.feature index ecc9bdc652b5..b8866a74b7ad 100644 --- a/tests/acceptance/features/apiProvisioning-v2/getSubAdminsOc10Issue31276.feature +++ b/tests/acceptance/features/apiProvisioning-v2/getSubAdminsOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @provisioning_api-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS -Feature: get subadmins +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: get subadmins - current oC10 behavior for issue-31276 As an admin I want to be able to get the list of subadmins of a group So that I can manage subadmins of a group @@ -18,7 +17,8 @@ Feature: get subadmins And user "subadmin" has been made a subadmin of group "brand-new-group" And user "another-subadmin" has been made a subadmin of group "brand-new-group" When user "subadmin" gets all the subadmins of group "brand-new-group" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And the API should not return any data @@ -31,6 +31,7 @@ Feature: get subadmins And group "brand-new-group" has been created And user "subadmin" has been made a subadmin of group "brand-new-group" When user "brand-new-user" gets all the subadmins of group "brand-new-group" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And the API should not return any data diff --git a/tests/acceptance/features/apiProvisioning-v2/getUser.feature b/tests/acceptance/features/apiProvisioning-v2/getUser.feature index 66ae5f8aca27..e799b6cc33e4 100644 --- a/tests/acceptance/features/apiProvisioning-v2/getUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/getUser.feature @@ -78,15 +78,14 @@ Feature: get user And the HTTP status code should be "401" And the API should not return any data - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: a normal user tries to get information of another user Given these users have been created with default attributes and skeleton files: | username | | brand-new-user | | another-new-user | When user "another-new-user" retrieves the information of user "brand-new-user" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And the API should not return any data diff --git a/tests/acceptance/features/apiProvisioning-v2/getUserOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/getUserOc10Issue31276.feature index ae42bf3948ed..f6b0f70f912c 100644 --- a/tests/acceptance/features/apiProvisioning-v2/getUserOc10Issue31276.feature +++ b/tests/acceptance/features/apiProvisioning-v2/getUserOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @provisioning_api-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS -Feature: get user +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: get user - current oC10 behavior for issue-31276 As an admin, subadmin or as myself I want to be able to retrieve user information So that I can see the information @@ -15,17 +14,7 @@ Feature: get user | brand-new-user | | another-new-user | When user "another-new-user" retrieves the information of user "brand-new-user" using the provisioning API - Then the OCS status code should be "401" - And the HTTP status code should be "401" - And the API should not return any data - - @issue-31276 - Scenario: normal user tries to get other users - Given these users have been created with default attributes and skeleton files: - | username | - | brand-new-user | - | another-new-user | - When user "brand-new-user" gets the list of all users using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And the API should not return any data diff --git a/tests/acceptance/features/apiProvisioning-v2/getUsers.feature b/tests/acceptance/features/apiProvisioning-v2/getUsers.feature index 9bffa3bb5149..485c59da2d42 100644 --- a/tests/acceptance/features/apiProvisioning-v2/getUsers.feature +++ b/tests/acceptance/features/apiProvisioning-v2/getUsers.feature @@ -40,14 +40,13 @@ Feature: get users And the OCS status code should be "200" And the HTTP status code should be "200" - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: normal user tries to get other users Given these users have been created with default attributes and skeleton files: | username | | brand-new-user | | another-new-user | When user "brand-new-user" gets the list of all users using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And the API should not return any data diff --git a/tests/acceptance/features/apiProvisioning-v2/getUsersOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/getUsersOc10Issue31276.feature new file mode 100644 index 000000000000..3f347d11528b --- /dev/null +++ b/tests/acceptance/features/apiProvisioning-v2/getUsersOc10Issue31276.feature @@ -0,0 +1,20 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: get users - current oC10 behavior for issue-31276 + As an admin, subadmin or as myself + I want to be able to retrieve user information + So that I can see the information + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: normal user tries to get other users + Given these users have been created with default attributes and skeleton files: + | username | + | brand-new-user | + | another-new-user | + When user "brand-new-user" gets the list of all users using the provisioning API + Then the OCS status code should be "997" + #Then the OCS status code should be "401" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature index 6f7d41358a9a..30d0c4f606fb 100644 --- a/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature +++ b/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature @@ -17,7 +17,7 @@ Feature: remove subadmin And the HTTP status code should be "200" And user "brand-new-user" should not be a subadmin of group "brand-new-group" - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: subadmin tries to remove other subadmin in the group Given these users have been created with default attributes and skeleton files: | username | @@ -27,12 +27,11 @@ Feature: remove subadmin And user "subadmin" has been made a subadmin of group "brand-new-group" And user "another-subadmin" has been made a subadmin of group "brand-new-group" When user "subadmin" removes user "another-subadmin" from being a subadmin of group "brand-new-group" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "another-subadmin" should be a subadmin of group "brand-new-group" - @issue-31276 + @issue-31276 @skipOnOcV10 Scenario: normal user tries to remove subadmin in the group Given these users have been created with default attributes and skeleton files: | username | @@ -42,7 +41,6 @@ Feature: remove subadmin And user "subadmin" has been made a subadmin of group "brand-new-group" And user "brand-new-user" has been added to group "brand-new-group" When user "brand-new-user" removes user "subadmin" from being a subadmin of group "brand-new-group" using the provisioning API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" And user "subadmin" should be a subadmin of group "brand-new-group" diff --git a/tests/acceptance/features/apiProvisioning-v2/removeSubAdminOc10Issue31276.feature b/tests/acceptance/features/apiProvisioning-v2/removeSubAdminOc10Issue31276.feature index 43705978c7fb..ca6e20510f66 100644 --- a/tests/acceptance/features/apiProvisioning-v2/removeSubAdminOc10Issue31276.feature +++ b/tests/acceptance/features/apiProvisioning-v2/removeSubAdminOc10Issue31276.feature @@ -1,6 +1,5 @@ -@api @provisioning_api-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS -Feature: remove subadmin +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS +Feature: remove subadmin - current oC10 behavior for issue-31276 As an admin I want to be able to remove subadmin rights to a user from a group So that I cam manage administrative access rights for groups @@ -18,7 +17,8 @@ Feature: remove subadmin And user "subadmin" has been made a subadmin of group "brand-new-group" And user "another-subadmin" has been made a subadmin of group "brand-new-group" When user "subadmin" removes user "another-subadmin" from being a subadmin of group "brand-new-group" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And user "another-subadmin" should be a subadmin of group "brand-new-group" @@ -32,6 +32,7 @@ Feature: remove subadmin And user "subadmin" has been made a subadmin of group "brand-new-group" And user "brand-new-user" has been added to group "brand-new-group" When user "brand-new-user" removes user "subadmin" from being a subadmin of group "brand-new-group" using the provisioning API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" And user "subadmin" should be a subadmin of group "brand-new-group" diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature index 9b4ace4c5839..843cec155725 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature @@ -58,22 +58,12 @@ Feature: add groups | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | - # Note: these groups do get created OK, but: - # 1) the "should exist" step fails because the API to check their existence does not work. - # 2) the ordinary group deletion in AfterScenario does not work, because the - # that group-delete API does not work for groups with a slash in the name - @issue-31015 + @issue-31015 @skipOnOcV10 Scenario Outline: admin creates a group with a forward-slash in the group name When the administrator sends a group creation request for group "" using the provisioning API Then the OCS status code should be "100" And the HTTP status code should be "200" - # After fixing issue-31015, change the following step to "should exist" - And group "" should not exist - #And group "" should exist - # - # The following step is needed so that the group does get cleaned up. - # After fixing issue-31015, remove the following step: - And the administrator deletes group "" using the occ command + And group "" should exist Examples: | group_id | comment | | Mgmt/Sydney | Slash (special escaping happens) | @@ -81,20 +71,15 @@ Feature: add groups | var/../etc | using slash-dot-dot | | priv/subadmins/1 | Subadmins mentioned not at the end | - # 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 + # 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 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 - # After fixing issue-31015, change the expected status to "101" - Then the OCS status code should be "100" - #Then the OCS status code should be "101" + Then the OCS status code should be "101" And the HTTP status code should be "200" And group "priv/subadmins" should not exist - # The following step is needed so that the group does get cleaned up. - # After fixing issue-31015, remove the following step: - And the administrator deletes group "priv/subadmins" using the occ command Scenario: admin tries to create a group that already exists Given group "brand-new-group" has been created diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addGroupOc10Issue31015.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addGroupOc10Issue31015.feature index fffda501551c..e19b328fa683 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/addGroupOc10Issue31015.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/addGroupOc10Issue31015.feature @@ -1,21 +1,27 @@ -@api @provisioning_api-app-required @skipOnLDAP -@skipOnOcV10 @notToImplementOnOCIS +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS Feature: add groups As an admin I want to be able to add groups So that I can more easily manage access to resources by groups rather than individual users + Background: + Given using OCS API version "1" + # Note: these groups do get created OK, but: # 1) the "should exist" step fails because the API to check their existence does not work. # 2) the ordinary group deletion in AfterScenario does not work, because the - # that group-delete API does not work for groups with a slash in the name + # group-delete API does not work for groups with a slash in the name @issue-31015 Scenario Outline: admin creates a group with a forward-slash in the group name - Given using OCS API version "1" When the administrator sends a group creation request for group "" using the provisioning API Then the OCS status code should be "100" And the HTTP status code should be "200" - And group "" should exist + And group "" should not exist + #And group "" should exist + # + # The following step is needed so that the group does get cleaned up. + # After fixing issue-31015, this should not be needed. + And the administrator deletes group "" using the occ command Examples: | group_id | comment | | Mgmt/Sydney | Slash (special escaping happens) | @@ -23,12 +29,16 @@ Feature: add groups | var/../etc | using slash-dot-dot | | priv/subadmins/1 | Subadmins mentioned not at the end | - # A group name must not end in "/subadmins" because that would create ambiguity - # with the endpoint for getting the subadmins of a group + # 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 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 - Then the OCS status code should be "101" + Then the OCS status code should be "100" + #Then the OCS status code should be "101" And the HTTP status code should be "200" And group "priv/subadmins" should not exist + # The following step is needed so that the group does get cleaned up. + # After fixing issue-31015, this should not be needed. + And the administrator deletes group "priv/subadmins" using the occ command diff --git a/tests/acceptance/features/apiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature index 6a3c8955aa48..6ea07cbf7532 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature @@ -1,4 +1,4 @@ -@api @files_sharing-app-required @notToImplementOnOCIS +@api @files_sharing-app-required Feature: share resources with a disabled user Background: @@ -15,12 +15,11 @@ Feature: share resources with a disabled user | ocs_api_version | ocs_status_code | | 1 | 997 | - @issue-32068 + @issue-32068 @skipOnOcV10 Scenario: Creating a new share with a disabled user Given using OCS API version "2" And user "Brian" has been created with default attributes and without skeleton files And user "Alice" has been disabled When user "Alice" shares file "welcome.txt" with user "Brian" using the sharing API - Then the OCS status code should be "997" - #And the OCS status code should be "401" + Then the OCS status code should be "401" And the HTTP status code should be "401" diff --git a/tests/acceptance/features/apiShareCreateSpecial2/createShareWithDisabledUserOc10Issue32068.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot2/createShareWithDisabledUserOc10Issue32068.feature similarity index 57% rename from tests/acceptance/features/apiShareCreateSpecial2/createShareWithDisabledUserOc10Issue32068.feature rename to tests/acceptance/features/apiShareCreateSpecialToRoot2/createShareWithDisabledUserOc10Issue32068.feature index 15c103cd76cd..7ddc4a69b1b3 100644 --- a/tests/acceptance/features/apiShareCreateSpecial2/createShareWithDisabledUserOc10Issue32068.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToRoot2/createShareWithDisabledUserOc10Issue32068.feature @@ -1,13 +1,15 @@ -@api @files_sharing-app-required @issue-ocis-reva-243 -@skipOnOcV10 @notToImplementOnOCIS -Feature: share resources with a disabled user +@api @files_sharing-app-required @issue-ocis-reva-243 @notToImplementOnOCIS +Feature: share resources with a disabled user - current oC10 behavior for issue-32068 + + Background: + Given user "Alice" has been created with default attributes and skeleton files @issue-32068 Scenario: Creating a new share with a disabled user - Given user "Alice" has been created with default attributes and skeleton files - And using OCS API version "2" + Given using OCS API version "2" And user "Brian" has been created with default attributes and without skeleton files And user "Alice" has been disabled When user "Alice" shares file "welcome.txt" with user "Brian" using the sharing API - Then the OCS status code should be "401" + Then the OCS status code should be "997" + #Then the OCS status code should be "401" And the HTTP status code should be "401" diff --git a/tests/acceptance/features/apiShareManagementToRoot/moveReceivedShare.feature b/tests/acceptance/features/apiShareManagementToRoot/moveReceivedShare.feature index 4d6635be95a4..140611b9a781 100644 --- a/tests/acceptance/features/apiShareManagementToRoot/moveReceivedShare.feature +++ b/tests/acceptance/features/apiShareManagementToRoot/moveReceivedShare.feature @@ -1,4 +1,4 @@ -@api @files_sharing-app-required @notToImplementOnOCIS +@api @files_sharing-app-required Feature: sharing Background: @@ -74,19 +74,16 @@ Feature: sharing And as "Alice" file "/folderToShare/renamedFile" should exist But as "Alice" file "/folderToShare/fileInside" should not exist - @issue-30325 + @issue-30325 @skipOnOcV10 Scenario: receiver tries to rename a received share with share, read permissions Given user "Alice" has created folder "folderToShare" And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside" And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read" When user "Brian" moves folder "folderToShare" to "myFolder" using the WebDAV API - Then the HTTP status code should be "403" -# Then the HTTP status code should be "201" - And as "Brian" folder "myFolder" should not exist -# And as "Brian" folder "myFolder" should exist + Then the HTTP status code should be "201" + And as "Brian" folder "myFolder" should exist But as "Alice" folder "myFolder" should not exist -# When user "Brian" moves file "/myFolder/fileInside" to "/myFolder/renamedFile" using the WebDAV API - When user "Brian" moves file "/folderToShare/fileInside" to "/folderToShare/renamedFile" using the WebDAV API + When user "Brian" moves file "/myFolder/fileInside" to "/myFolder/renamedFile" using the WebDAV API Then the HTTP status code should be "403" - And as "Brian" file "/folderToShare/renamedFile" should not exist - But as "Brian" file "/folderToShare/fileInside" should exist + And as "Brian" file "/myFolder/renamedFile" should not exist + But as "Brian" file "/myFolder/fileInside" should exist diff --git a/tests/acceptance/features/apiShareManagement/moveReceivedShareOc10Issue30325.feature b/tests/acceptance/features/apiShareManagementToRoot/moveReceivedShareOc10Issue30325.feature similarity index 53% rename from tests/acceptance/features/apiShareManagement/moveReceivedShareOc10Issue30325.feature rename to tests/acceptance/features/apiShareManagementToRoot/moveReceivedShareOc10Issue30325.feature index fa25b4bf8346..4da7e6e66f50 100644 --- a/tests/acceptance/features/apiShareManagement/moveReceivedShareOc10Issue30325.feature +++ b/tests/acceptance/features/apiShareManagementToRoot/moveReceivedShareOc10Issue30325.feature @@ -1,23 +1,29 @@ -@api @files_sharing-app-required @issue-ocis-reva-14 @issue-ocis-reva-243 -@skipOnOcV10 @notToImplementOnOCIS -Feature: sharing +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing - current oC10 behavior for issue-30325 - @issue-30325 - Scenario: receiver tries to rename a received share with share, read permissions + Background: Given using OCS API version "1" And these users have been created with default attributes and skeleton files: | username | | Alice | | Brian | | Carol | - And user "Alice" has created folder "folderToShare" + + @issue-30325 + Scenario: receiver tries to rename a received share with share, read permissions + Given user "Alice" has created folder "folderToShare" And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside" And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read" When user "Brian" moves folder "folderToShare" to "myFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "myFolder" should exist + Then the HTTP status code should be "403" +# Then the HTTP status code should be "201" + And as "Brian" folder "myFolder" should not exist +# And as "Brian" folder "myFolder" should exist But as "Alice" folder "myFolder" should not exist - When user "Brian" moves file "/myFolder/fileInside" to "/myFolder/renamedFile" using the WebDAV API +# When user "Brian" moves file "/myFolder/fileInside" to "/myFolder/renamedFile" using the WebDAV API + When user "Brian" moves file "/folderToShare/fileInside" to "/folderToShare/renamedFile" using the WebDAV API Then the HTTP status code should be "403" And as "Brian" file "/folderToShare/renamedFile" should not exist +# And as "Brian" file "/myFolder/renamedFile" should not exist But as "Brian" file "/folderToShare/fileInside" should exist +# But as "Brian" file "/myFolder/fileInside" should exist