diff --git a/tests/acceptance/features/coreApiAuth/cors.feature b/tests/acceptance/features/coreApiAuth/cors.feature new file mode 100644 index 00000000000..ca0c21ef6d3 --- /dev/null +++ b/tests/acceptance/features/coreApiAuth/cors.feature @@ -0,0 +1,209 @@ +@api @issue-ocis-reva-26 @issue-ocis-reva-27 @skipOnOcis +Feature: CORS headers + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + 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 + When user "Alice" sends HTTP method "GET" to OCS API endpoint "" with headers + | header | value | + | Origin | https://aphno.badal | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the following headers should be set + | header | value | + | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,OC-RequestAppPassword,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,Cache-Control,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,OC-RequestAppPassword,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 | /privatedata/getattribute | 100 | 200 | + | 2 | /privatedata/getattribute | 200 | 200 | + | 1 | /cloud/apps | 997 | 401 | + | 2 | /cloud/apps | 997 | 401 | + | 1 | /cloud/groups | 997 | 401 | + | 2 | /cloud/groups | 997 | 401 | + | 1 | /cloud/users | 997 | 401 | + | 2 | /cloud/users | 997 | 401 | + | 1 | /config | 100 | 200 | + | 2 | /config | 200 | 200 | + + @files_external-app-required @notToImplementOnOCIS + Examples: + | ocs_api_version | endpoint | ocs-code | http-code | + | 1 | /apps/files_external/api/v1/mounts | 100 | 200 | + | 2 | /apps/files_external/api/v1/mounts | 200 | 200 | + + @files_sharing-app-required + Examples: + | ocs_api_version | endpoint | ocs-code | http-code | + | 1 | /apps/files_sharing/api/v1/remote_shares | 100 | 200 | + | 2 | /apps/files_sharing/api/v1/remote_shares | 200 | 200 | + | 1 | /apps/files_sharing/api/v1/remote_shares/pending | 100 | 200 | + | 2 | /apps/files_sharing/api/v1/remote_shares/pending | 200 | 200 | + | 1 | /apps/files_sharing/api/v1/shares | 100 | 200 | + | 2 | /apps/files_sharing/api/v1/shares | 200 | 200 | + + + Scenario Outline: CORS headers should be returned when setting CORS domain sending Origin header (admin only endpoints) + Given using OCS API version "" + And the administrator has added "https://aphno.badal" to the list of personal CORS domains + When the administrator sends HTTP method "GET" to OCS API endpoint "" with headers + | header | value | + | Origin | https://aphno.badal | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the following headers should be set + | header | value | + | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,OC-RequestAppPassword,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,Cache-Control,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,OC-RequestAppPassword,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 | 100 | 200 | + | 2 | /cloud/apps | 200 | 200 | + | 1 | /cloud/groups | 100 | 200 | + | 2 | /cloud/groups | 200 | 200 | + | 1 | /cloud/users | 100 | 200 | + | 2 | /cloud/users | 200 | 200 | + + + Scenario Outline: no CORS headers should be returned when CORS domain does not match Origin header + Given using OCS API version "" + And user "Alice" has added "https://mero.badal" to the list of personal CORS domains + When user "Alice" sends HTTP method "GET" to OCS API endpoint "" with headers + | header | value | + | Origin | https://aphno.badal | + Then the OCS status code should be "" + And the HTTP status code should be "" + And 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 | + | 2 | /config | 200 | 200 | + | 1 | /privatedata/getattribute | 100 | 200 | + | 2 | /privatedata/getattribute | 200 | 200 | + | 1 | /cloud/apps | 997 | 401 | + | 2 | /cloud/apps | 997 | 401 | + | 1 | /cloud/groups | 997 | 401 | + | 2 | /cloud/groups | 997 | 401 | + | 1 | /cloud/users | 997 | 401 | + | 2 | /cloud/users | 997 | 401 | + + @files_external-app-required @notToImplementOnOCIS + Examples: + | ocs_api_version | endpoint | ocs-code | http-code | + | 1 | /apps/files_external/api/v1/mounts | 100 | 200 | + | 2 | /apps/files_external/api/v1/mounts | 200 | 200 | + + @files_sharing-app-required + Examples: + | ocs_api_version | endpoint | ocs-code | http-code | + | 1 | /apps/files_sharing/api/v1/remote_shares | 100 | 200 | + | 2 | /apps/files_sharing/api/v1/remote_shares | 200 | 200 | + | 1 | /apps/files_sharing/api/v1/remote_shares/pending | 100 | 200 | + | 2 | /apps/files_sharing/api/v1/remote_shares/pending | 200 | 200 | + | 1 | /apps/files_sharing/api/v1/shares | 100 | 200 | + | 2 | /apps/files_sharing/api/v1/shares | 200 | 200 | + + + Scenario Outline: no CORS headers should be returned when CORS domain does not match Origin header (admin only endpoints) + Given using OCS API version "" + And the administrator has added "https://mero.badal" to the list of personal CORS domains + When the administrator sends HTTP method "GET" to OCS API endpoint "" with headers + | header | value | + | Origin | https://aphno.badal | + Then the OCS status code should be "" + And the HTTP status code should be "" + And 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 | /cloud/apps | 100 | 200 | + | 2 | /cloud/apps | 200 | 200 | + | 1 | /cloud/groups | 100 | 200 | + | 2 | /cloud/groups | 200 | 200 | + | 1 | /cloud/users | 100 | 200 | + | 2 | /cloud/users | 200 | 200 | + + @issue-34679 @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 + When user "Alice" sends HTTP method "GET" to OCS API endpoint "" with headers using password "invalid" + | header | value | + | Origin | https://aphno.badal | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the following headers should be set + | header | value | + | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,OC-RequestAppPassword,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,Cache-Control,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,OC-RequestAppPassword,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 | /privatedata/getattribute | 997 | 401 | + | 2 | /privatedata/getattribute | 997 | 401 | + | 1 | /cloud/apps | 997 | 401 | + | 2 | /cloud/apps | 997 | 401 | + | 1 | /cloud/groups | 997 | 401 | + | 2 | /cloud/groups | 997 | 401 | + | 1 | /cloud/users | 997 | 401 | + | 2 | /cloud/users | 997 | 401 | + + @files_external-app-required @notToImplementOnOCIS + Examples: + | ocs_api_version | endpoint | ocs-code | http-code | + | 1 | /apps/files_external/api/v1/mounts | 997 | 401 | + | 2 | /apps/files_external/api/v1/mounts | 997 | 401 | + + @files_sharing-app-required + Examples: + | ocs_api_version | endpoint | ocs-code | http-code | + | 1 | /apps/files_sharing/api/v1/remote_shares | 997 | 401 | + | 2 | /apps/files_sharing/api/v1/remote_shares | 997 | 401 | + | 1 | /apps/files_sharing/api/v1/remote_shares/pending | 997 | 401 | + | 2 | /apps/files_sharing/api/v1/remote_shares/pending | 997 | 401 | + | 1 | /apps/files_sharing/api/v1/shares | 997 | 401 | + | 2 | /apps/files_sharing/api/v1/shares | 997 | 401 | + + @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 + And user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When user "another-admin" sends HTTP method "GET" to OCS API endpoint "" with headers using password "invalid" + | header | value | + | Origin | https://aphno.badal | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the following headers should be set + | header | value | + | Access-Control-Allow-Headers | OC-Checksum,OC-Total-Length,OCS-APIREQUEST,X-OC-Mtime,OC-RequestAppPassword,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,Cache-Control,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,OC-RequestAppPassword,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 | + | 2 | /cloud/apps | 997 | 401 | + | 1 | /cloud/groups | 997 | 401 | + | 2 | /cloud/groups | 997 | 401 | + | 1 | /cloud/users | 997 | 401 | + | 2 | /cloud/users | 997 | 401 | diff --git a/tests/acceptance/features/coreApiAuth/corsOc10Issue34679.feature b/tests/acceptance/features/coreApiAuth/corsOc10Issue34679.feature new file mode 100644 index 00000000000..a3ece05bacd --- /dev/null +++ b/tests/acceptance/features/coreApiAuth/corsOc10Issue34679.feature @@ -0,0 +1,85 @@ +@api @notToImplementOnOCIS +Feature: CORS headers current oC10 behavior for issue-34679 + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @issue-34679 + 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 + When user "Alice" sends HTTP method "GET" to OCS API endpoint "" with headers using password "invalid" + | header | value | + | Origin | https://aphno.badal | + Then the OCS status code should be "" + And the HTTP status code should be "" + And 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 | /privatedata/getattribute | 997 | 401 | + | 2 | /privatedata/getattribute | 997 | 401 | + | 1 | /cloud/apps | 997 | 401 | + | 2 | /cloud/apps | 997 | 401 | + | 1 | /cloud/groups | 997 | 401 | + | 2 | /cloud/groups | 997 | 401 | + | 1 | /cloud/users | 997 | 401 | + | 2 | /cloud/users | 997 | 401 | + + @files_external-app-required @notToImplementOnOCIS + Examples: + | ocs_api_version | endpoint | ocs-code | http-code | + | 1 | /apps/files_external/api/v1/mounts | 997 | 401 | + | 2 | /apps/files_external/api/v1/mounts | 997 | 401 | + + @files_sharing-app-required + Examples: + | ocs_api_version | endpoint | ocs-code | http-code | + | 1 | /apps/files_sharing/api/v1/remote_shares | 997 | 401 | + | 2 | /apps/files_sharing/api/v1/remote_shares | 997 | 401 | + | 1 | /apps/files_sharing/api/v1/remote_shares/pending | 997 | 401 | + | 2 | /apps/files_sharing/api/v1/remote_shares/pending | 997 | 401 | + | 1 | /apps/files_sharing/api/v1/shares | 997 | 401 | + | 2 | /apps/files_sharing/api/v1/shares | 997 | 401 | + + @issue-34679 + 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 + And user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When user "another-admin" sends HTTP method "GET" to OCS API endpoint "" with headers using password "invalid" + | header | value | + | Origin | https://aphno.badal | + Then the OCS status code should be "" + And the HTTP status code should be "" + And 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 | + | 2 | /cloud/apps | 997 | 401 | + | 1 | /cloud/groups | 997 | 401 | + | 2 | /cloud/groups | 997 | 401 | + | 1 | /cloud/users | 997 | 401 | + | 2 | /cloud/users | 997 | 401 | diff --git a/tests/acceptance/features/coreApiAuth/filesAppAuth.feature b/tests/acceptance/features/coreApiAuth/filesAppAuth.feature new file mode 100644 index 00000000000..d4636b295e6 --- /dev/null +++ b/tests/acceptance/features/coreApiAuth/filesAppAuth.feature @@ -0,0 +1,40 @@ +@api @notToImplementOnOCIS @issue-ocis-reva-28 +Feature: auth + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario: access files app anonymously + When a user requests "/index.php/apps/files" with "GET" and no authentication + Then the HTTP status code should be "401" + + @smokeTest + Scenario: access files app with basic auth + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth + Then the HTTP status code should be "200" + + @smokeTest + Scenario: access files app with basic token auth + Given a new client token for "Alice" has been generated + When user "Alice" requests "/index.php/apps/files" with "GET" using basic token auth + Then the HTTP status code should be "200" + + @smokeTest + Scenario: access files app with a client token + Given a new client token for "Alice" has been generated + When the user requests "/index.php/apps/files" with "GET" using the generated client token + Then the HTTP status code should be "200" + + @smokeTest + Scenario: access files app with browser session + Given a new browser session for "Alice" has been started + When the user requests "/index.php/apps/files" with "GET" using the browser session + Then the HTTP status code should be "200" + + @smokeTest + Scenario: access files app with an app password + Given a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests "/index.php/apps/files" with "GET" using the generated app password + Then the HTTP status code should be "200" diff --git a/tests/acceptance/features/coreApiAuth/tokenAuth.feature b/tests/acceptance/features/coreApiAuth/tokenAuth.feature new file mode 100644 index 00000000000..cef3c2bbee4 --- /dev/null +++ b/tests/acceptance/features/coreApiAuth/tokenAuth.feature @@ -0,0 +1,61 @@ +@api @notToImplementOnOCIS @issue-ocis-reva-28 @issue-ocis-reva-37 +Feature: tokenAuth + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + And token auth has been enforced + + + Scenario: creating a user with basic auth should be blocked when token auth is enforced + Given user "brand-new-user" has been deleted + When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + + + Scenario: moving a file should be blocked when token auth is enforced + Given using new DAV path + When user "Alice" moves file "/textfile0.txt" to "/renamed_textfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + + @smokeTest + Scenario: can access files app with an app password when token auth is enforced + Given a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests "/index.php/apps/files" with "GET" using the generated app password + Then the HTTP status code should be "200" + + + Scenario: cannot access files app with an app password that is deleted when token auth is enforced + Given a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + And the user has deleted the app password named "my-client" + When the user requests "/index.php/apps/files" with "GET" using the generated app password + Then the HTTP status code should be "401" + + + Scenario: Access files app with when there are multiple tokens generated + Given a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + And the user has generated a new app password named "my-new-client" + When the user requests "/index.php/apps/files" with "GET" using app password named "my-client" + Then the HTTP status code should be "200" + When the user requests "/index.php/apps/files" with "GET" using app password named "my-new-client" + Then the HTTP status code should be "200" + + @smokeTest + Scenario: cannot access files app with basic auth when token auth is enforced + When user "Alice" requests "/index.php/apps/files" with "GET" using basic auth + Then the HTTP status code should be "401" + + + Scenario: using WebDAV with basic auth should be blocked when token auth is enforced + When user "Alice" requests "/remote.php/webdav" with "PROPFIND" using basic auth + Then the HTTP status code should be "401" + + @files_sharing-app-required + Scenario: using OCS with basic auth should be blocked when token auth is enforced + When user "Alice" requests "/ocs/v1.php/apps/files_sharing/api/v1/remote_shares" with "GET" using basic auth + Then the OCS status code should be "997" + And the HTTP status code should be "401" diff --git a/tests/acceptance/features/coreApiAuth/webDavAuth.feature b/tests/acceptance/features/coreApiAuth/webDavAuth.feature new file mode 100644 index 00000000000..fadc2cbeee9 --- /dev/null +++ b/tests/acceptance/features/coreApiAuth/webDavAuth.feature @@ -0,0 +1,40 @@ +@api +Feature: auth + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario: using WebDAV anonymously + When a user requests "/remote.php/webdav" with "PROPFIND" and no authentication + Then the HTTP status code should be "401" + + @smokeTest @skipOnOcV10 @personalSpace + Scenario: using spaces WebDAV anonymously + When user "Alice" requests "/dav/spaces/%spaceid%" with "PROPFIND" and no authentication + Then the HTTP status code should be "401" + + @smokeTest + Scenario Outline: using WebDAV with basic auth + When user "Alice" requests "" with "PROPFIND" using basic auth + Then the HTTP status code should be "207" + Examples: + | dav_path | + | /remote.php/webdav | + + @skipOnOcV10 @personalSpace + Examples: + | dav_path | + | /dav/spaces/%spaceid% | + + @smokeTest @notToImplementOnOCIS @issue-ocis-reva-28 + Scenario: using WebDAV with token auth + Given a new client token for "Alice" has been generated + When user "Alice" requests "/remote.php/webdav" with "PROPFIND" using basic token auth + Then the HTTP status code should be "207" + + @smokeTest @notToImplementOnOCIS + Scenario: using WebDAV with browser session + Given a new browser session for "Alice" has been started + When the user requests "/remote.php/webdav" with "PROPFIND" using the browser session + Then the HTTP status code should be "207" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuth.feature b/tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuth.feature new file mode 100644 index 00000000000..676cf84b26c --- /dev/null +++ b/tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuth.feature @@ -0,0 +1,30 @@ +@api @files_sharing-app-required +Feature: auth + + Background: + Given user "another-admin" has been created with default attributes and without skeleton files + + @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" + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending/123 | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/shares/123 | + | /ocs/v1.php/apps/files_sharing/api/v1/shares/pending/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/shares/pending/123 | + | /ocs/v1.php/cloud/apps/testing | + | /ocs/v2.php/cloud/apps/testing | + | /ocs/v1.php/cloud/groups/group1 | + | /ocs/v2.php/cloud/groups/group1 | + | /ocs/v1.php/cloud/users/%username% | + | /ocs/v2.php/cloud/users/%username% | + | /ocs/v1.php/cloud/users/%username%/groups | + | /ocs/v2.php/cloud/users/%username%/groups | + | /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" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuthOc10Issue32068.feature b/tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuthOc10Issue32068.feature new file mode 100644 index 00000000000..e185ae46972 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthOcs/ocsDELETEAuthOc10Issue32068.feature @@ -0,0 +1,29 @@ +@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 + Scenario: send DELETE requests to OCS endpoints as admin with wrong password + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When user "another-admin" requests these endpoints with "DELETE" using password "invalid" about user "Alice" + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending/123 | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/shares/123 | + | /ocs/v1.php/apps/files_sharing/api/v1/shares/pending/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/shares/pending/123 | + | /ocs/v1.php/cloud/apps/testing | + | /ocs/v2.php/cloud/apps/testing | + | /ocs/v1.php/cloud/groups/group1 | + | /ocs/v2.php/cloud/groups/group1 | + | /ocs/v1.php/cloud/users/%username% | + | /ocs/v2.php/cloud/users/%username% | + | /ocs/v1.php/cloud/users/%username%/groups | + | /ocs/v2.php/cloud/users/%username%/groups | + | /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/coreApiAuthOcs/ocsGETAuth.feature b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuth.feature new file mode 100644 index 00000000000..9bdba239a16 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuth.feature @@ -0,0 +1,248 @@ +@api @files_sharing-app-required +Feature: auth + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @issue-32068 @skipOnOcV10 @issue-ocis-reva-30 @smokeTest + Scenario: using OCS anonymously + When a user requests these endpoints with "GET" and no authentication + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/cloud/apps | + | /ocs/v2.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v2.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /ocs/v2.php/cloud/users | + | /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" + + @issue-ocis-reva-29 + Scenario: ocs config end point accessible by unauthorized users + When a user requests these endpoints with "GET" and no authentication + | endpoint | + | /ocs/v1.php/config | + 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 "100" + When a user requests these endpoints with "GET" and no authentication + | endpoint | + | /ocs/v2.php/config | + 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 @skipOnOcV10 @issue-ocis-reva-11 @issue-ocis-reva-30 @issue-ocis-reva-31 @issue-ocis-reva-32 @issue-ocis-reva-33 @issue-ocis-reva-34 @issue-ocis-reva-35 + Scenario: using OCS with non-admin basic auth + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/config | + | /ocs/v1.php/privatedata/getattribute | + 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 "100" + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/config | + | /ocs/v2.php/privatedata/getattribute | + 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" + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v1.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /ocs/v2.php/cloud/apps | + | /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" + + @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 + When user "Alice" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/cloud/apps | + | /ocs/v2.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v2.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /ocs/v2.php/cloud/users | + | /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" + When user "Alice" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v1.php/config | + 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 "100" + When user "Alice" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v2.php/config | + 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-ocis-reva-65 + Scenario:using OCS with admin basic auth + When the administrator requests these endpoint with "GET" + | endpoint | + | /ocs/v1.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v1.php/cloud/users | + 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 "100" + When the administrator requests these endpoint with "GET" + | endpoint | + | /ocs/v2.php/cloud/apps | + | /ocs/v2.php/cloud/groups | + | /ocs/v2.php/cloud/users | + 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-ocis-reva-30 @issue-ocis-reva-65 @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: using OCS as admin user with wrong password + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When user "another-admin" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/cloud/apps | + | /ocs/v2.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v2.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /ocs/v2.php/cloud/users | + | /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" + When user "another-admin" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v1.php/config | + 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 "100" + When user "another-admin" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v2.php/config | + 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" + + @notToImplementOnOCIS @issue-ocis-reva-30 @issue-ocis-reva-28 + Scenario: using OCS with token auth of a normal user + Given a new client token for "Alice" has been generated + When user "Alice" requests these endpoints with "GET" using basic token auth + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/config | + | /ocs/v1.php/privatedata/getattribute | + 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 "100" + When user "Alice" requests these endpoints with "GET" using basic token auth + | endpoint | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/config | + | /ocs/v2.php/privatedata/getattribute | + 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" + When user "Alice" requests these endpoints with "GET" using basic token auth + | endpoint | + | /ocs/v1.php/cloud/apps | + | /ocs/v1.php/cloud/users | + | /ocs/v1.php/cloud/groups | + | /ocs/v2.php/cloud/apps | + | /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" + + @notToImplementOnOCIS + Scenario: using OCS with browser session of normal user + Given a new browser session for "Alice" has been started + When the user requests these endpoints with "GET" using a new browser session + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/config | + | /ocs/v1.php/privatedata/getattribute | + 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 "100" + When the user requests these endpoints with "GET" using a new browser session + | endpoint | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/config | + | /ocs/v2.php/privatedata/getattribute | + 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" + When the user requests these endpoints with "GET" using a new browser session + | endpoint | + | /ocs/v1.php/cloud/apps | + | /ocs/v2.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v2.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /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" + + @notToImplementOnOCIS + Scenario: using OCS with an app password of a normal user + Given a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "GET" using the generated app password + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/config | + | /ocs/v1.php/privatedata/getattribute | + 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 "100" + When the user requests these endpoints with "GET" using the generated app password + | endpoint | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/config | + | /ocs/v2.php/privatedata/getattribute | + 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" + When the user requests these endpoints with "GET" using the generated app password + | endpoint | + | /ocs/v1.php/cloud/apps | + | /ocs/v2.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v2.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /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" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternal.feature b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternal.feature new file mode 100644 index 00000000000..df7fb37012b --- /dev/null +++ b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternal.feature @@ -0,0 +1,90 @@ +@api @files_external-app-required @notToImplementOnOCIS +Feature: auth + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @issue-32068 @skipOnOcV10 @smokeTest + Scenario: using OCS anonymously + When a user requests these endpoints with "GET" and no authentication + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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" + + @issue-32068 @skipOnOcV10 + Scenario: using OCS with non-admin basic auth + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + 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 "100" + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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 @skipOnOcV10 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: using OCS as normal user with wrong password + When user "Alice" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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" + + + Scenario: using OCS as admin user with wrong password + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When user "another-admin" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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" + + + Scenario: using OCS with token auth of a normal user + Given a new client token for "Alice" has been generated + When user "Alice" requests these endpoints with "GET" using basic token auth + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + 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 "100" + When user "Alice" requests these endpoints with "GET" using basic token auth + | endpoint | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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" + + + Scenario: using OCS with browser session of normal user + Given a new browser session for "Alice" has been started + When the user requests these endpoints with "GET" using a new browser session + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + 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 "100" + When the user requests these endpoints with "GET" using a new browser session + | endpoint | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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" + + + Scenario: using OCS with an app password of a normal user + Given a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "GET" using the generated app password + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + 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 "100" + When the user requests these endpoints with "GET" using the generated app password + | endpoint | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature new file mode 100644 index 00000000000..6d1b225a0cb --- /dev/null +++ b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthFilesExternalOc10Issue32068.feature @@ -0,0 +1,38 @@ +@api @notToImplementOnOCIS @files_external-app-required @issue-32068 +Feature: current oC10 behavior for issue-32068 + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario: using OCS anonymously + When a user requests these endpoints with "GET" and no authentication + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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" + + + Scenario: using OCS with non-admin basic auth + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + 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 "100" + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: using OCS as normal user with wrong password + When user "Alice" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v1.php/apps/files_external/api/v1/mounts | + | /ocs/v2.php/apps/files_external/api/v1/mounts | + 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/coreApiAuthOcs/ocsGETAuthOc10Issue32068.feature b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthOc10Issue32068.feature new file mode 100644 index 00000000000..3f1f08b82c2 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuthOc10Issue32068.feature @@ -0,0 +1,91 @@ +@api @notToImplementOnOCIS @files_sharing-app-required @issue-32068 +Feature: current oC10 behavior for issue-32068 + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @issue-32068 @issue-ocis-reva-30 @smokeTest + Scenario: using OCS anonymously + When a user requests these endpoints with "GET" and no authentication + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/cloud/apps | + | /ocs/v2.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v2.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /ocs/v2.php/cloud/users | + | /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-32068 @issue-ocis-reva-11 @issue-ocis-reva-30 @issue-ocis-reva-31 @issue-ocis-reva-32 @issue-ocis-reva-33 @issue-ocis-reva-34 @issue-ocis-reva-35 + Scenario: using OCS with non-admin basic auth + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/config | + | /ocs/v1.php/privatedata/getattribute | + 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 "100" + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/config | + | /ocs/v2.php/privatedata/getattribute | + 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" + When the user "Alice" requests these endpoints with "GET" with basic auth + | endpoint | + | /ocs/v1.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /ocs/v2.php/cloud/apps | + | /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 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: using OCS as normal user with wrong password + When user "Alice" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/cloud/apps | + | /ocs/v2.php/cloud/apps | + | /ocs/v1.php/cloud/groups | + | /ocs/v2.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /ocs/v2.php/cloud/users | + | /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 | + 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 "100" + When user "Alice" requests these endpoints with "GET" using password "invalid" + | endpoint | + | /ocs/v2.php/config | + 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" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsPOSTAuth.feature b/tests/acceptance/features/coreApiAuthOcs/ocsPOSTAuth.feature new file mode 100644 index 00000000000..9b10a64ee6f --- /dev/null +++ b/tests/acceptance/features/coreApiAuthOcs/ocsPOSTAuth.feature @@ -0,0 +1,42 @@ +@api @files_sharing-app-required +Feature: auth + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @issue-ocis-reva-30 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send POST requests to OCS endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending/123 | + | /ocs/v1.php/apps/files_sharing/api/v1/shares | + | /ocs/v2.php/apps/files_sharing/api/v1/shares | + | /ocs/v1.php/apps/files_sharing/api/v1/shares/pending/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/shares/pending/123 | + | /ocs/v1.php/cloud/apps/testing | + | /ocs/v2.php/cloud/apps/testing | + | /ocs/v1.php/cloud/groups | + | /ocs/v2.php/cloud/groups | + | /ocs/v1.php/cloud/users | + | /ocs/v2.php/cloud/users | + | /ocs/v1.php/cloud/users/%username%/groups | + | /ocs/v2.php/cloud/users/%username%/groups | + | /ocs/v1.php/cloud/users/%username%/subadmins | + | /ocs/v2.php/cloud/users/%username%/subadmins | + | /ocs/v1.php/privatedata/deleteattribute/testing/test | + | /ocs/v2.php/privatedata/deleteattribute/testing/test | + | /ocs/v1.php/privatedata/setattribute/testing/test | + | /ocs/v2.php/privatedata/setattribute/testing/test | + 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" + When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /ocs/v1.php/person/check | + 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 "101" + When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /ocs/v2.php/person/check | + Then the HTTP status code of responses on all endpoints should be "400" + And the OCS status code of responses on all endpoints should be "400" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsPUTAuth.feature b/tests/acceptance/features/coreApiAuthOcs/ocsPUTAuth.feature new file mode 100644 index 00000000000..c6101795534 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthOcs/ocsPUTAuth.feature @@ -0,0 +1,31 @@ +@api @files_sharing-app-required +Feature: auth + + Background: + Given user "another-admin" has been created with default attributes and without skeleton files + + @issue-ocis-reva-30 @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PUT request 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 "PUT" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /ocs/v1.php/cloud/users/%username% | + | /ocs/v2.php/cloud/users/%username% | + | /ocs/v1.php/cloud/users/%username%/disable | + | /ocs/v2.php/cloud/users/%username%/disable | + | /ocs/v1.php/cloud/users/%username%/enable | + | /ocs/v2.php/cloud/users/%username%/enable | + | /ocs/v1.php/apps/files_sharing/api/v1/shares/123 | + | /ocs/v2.php/apps/files_sharing/api/v1/shares/123 | + 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" + + @issue-38423 @skipOnOcV10 + Scenario: Request to edit nonexistent user by authorized admin gets unauthorized in http response + Given user "another-admin" has been added to group "admin" + When user "another-admin" requests these endpoints with "PUT" including body "doesnotmatter" about user "nonexistent" + | endpoint | + | /ocs/v1.php/cloud/users/%username% | + | /ocs/v2.php/cloud/users/%username% | + 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 "101" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsPUTAuthOc10Issue38423.feature b/tests/acceptance/features/coreApiAuthOcs/ocsPUTAuthOc10Issue38423.feature new file mode 100644 index 00000000000..bdbe04add87 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthOcs/ocsPUTAuthOc10Issue38423.feature @@ -0,0 +1,13 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +#When this issue is fixed, please delete this file and use the one from ocsPUTAuth.feature +Feature: current oC10 behavior for issue-38423 + + Scenario: Request to edit nonexistent user by authorized admin gets unauthorized in http response + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When user "another-admin" requests these endpoints with "PUT" including body "doesnotmatter" about user "nonexistent" + | endpoint | + | /ocs/v1.php/cloud/users/%username% | + | /ocs/v2.php/cloud/users/%username% | + 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" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature new file mode 100644 index 00000000000..bb1317fbaf1 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature @@ -0,0 +1,184 @@ +@api +Feature: COPY file/folder + + As a user + I want to copy a file or folder + So that I can duplicate it + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send COPY requests to webDav endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "COPY" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send COPY requests to webDav endpoints as normal user with wrong password using the spaces WebDAV API + When user "Alice" requests these endpoints with "COPY" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send COPY requests to webDav endpoints as normal user with no password + When user "Alice" requests these endpoints with "COPY" using password "" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send COPY requests to webDav endpoints as normal user with no password using the spaces WebDAV API + When user "Alice" requests these endpoints with "COPY" using password "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-14 + Scenario: send COPY requests to another user's webDav endpoints as normal user + When user "Brian" requests these endpoints with "COPY" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "403" + + @skipOnOcV10 @personalSpace @issue-ocis-reva-14 + Scenario: send COPY requests to another user's webDav endpoints as normal user using the spaces WebDAV API + When user "Brian" requests these endpoints with "COPY" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "403" + + + Scenario: send COPY requests to webDav endpoints using invalid username but correct password + When user "usero" requests these endpoints with "COPY" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send COPY requests to webDav endpoints using invalid username but correct password using the spaces WebDAV API + When user "usero" requests these endpoints with "COPY" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + + Scenario: send COPY requests to webDav endpoints using valid password and username of different user + When user "Brian" requests these endpoints with "COPY" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send COPY requests to webDav endpoints using valid password and username of different user using the spaces WebDAV API + When user "Brian" requests these endpoints with "COPY" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send COPY requests to webDav endpoints without any authentication + When a user requests these endpoints with "COPY" with no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send COPY requests to webDav endpoints without any authentication using the spaces WebDAV API + When a user requests these endpoints with "COPY" with no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send COPY requests to webDav endpoints using token authentication should not work + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "COPY" using the generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send COPY requests to webDav endpoints using app password token as password + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "COPY" with body "doesnotmatter" using basic auth and generated app password about user "Alice" + | endpoint | + # The token was valid and accepted but the body is invalid so it gives 403 + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "403" + + @skipOnOcV10 + Scenario: send COPY requests to webDav endpoints with body as normal user + When user "Alice" requests these endpoints with "COPY" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/webdav/PARENT/parent.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "415" + + @skipOnOcV10 @personalSpace + Scenario: send COPY requests to webDav endpoints with body as normal user using the spaces WebDAV API + When user "Alice" requests these endpoints with "COPY" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "415" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuthOC10Issue40144.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuthOC10Issue40144.feature new file mode 100644 index 00000000000..d22c87f0e2d --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuthOC10Issue40144.feature @@ -0,0 +1,28 @@ +@api @skipOnOcis +Feature: COPY file/folder + + As a user + I want to copy a file or folder + So that I can duplicate it + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + + Scenario: send COPY requests to webDav endpoints with body as normal user + When user "Alice" requests these endpoints with "COPY" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/webdav/PARENT/parent.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "403" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavCaseInsensitiveAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavCaseInsensitiveAuth.feature new file mode 100644 index 00000000000..300645bfd87 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavCaseInsensitiveAuth.feature @@ -0,0 +1,35 @@ +@api @notToImplementOnOCIS +Feature: usernames are case-insensitive in webDAV requests with app passwords + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @skipOnOcV10.10.0 + Scenario: send PUT requests to webDav endpoints using app password token as password and lowercase of username + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "204" + When the user "alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice" + | endpoint | + # this folder is created, so gives 201 - CREATED + | /remote.php/webdav/PARENS | + | /remote.php/dav/files/%username%/FOLDERS | + Then the HTTP status code of responses on all endpoints should be "201" + When the user "alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice" + | endpoint | + # this folder already exists so gives 409 - CONFLICT + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "409" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuth.feature new file mode 100644 index 00000000000..c905a7180b8 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuth.feature @@ -0,0 +1,204 @@ +@api +Feature: delete file/folder + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send DELETE requests to webDav endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "DELETE" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/webdav/PARENT/parent.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to webDav endpoints as normal user with wrong password using the spaces WebDAV API + When user "Alice" requests these endpoints with "DELETE" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + Scenario: send DELETE requests to webDav endpoints as normal user with no password + When user "Alice" requests these endpoints with "DELETE" using password "" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/webdav/PARENT/parent.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to webDav endpoints as normal user with no password using the spaces WebDAV API + When user "Alice" requests these endpoints with "DELETE" using password "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-13 + Scenario: send DELETE requests to another user's webDav endpoints as normal user + When user "Brian" requests these endpoints with "DELETE" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + @issue-ocis-reva-13 @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to another user's webDav endpoints as normal user using the spaces WebDAV API + When user "Brian" requests these endpoints with "DELETE" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + @smokeTest + Scenario: send DELETE requests to webDav endpoints using invalid username but correct password + When user "usero" requests these endpoints with "DELETE" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to webDav endpoints using invalid username but correct password using the spaces WebDAV API + When user "usero" requests these endpoints with "DELETE" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + + Scenario: send DELETE requests to webDav endpoints using valid password and username of different user + When user "Brian" requests these endpoints with "DELETE" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to webDav endpoints using valid password and username of different user using the spaces WebDAV API + When user "Brian" requests these endpoints with "DELETE" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send DELETE requests to webDav endpoints without any authentication + When a user requests these endpoints with "DELETE" with no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to webDav endpoints without any authentication using the spaces WebDAV API + When a user requests these endpoints with "DELETE" with no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-60 + Scenario: send DELETE requests to webDav endpoints using token authentication should not work + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "DELETE" using the generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-60 @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to webDav endpoints using token authentication should not work using the spaces WebDAV API + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "DELETE" using the generated app password about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-60 + Scenario: send DELETE requests to webDav endpoints using app password token as password + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "DELETE" using basic auth and generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "204" + + @issue-ocis-reva-60 @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to webDav endpoints using app password token as password using the spaces WebDAV API + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "DELETE" using basic auth and generated app password about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "204" + + @skipOnOcV10 + Scenario: send DELETE requests to webDav endpoints with body as normal user + When user "Alice" requests these endpoints with "DELETE" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "415" + + @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to webDav endpoints with body as normal user using the spaces WebDAV API + When user "Alice" requests these endpoints with "DELETE" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + Then the HTTP status code of responses on all endpoints should be "415" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuthOC10Issue40144.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuthOC10Issue40144.feature new file mode 100644 index 00000000000..7f25de041d7 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavDELETEAuthOC10Issue40144.feature @@ -0,0 +1,24 @@ +@api @notToImplementOnOCIS +Feature: delete file/folder + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + + Scenario: send DELETE requests to webDav endpoints with body as normal user + When user "Alice" requests these endpoints with "DELETE" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "204" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavLOCKAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavLOCKAuth.feature new file mode 100644 index 00000000000..623a6b36783 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavLOCKAuth.feature @@ -0,0 +1,165 @@ +@api +Feature: LOCK file/folder + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send LOCK requests to webDav endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "LOCK" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send LOCK requests to webDav endpoints as normal user with wrong password using the spaces WebDAV API + When user "Alice" requests these endpoints with "LOCK" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send LOCK requests to webDav endpoints as normal user with no password + When user "Alice" requests these endpoints with "LOCK" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send LOCK requests to webDav endpoints as normal user with no password using the spaces WebDAV API + When user "Alice" requests these endpoints with "LOCK" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-9 + Scenario: send LOCK requests to another user's webDav endpoints as normal user + When user "Brian" requests these endpoints with "LOCK" to get property "d:shared" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/dav/files/%username%/PARENT | + Then the HTTP status code of responses on all endpoints should be "403" + When user "Brian" requests these endpoints with "LOCK" to get property "d:shared" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "409" + + @issue-ocis-reva-9 @skipOnOcV10 @personalSpace + Scenario: send LOCK requests to another user's webDav endpoints as normal user using the spaces WebDAV API + When user "Brian" requests these endpoints with "LOCK" to get property "d:shared" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + Then the HTTP status code of responses on all endpoints should be "403" + When user "Brian" requests these endpoints with "LOCK" to get property "d:shared" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "409" + + + Scenario: send LOCK requests to webDav endpoints using invalid username but correct password + When user "usero" requests these endpoints with "LOCK" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send LOCK requests to webDav endpoints using invalid username but correct password using the spaces WebDAV API + When user "usero" requests these endpoints with "LOCK" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + + Scenario: send LOCK requests to webDav endpoints using valid password and username of different user + When user "Brian" requests these endpoints with "LOCK" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send LOCK requests to webDav endpoints using valid password and username of different user using the spaces WebDAV API + When user "Brian" requests these endpoints with "LOCK" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send LOCK requests to webDav endpoints without any authentication + When a user requests these endpoints with "LOCK" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send LOCK requests to webDav endpoints without any authentication using the spaces WebDAV API + When a user requests these endpoints with "LOCK" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send LOCK requests to webDav endpoints using token authentication should not work + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "LOCK" using the generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send LOCK requests to webDav endpoints using app password token as password + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "LOCK" to get property "d:shared" using basic auth and generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "200" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavMCKOLAuthOC10Issue40485.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavMCKOLAuthOC10Issue40485.feature new file mode 100644 index 00000000000..1c10e382d26 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavMCKOLAuthOC10Issue40485.feature @@ -0,0 +1,30 @@ +@api @skipOnOcis +Feature: create folder using MKCOL + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + Scenario: send MKCOL requests to another user's webDav endpoints as normal user + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "MKCOL" including body "" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/does-not-exist | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on each endpoint should be "403, 403, 403, 409" respectively + + + Scenario: send MKCOL requests to non-existent user's webDav endpoints as normal user + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "MKCOL" including body "" about user "non-existent-user" + | endpoint | + | /remote.php/dav/files/non-existent-user/textfile0.txt | + | /remote.php/dav/files/non-existent-user/PARENT | + | /remote.php/dav/files/non-existent-user/does-not-exist | + | /remote.php/dav/files/non-existent-user/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "409" \ No newline at end of file diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavMKCOLAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavMKCOLAuth.feature new file mode 100644 index 00000000000..9f49fd4d650 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavMKCOLAuth.feature @@ -0,0 +1,183 @@ +@api +Feature: create folder using MKCOL + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send MKCOL requests to webDav endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "MKCOL" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send MKCOL requests to webDav endpoints as normal user with wrong password using the spaces WebDAV API + When user "Alice" requests these endpoints with "MKCOL" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send MKCOL requests to webDav endpoints as normal user with no password + When user "Alice" requests these endpoints with "MKCOL" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnOcV10 @personalSpace @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send MKCOL requests to webDav endpoints as normal user with no password using the spaces WebDAV API + When user "Alice" requests these endpoints with "MKCOL" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @issue-ocis-5049 @issue-ocis-reva-9 @issue-ocis-reva-197 + Scenario: send MKCOL requests to another user's webDav endpoints as normal user + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "MKCOL" including body "" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/does-not-exist | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + @skipOnOcV10 @issue-ocis-5049 @issue-ocis-reva-9 @issue-ocis-reva-197 + Scenario: send MKCOL requests to non-existent user's webDav endpoints as normal user + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "MKCOL" including body "" about user "non-existent-user" + | endpoint | + | /remote.php/dav/files/non-existent-user/textfile0.txt | + | /remote.php/dav/files/non-existent-user/PARENT | + | /remote.php/dav/files/non-existent-user/does-not-exist | + | /remote.php/dav/files/non-existent-user/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + @skipOnOcV10 @personalSpace @issue-ocis-reva-9 @issue-ocis-reva-197 + Scenario: send MKCOL requests to another user's webDav endpoints as normal user using the spaces WebDAV API + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "MKCOL" including body "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/does-not-exist | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + @skipOnOcV10 @issue-ocis-5049 @personalSpace @issue-ocis-reva-9 @issue-ocis-reva-197 + Scenario: send MKCOL requests to non-existent user's webDav endpoints as normal user using the spaces WebDAV API + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "MKCOL" including body "" about user "non-existent-user" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/does-not-exist | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + + Scenario: send MKCOL requests to webDav endpoints using invalid username but correct password + When user "usero" requests these endpoints with "MKCOL" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send MKCOL requests to webDav endpoints using invalid username but correct password using the spaces WebDAV API + When user "usero" requests these endpoints with "MKCOL" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + + Scenario: send MKCOL requests to webDav endpoints using valid password and username of different user + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "MKCOL" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send MKCOL requests to webDav endpoints using valid password and username of different user using the spaces WebDAV API + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "MKCOL" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send MKCOL requests to webDav endpoints without any authentication + When a user requests these endpoints with "MKCOL" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send MKCOL requests to webDav endpoints without any authentication using the spaces WebDAV API + When a user requests these endpoints with "MKCOL" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send MKCOL requests to webDav endpoints using token authentication should not work + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "MKCOL" using the generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send MKCOL requests to webDav endpoints using app password token as password + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "MKCOL" using basic auth and generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/newCol | + | /remote.php/dav/files/%username%/newCol1 | + | /remote.php/dav/files/%username%/PARENT/newCol | + | /remote.php/webdav/COL | + | /remote.php/dav/files/%username%/FOLDER/newCol | + Then the HTTP status code of responses on all endpoints should be "201" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuth.feature new file mode 100644 index 00000000000..b2e2723b5b7 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuth.feature @@ -0,0 +1,180 @@ +@api +Feature: MOVE file/folder + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send MOVE requests to webDav endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "MOVE" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send MOVE requests to webDav endpoints as normal user with wrong password using the spaces WebDAV API + When user "Alice" requests these endpoints with "MOVE" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send MOVE requests to webDav endpoints as normal user with no password + When user "Alice" requests these endpoints with "MOVE" using password "" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send MOVE requests to webDav endpoints as normal user with no password using the spaces WebDAV API + When user "Alice" requests these endpoints with "MOVE" using password "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-14 + Scenario: send MOVE requests to another user's webDav endpoints as normal user + When user "Brian" requests these endpoints with "MOVE" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "403" + + @skipOnOcV10 @personalSpace @issue-ocis-reva-14 + Scenario: send MOVE requests to another user's webDav endpoints as normal user using the spaces WebDAV API + When user "Brian" requests these endpoints with "MOVE" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "403" + + + Scenario: send MOVE requests to webDav endpoints using invalid username but correct password + When user "usero" requests these endpoints with "MOVE" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send MOVE requests to webDav endpoints using invalid username but correct password using the spaces WebDAV API + When user "usero" requests these endpoints with "MOVE" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + + Scenario: send MOVE requests to webDav endpoints using valid password and username of different user + When user "Brian" requests these endpoints with "MOVE" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send MOVE requests to webDav endpoints using valid password and username of different user using the spaces WebDAV API + When user "Brian" requests these endpoints with "MOVE" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send MOVE requests to webDav endpoints without any authentication + When a user requests these endpoints with "MOVE" with no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send MOVE requests to webDav endpoints without any authentication using the spaces WebDAV API + When a user requests these endpoints with "MOVE" with no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send MOVE requests to webDav endpoints using token authentication should not work + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "MOVE" using the generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send MOVE requests to webDav endpoints using app password token as password + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "MOVE" with body "doesnotmatter" using basic auth and generated app password about user "Alice" + | endpoint | + # The token was valid and accepted but the body is invalid so it gives 403 + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "403" + + @skipOnOcV10 + Scenario: send MOVE requests to webDav endpoints with body as normal user + When user "Alice" requests these endpoints with "MOVE" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/webdav/PARENT/parent.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "415" + + @skipOnOcV10 @personalSpace + Scenario: send MOVE requests to webDav endpoints with body as normal user using the spaces WebDAV API + When user "Alice" requests these endpoints with "MOVE" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "415" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuthOC10Issue40144.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuthOC10Issue40144.feature new file mode 100644 index 00000000000..76f8816e6b4 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuthOC10Issue40144.feature @@ -0,0 +1,24 @@ +@api @notToImplementOnOCIS +Feature: MOVE file/folder + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + + Scenario: send MOVE requests to webDav endpoints with body as normal user + When user "Alice" requests these endpoints with "MOVE" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/webdav/PARENT/parent.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "403" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPOSTAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPOSTAuth.feature new file mode 100644 index 00000000000..1e90596219f --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavPOSTAuth.feature @@ -0,0 +1,160 @@ +@api +Feature: get file info using POST + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send POST requests to webDav endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send POST requests to webDav endpoints as normal user with wrong password using the spaces WebDAV API + When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send POST requests to webDav endpoints as normal user with no password + When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send POST requests to webDav endpoints as normal user with no password using the spaces WebDAV API + When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-179 + Scenario: send POST requests to another user's webDav endpoints as normal user + When user "Brian" requests these endpoints with "POST" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + @skipOnOcV10 @personalSpace @issue-ocis-reva-179 + Scenario: send POST requests to another user's webDav endpoints as normal user using the spaces WebDAV API + When user "Brian" requests these endpoints with "POST" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + + Scenario: send POST requests to webDav endpoints using invalid username but correct password + When user "usero" requests these endpoints with "POST" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send POST requests to webDav endpoints using invalid username but correct password using the spaces WebDAV API + When user "usero" requests these endpoints with "POST" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + + Scenario: send POST requests to webDav endpoints using valid password and username of different user + When user "Brian" requests these endpoints with "POST" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send POST requests to webDav endpoints using valid password and username of different user using the spaces WebDAV API + When user "Brian" requests these endpoints with "POST" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send POST requests to webDav endpoints without any authentication + When a user requests these endpoints with "POST" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send POST requests to webDav endpoints without any authentication using the spaces WebDAV API + When a user requests these endpoints with "POST" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send POST requests to webDav endpoints using token authentication should not work + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "POST" using the generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send POST requests to webDav endpoints using app password token as password + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "POST" with body "doesnotmatter" using basic auth and generated app password about user "Alice" + | endpoint | + # this method is not available so gives 501 + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "501" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPROPFINDAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPROPFINDAuth.feature new file mode 100644 index 00000000000..d1bfee252d5 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavPROPFINDAuth.feature @@ -0,0 +1,158 @@ +@api +Feature: get file info using PROPFIND + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PROPFIND requests to webDav endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "PROPFIND" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send PROPFIND requests to webDav endpoints as normal user with wrong password using the spaces WebDAV API + When user "Alice" requests these endpoints with "PROPFIND" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PROPFIND requests to webDav endpoints as normal user with no password + When user "Alice" requests these endpoints with "PROPFIND" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send PROPFIND requests to webDav endpoints as normal user with no password using the spaces WebDAV API + When user "Alice" requests these endpoints with "PROPFIND" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-9 + Scenario: send PROPFIND requests to another user's webDav endpoints as normal user + When user "Brian" requests these endpoints with "PROPFIND" to get property "d:getetag" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + @skipOnOcV10 @personalSpace @issue-ocis-reva-9 + Scenario: send PROPFIND requests to another user's webDav endpoints as normal user using the spaces WebDAV API + When user "Brian" requests these endpoints with "PROPFIND" to get property "d:getetag" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + + Scenario: send PROPFIND requests to webDav endpoints using invalid username but correct password + When user "usero" requests these endpoints with "PROPFIND" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send PROPFIND requests to webDav endpoints using invalid username but correct password using the spaces WebDAV API + When user "usero" requests these endpoints with "PROPFIND" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + + Scenario: send PROPFIND requests to webDav endpoints using valid password and username of different user + When user "Brian" requests these endpoints with "PROPFIND" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send PROPFIND requests to webDav endpoints using valid password and username of different user using the spaces WebDAV API + When user "Brian" requests these endpoints with "PROPFIND" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PROPFIND requests to webDav endpoints without any authentication + When a user requests these endpoints with "PROPFIND" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send PROPFIND requests to webDav endpoints without any authentication using the spaces WebDAV API + When a user requests these endpoints with "PROPFIND" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send PROPFIND requests to webDav endpoints using token authentication should not work + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "PROPFIND" using the generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send PROPFIND requests to webDav endpoints using app password token as password + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + | /remote.php/webdav/PARENT | + | /remote.php/webdav/textfile0.txt | + Then the HTTP status code of responses on all endpoints should be "207" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPROPPATCHAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPROPPATCHAuth.feature new file mode 100644 index 00000000000..3c1b893b9cc --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavPROPPATCHAuth.feature @@ -0,0 +1,159 @@ +@api +Feature: PROPPATCH file/folder + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PROPPATCH requests to webDav endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send PROPPATCH requests to webDav endpoints as normal user with wrong password using the spaces WebDAV API + When user "Alice" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PROPPATCH requests to webDav endpoints as normal user with no password + When user "Alice" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send PROPPATCH requests to webDav endpoints as normal user with no password using the spaces WebDAV API + When user "Alice" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @issue-ocis-reva-9 @issue-ocis-reva-197 + Scenario: send PROPPATCH requests to another user's webDav endpoints as normal user + When user "Brian" requests these endpoints with "PROPPATCH" to set property "favorite" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + @issue-ocis-reva-9 @issue-ocis-reva-197 @skipOnOcV10 @personalSpace + Scenario: send PROPPATCH requests to another user's webDav endpoints as normal user using the spaces WebDAV API + When user "Brian" requests these endpoints with "PROPPATCH" to set property "favorite" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + + Scenario: send PROPPATCH requests to webDav endpoints using invalid username but correct password + When user "usero" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send PROPPATCH requests to webDav endpoints using invalid username but correct password using the spaces WebDAV API + When user "usero" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + + Scenario: send PROPPATCH requests to webDav endpoints using valid password and username of different user + When user "Brian" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send PROPPATCH requests to webDav endpoints using valid password and username of different user using the spaces WebDAV API + When user "Brian" requests these endpoints with "PROPPATCH" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PROPPATCH requests to webDav endpoints without any authentication + When a user requests these endpoints with "PROPPATCH" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send PROPPATCH requests to webDav endpoints without any authentication using the spaces WebDAV API + When a user requests these endpoints with "PROPPATCH" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send PROPPATCH requests to webDav endpoints using token authentication should not work + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "PROPPATCH" using the generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send PROPPATCH requests to webDav endpoints using app password token as password + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "PROPPATCH" to set property "favorite" using basic auth and generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "207" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuth.feature new file mode 100644 index 00000000000..b12dba719e0 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuth.feature @@ -0,0 +1,174 @@ +@api +Feature: get file info using PUT + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PUT requests to webDav endpoints as normal user with wrong password + When user "Alice" requests these endpoints with "PUT" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send PUT requests to webDav endpoints as normal user with wrong password using the spaces WebDAV API + When user "Alice" requests these endpoints with "PUT" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PUT requests to webDav endpoints as normal user with no password + When user "Alice" requests these endpoints with "PUT" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send PUT requests to webDav endpoints as normal user with no password using the spaces WebDAV API + When user "Alice" requests these endpoints with "PUT" including body "doesnotmatter" using password "" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 + Scenario: send PUT requests to another user's webDav endpoints as normal user + When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT | + Then the HTTP status code of responses on all endpoints should be "403" + When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "403" + + @skipOnOcV10 @personalSpace + Scenario: send PUT requests to another user's webDav endpoints as normal user using the spaces WebDAV API + When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + Then the HTTP status code of responses on all endpoints should be "403" + When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "403" + + + Scenario: send PUT requests to webDav endpoints using invalid username but correct password + When user "usero" requests these endpoints with "PUT" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send PUT requests to webDav endpoints using invalid username but correct password using the spaces WebDAV API + When user "usero" requests these endpoints with "PUT" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + + Scenario: send PUT requests to webDav endpoints using valid password and username of different user + When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @skipOnOcV10 @personalSpace + Scenario: send PUT requests to webDav endpoints using valid password and username of different user using the spaces WebDAV API + When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 + Scenario: send PUT requests to webDav endpoints without any authentication + When a user requests these endpoints with "PUT" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @smokeTest @skipOnBruteForceProtection @issue-brute_force_protection-112 @skipOnOcV10 @personalSpace + Scenario: send PUT requests to webDav endpoints without any authentication using the spaces WebDAV API + When a user requests these endpoints with "PUT" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php/dav/spaces/%spaceid%/PARENT | + | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send PUT requests to webDav endpoints using token authentication should not work + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user requests these endpoints with "PUT" using the generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile0.txt | + | /remote.php/webdav/PARENT | + | /remote.php/dav/files/%username%/PARENT | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "401" + + @notToImplementOnOCIS @issue-ocis-reva-37 + Scenario: send PUT requests to webDav endpoints using app password token as password + Given token auth has been enforced + And a new browser session for "Alice" has been started + And the user has generated a new app password named "my-client" + When the user "Alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice" + | endpoint | + | /remote.php/webdav/textfile0.txt | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "204" + When the user "Alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice" + | endpoint | + # this folder is created, so gives 201 - CREATED + | /remote.php/webdav/PARENS | + | /remote.php/dav/files/%username%/FOLDERS | + Then the HTTP status code of responses on all endpoints should be "201" + When the user "Alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice" + | endpoint | + # this folder already exists so gives 409 - CONFLICT + | /remote.php/dav/files/%username%/FOLDER | + Then the HTTP status code of responses on all endpoints should be "409" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuthOC10Issue39597.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuthOC10Issue39597.feature new file mode 100644 index 00000000000..da98171ce59 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuthOC10Issue39597.feature @@ -0,0 +1,23 @@ +@api @issue-39597 @skipOnOcis +Feature: get file info using PUT + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + + Scenario: send PUT requests to another user's webDav endpoints as normal user + When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/PARENT | + Then the HTTP status code of responses on all endpoints should be "403" + When user "Brian" requests these endpoints with "PUT" including body "doesnotmatter" about user "Alice" + | endpoint | + | /remote.php/dav/files/%username%/PARENT/parent.txt | + Then the HTTP status code of responses on all endpoints should be "409" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavSpecialURLs.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavSpecialURLs.feature new file mode 100644 index 00000000000..466caeaf0a6 --- /dev/null +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavSpecialURLs.feature @@ -0,0 +1,203 @@ +@api @skipOnOcV10.10.0 +Feature: make webdav request with special urls + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + + Scenario: send DELETE requests to webDav endpoints with 2 slashes + When user "Alice" requests these endpoints with "DELETE" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php/webdav/textfile0.txt | + | //remote.php//dav/files/%username%/textfile1.txt | + | /remote.php//dav/files/%username%/PARENT/parent.txt | + | /remote.php//webdav/PARENT | + | //remote.php/dav//files/%username%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "204" + + @skipOnOcV10 @personalSpace + Scenario: send DELETE requests to webDav endpoints with 2 slashes using the spaces WebDAV API + When user "Alice" requests these endpoints with "DELETE" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php/dav/spaces/%spaceid%/textfile0.txt | + | //remote.php//dav/spaces/%spaceid%/PARENT/parent.txt | + | /remote.php//dav/spaces/%spaceid%/PARENT | + | //remote.php/dav//spaces/%spaceid%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "204" + + + Scenario: send GET requests to webDav endpoints with 2 slashes + When user "Alice" requests these endpoints with "GET" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php/webdav/textfile0.txt | + | //remote.php//dav/files/%username%/textfile1.txt | + | /remote.php//dav/files/%username%/PARENT/parent.txt | + | /remote.php//webdav/PARENT | + | //remote.php/dav//files/%username%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "200" + + @skipOnOcV10 @personalSpace + Scenario: send GET requests to webDav endpoints with 2 slashes using the spaces WebDAV API + When user "Alice" requests these endpoints with "GET" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php/dav/spaces/%spaceid%/textfile0.txt | + | //remote.php//dav/spaces/%spaceid%/PARENT/parent.txt | + | /remote.php//dav/spaces/%spaceid%/PARENT | + | //remote.php/dav//spaces/%spaceid%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "200" + + + Scenario: send LOCK requests to webDav endpoints with 2 slashes + When the user "Alice" requests these endpoints with "LOCK" to get property "d:shared" with password "%regular%" about user "Alice" + | endpoint | + | //remote.php/webdav/textfile0.txt | + | //remote.php//dav/files/%username%/textfile1.txt | + | /remote.php//dav/files/%username%/PARENT/parent.txt | + | /remote.php//webdav/PARENT | + | //remote.php/dav//files/%username%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "200" + + @skipOnOcV10 @personalSpace + Scenario: send LOCK requests to webDav endpoints with 2 slashes using the spaces WebDAV API + When the user "Alice" requests these endpoints with "LOCK" to get property "d:shared" with password "%regular%" about user "Alice" + | endpoint | + | //remote.php/dav/spaces/%spaceid%/textfile0.txt | + | //remote.php//dav/spaces/%spaceid%/PARENT/parent.txt | + | /remote.php//dav/spaces/%spaceid%/PARENT | + | //remote.php/dav//spaces/%spaceid%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "200" + + + Scenario: send MKCOL requests to webDav endpoints with 2 slashes + When user "Alice" requests these endpoints with "MKCOL" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php/webdav/PARENT1 | + | /remote.php//webdav/PARENT2 | + | //remote.php//webdav/PARENT3 | + | //remote.php/dav//files/%username%/PARENT4 | + | /remote.php/dav/files/%username%//PARENT5 | + | /remote.php/dav//files/%username%/PARENT6 | + Then the HTTP status code of responses on all endpoints should be "201" + + @skipOnOcV10 @personalSpace + Scenario: send MKCOL requests to webDav endpoints with 2 slashes using the spaces WebDAV API + When user "Alice" requests these endpoints with "MKCOL" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php/dav/spaces/%spaceid%/PARENT1 | + | /remote.php//dav/spaces/%spaceid%/PARENT2 | + | //remote.php//dav/spaces/%spaceid%/PARENT3 | + | //remote.php/dav//spaces/%spaceid%/PARENT4 | + | /remote.php/dav/spaces/%spaceid%//PARENT5 | + | /remote.php/dav//spaces/%spaceid%/PARENT6 | + Then the HTTP status code of responses on all endpoints should be "201" + + + Scenario: send MOVE requests to webDav endpoints with 2 slashes + When user "Alice" requests these endpoints with "MOVE" using password "%regular%" about user "Alice" + | endpoint | destination | + | //remote.php/webdav/textfile0.txt | /remote.php/webdav/textfileZero.txt | + | /remote.php//dav/files/%username%/textfile1.txt | /remote.php/dav/files/%username%/textfileOne.txt | + | /remote.php/webdav//PARENT | /remote.php/webdav/PARENT1 | + | //remote.php/dav/files/%username%//PARENT1 | /remote.php/dav/files/%username%/PARENT2 | + | /remote.php/dav//files/%username%/PARENT2/parent.txt | /remote.php/dav/files/%username%/PARENT2/parent1.txt | + Then the HTTP status code of responses on all endpoints should be "201" + + @skipOnOcV10 @personalSpace + Scenario: send MOVE requests to webDav endpoints with 2 slashes using the spaces WebDAV API + When user "Alice" requests these endpoints with "MOVE" using password "%regular%" about user "Alice" + | endpoint | destination | + | /remote.php//dav/spaces/%spaceid%/textfile1.txt | /remote.php/dav/spaces/%spaceid%/textfileOne.txt | + | /remote.php/dav//spaces/%spaceid%/PARENT | /remote.php/dav/spaces/%spaceid%/PARENT1 | + | //remote.php/dav/spaces/%spaceid%//PARENT1 | /remote.php/dav/spaces/%spaceid%/PARENT2 | + | //remote.php/dav/spaces/%spaceid%/PARENT2/parent.txt | /remote.php/dav/spaces/%spaceid%/PARENT2/parent1.txt | + Then the HTTP status code of responses on all endpoints should be "201" + + + Scenario: send POST requests to webDav endpoints with 2 slashes + When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php/webdav/textfile0.txt | + | //remote.php//dav/files/%username%/textfile1.txt | + | /remote.php//dav/files/%username%/PARENT/parent.txt | + | /remote.php//webdav/PARENT | + | //remote.php/dav//files/%username%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "500" or "501" + + @skipOnOcV10 @personalSpace + Scenario: send POST requests to webDav endpoints with 2 slashes using the spaces WebDAV API + When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php//dav/spaces/%spaceid%/textfile1.txt | + | /remote.php//dav/spaces/%spaceid%/PARENT/parent.txt | + | /remote.php//dav/spaces/%spaceid%/PARENT | + | //remote.php/dav//spaces/%spaceid%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "500" or "501" + + + Scenario: send PROPFIND requests to webDav endpoints with 2 slashes + When the user "Alice" requests these endpoints with "PROPFIND" to get property "d:href" with password "%regular%" about user "Alice" + | endpoint | + | //remote.php/webdav/textfile0.txt | + | //remote.php//dav/files/%username%/textfile1.txt | + | /remote.php//dav/files/%username%/PARENT/parent.txt | + | /remote.php//webdav/PARENT | + | //remote.php/dav//files/%username%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "207" + + @skipOnOcV10 @personalSpace + Scenario: send PROPFIND requests to webDav endpoints with 2 slashes using the spaces WebDAV API + When the user "Alice" requests these endpoints with "PROPFIND" to get property "d:href" with password "%regular%" about user "Alice" + | endpoint | + | //remote.php//dav/spaces/%spaceid%/textfile1.txt | + | /remote.php//dav/spaces/%spaceid%/PARENT/parent.txt | + | /remote.php//dav/spaces/%spaceid%/PARENT | + | //remote.php/dav//spaces/%spaceid%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "207" + + + Scenario: send PROPPATCH requests to webDav endpoints with 2 slashes + When the user "Alice" requests these endpoints with "PROPPATCH" to set property "d:getlastmodified" with password "%regular%" about user "Alice" + | endpoint | + | //remote.php/webdav/textfile0.txt | + | //remote.php//dav/files/%username%/textfile1.txt | + | /remote.php//dav/files/%username%/PARENT/parent.txt | + | /remote.php//webdav/PARENT | + | //remote.php/dav//files/%username%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "207" + + @skipOnOcV10 @personalSpace + Scenario: send PROPPATCH requests to webDav endpoints with 2 slashes using the spaces WebDAV API + When the user "Alice" requests these endpoints with "PROPPATCH" to set property "d:getlastmodified" with password "%regular%" about user "Alice" + | endpoint | + | //remote.php//dav/spaces/%spaceid%/textfile1.txt | + | /remote.php//dav/spaces/%spaceid%/PARENT/parent.txt | + | /remote.php//dav/spaces/%spaceid%/PARENT | + | //remote.php/dav//spaces/%spaceid%//FOLDER | + Then the HTTP status code of responses on all endpoints should be "207" + + + Scenario: send PUT requests to webDav endpoints with 2 slashes + When user "Alice" requests these endpoints with "PUT" including body "doesnotmatter" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php/webdav/textfile0.txt | + | /remote.php//webdav/textfile1.txt | + | //remote.php//dav/files/%username%/textfile1.txt | + | /remote.php/dav/files/%username%/textfile7.txt | + | //remote.php/dav/files/%username%/PARENT//parent.txt | + Then the HTTP status code of responses on all endpoints should be "204" or "201" + + @skipOnOcV10 @personalSpace + Scenario: send PUT requests to webDav endpoints with 2 slashes using the spaces WebDAV API + When user "Alice" requests these endpoints with "PUT" including body "doesnotmatter" using password "%regular%" about user "Alice" + | endpoint | + | //remote.php/dav/spaces/%spaceid%/textfile0.txt | + | /remote.php//dav/spaces/%spaceid%/textfile1.txt | + | //remote.php//dav/spaces/%spaceid%/textfile1.txt | + | /remote.php/dav/spaces/%spaceid%/textfile7.txt | + | //remote.php/dav/spaces/%spaceid%/PARENT//parent.txt | + Then the HTTP status code of responses on all endpoints should be "204" or "201" diff --git a/tests/acceptance/features/coreApiCapabilities/capabilities.feature b/tests/acceptance/features/coreApiCapabilities/capabilities.feature new file mode 100644 index 00000000000..c34004a8228 --- /dev/null +++ b/tests/acceptance/features/coreApiCapabilities/capabilities.feature @@ -0,0 +1,961 @@ +@api @files_sharing-app-required @issue-ocis-reva-41 +Feature: capabilities + + Background: + Given using OCS API version "1" + + @smokeTest @skipOnOcis + Scenario: Check that the sharing API can be enabled + Given parameter "shareapi_enabled" of app "core" has been set to "no" + And the capabilities setting of "files_sharing" path "api_enabled" has been confirmed to be "" + When the administrator sets parameter "shareapi_enabled" of app "core" to "yes" + Then the capabilities setting of "files_sharing" path "api_enabled" should be "1" + + @smokeTest @skipOnOcis + Scenario: Check that the sharing API can be disabled + Given parameter "shareapi_enabled" of app "core" has been set to "yes" + And the capabilities setting of "files_sharing" path "api_enabled" has been confirmed to be "1" + When the administrator sets parameter "shareapi_enabled" of app "core" to "no" + Then the capabilities setting of "files_sharing" path "api_enabled" should be "" + + @skipOnOcis + Scenario: Check that group sharing can be enabled + Given parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + And the capabilities setting of "files_sharing" path "group_sharing" has been confirmed to be "" + When the administrator sets parameter "shareapi_allow_group_sharing" of app "core" to "yes" + Then the capabilities setting of "files_sharing" path "group_sharing" should be "1" + + @skipOnOcis + Scenario: Check that group sharing can be disabled + Given parameter "shareapi_allow_group_sharing" of app "core" has been set to "yes" + And the capabilities setting of "files_sharing" path "group_sharing" has been confirmed to be "1" + When the administrator sets parameter "shareapi_allow_group_sharing" of app "core" to "no" + Then the capabilities setting of "files_sharing" path "group_sharing" should be "" + + @smokeTest @skipOnOcis + Scenario: getting default capabilities with admin user + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | core | status@@@edition | %edition% | + | core | status@@@productname | %productname% | + | core | status@@@version | %version% | + | core | status@@@versionstring | %versionstring% | + | files_sharing | api_enabled | 1 | + | files_sharing | default_permissions | 31 | + | files_sharing | search_min_length | 2 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@multiple | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@supports_upload_only | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | public@@@enforced | EMPTY | + | files_sharing | public@@@enforced_for@@@read_only | EMPTY | + | files_sharing | public@@@enforced_for@@@read_write | EMPTY | + | files_sharing | public@@@enforced_for@@@upload_only | EMPTY | + | files_sharing | public@@@enforced_for@@@read_write_delete | EMPTY | + | files_sharing | public@@@expire_date@@@enabled | EMPTY | + | files_sharing | public@@@defaultPublicLinkShareName | Public link | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | share_with_membership_groups_only | EMPTY | + | files_sharing | auto_accept_share | 1 | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files_sharing | user@@@send_mail | EMPTY | + | files | bigfilechunking | 1 | + | files | privateLinks | 1 | + | files | privateLinksDetailsParam | 1 | + + @smokeTest @skipOnOcis + Scenario: getting default capabilities with admin user with new values + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | user@@@expire_date@@@enabled | EMPTY | + | files_sharing | group@@@expire_date@@@enabled | EMPTY | + | files_sharing | providers_capabilities@@@ocinternal@@@user@@@element[0] | shareExpiration | + | files_sharing | providers_capabilities@@@ocinternal@@@group@@@element[0] | shareExpiration | + | files_sharing | providers_capabilities@@@ocinternal@@@link@@@element[0] | shareExpiration | + | files_sharing | providers_capabilities@@@ocinternal@@@link@@@element[1] | passwordProtected | + + @smokeTest @skipOnOcis + Scenario: the default capabilities should include share expiration for all of user, group, link and remote (federated) + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | user@@@expire_date@@@enabled | EMPTY | + | files_sharing | group@@@expire_date@@@enabled | EMPTY | + | files_sharing | remote@@@expire_date@@@enabled | EMPTY | + | files_sharing | providers_capabilities@@@ocinternal@@@user@@@element[0] | shareExpiration | + | files_sharing | providers_capabilities@@@ocinternal@@@group@@@element[0] | shareExpiration | + | files_sharing | providers_capabilities@@@ocinternal@@@link@@@element[0] | shareExpiration | + | files_sharing | providers_capabilities@@@ocFederatedSharing@@@remote@@@element[0] | shareExpiration | + + @smokeTest @skipOnOcis + Scenario: getting new default capabilities in versions after 10.5.0 with admin user + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files | favorites | 1 | + | files | file_locking_support | 1 | + | files | file_locking_enable_file_action | EMPTY | + + @smokeTest @skipOnOcis + Scenario: lock file action can be enabled + Given parameter "enable_lock_file_action" of app "files" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files | file_locking_support | 1 | + | files | file_locking_enable_file_action | 1 | + + @smokeTest @skipOnOcis + Scenario: getting default capabilities with admin user + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | user@@@profile_picture | 1 | + + @files_trashbin-app-required @skipOnReva + Scenario: getting trashbin app capability with admin user + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files | undelete | 1 | + + @files_versions-app-required @skipOnReva + Scenario: getting versions app capability with admin user + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files | versioning | 1 | + + @skipOnOcis + Scenario: getting default_permissions capability with admin user + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | default_permissions | 31 | + + @skipOnOcis + Scenario: default_permissions capability can be changed + Given parameter "shareapi_default_permissions" of app "core" has been set to "7" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | default_permissions | 7 | + + @skipOnOcis + Scenario: .htaccess is reported as a blacklisted file by default + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files | blacklisted_files@@@element[0] | .htaccess | + + @skipOnOcis + Scenario: multiple files can be reported as blacklisted + Given the administrator has updated system config key "blacklisted_files" with value '["test.txt",".htaccess"]' and type "json" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files | blacklisted_files@@@element[0] | test.txt | + | files | blacklisted_files@@@element[1] | .htaccess | + + @skipOnOcis + Scenario: user expire date can be enabled + Given parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | user@@@expire_date@@@enabled | 1 | + | files_sharing | user@@@expire_date@@@days | 7 | + | files_sharing | user@@@expire_date@@@enforced | EMPTY | + + @skipOnOcis + Scenario: user expire date can be enforced + Given parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | user@@@expire_date@@@enabled | 1 | + | files_sharing | user@@@expire_date@@@days | 7 | + | files_sharing | user@@@expire_date@@@enforced | 1 | + + @skipOnOcis + Scenario: user expire date days can be set + Given parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "14" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | user@@@expire_date@@@enabled | 1 | + | files_sharing | user@@@expire_date@@@days | 14 | + | files_sharing | user@@@expire_date@@@enforced | EMPTY | + + @skipOnOcis + Scenario: group expire date can be enabled + Given parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | group@@@expire_date@@@enabled | 1 | + | files_sharing | group@@@expire_date@@@days | 7 | + | files_sharing | group@@@expire_date@@@enforced | EMPTY | + + @skipOnOcis + Scenario: group expire date can be enforced + Given parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | group@@@expire_date@@@enabled | 1 | + | files_sharing | group@@@expire_date@@@days | 7 | + | files_sharing | group@@@expire_date@@@enforced | 1 | + + @skipOnOcis + Scenario: group expire date days can be set + Given parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "14" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | group@@@expire_date@@@enabled | 1 | + | files_sharing | group@@@expire_date@@@days | 14 | + | files_sharing | group@@@expire_date@@@enforced | EMPTY | + + #feature added in #31824 released in 10.0.10 + @smokeTest @skipOnOcis + Scenario: getting capabilities with admin user + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files_sharing | can_share | 1 | + + #feature added in #32414 released in 10.0.10 + @skipOnOcis + Scenario: getting async capabilities when async operations are enabled + Given the administrator has enabled async operations + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | async | | 1.0 | + + + Scenario: getting async capabilities when async operations are disabled + Given the administrator has disabled async operations + When the administrator retrieves the capabilities using the capabilities API + Then the capabilities should contain + | capability | path_to_element | value | + | async | | EMPTY | + + @skipOnOcis + Scenario: Changing public upload + Given parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@multiple | 1 | + | files_sharing | public@@@upload | EMPTY | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Disabling share api + Given parameter "shareapi_enabled" of app "core" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | EMPTY | + | files_sharing | can_share | EMPTY | + | files_sharing | public@@@enabled | EMPTY | + | files_sharing | public@@@multiple | EMPTY | + | files_sharing | public@@@upload | EMPTY | + | files_sharing | resharing | EMPTY | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Disabling public links + Given parameter "shareapi_allow_links" of app "core" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | EMPTY | + | files_sharing | public@@@multiple | EMPTY | + | files_sharing | public@@@upload | EMPTY | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing resharing + Given parameter "shareapi_allow_resharing" of app "core" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | EMPTY | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing federation outgoing + Given parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | EMPTY | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing federation incoming + Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | EMPTY | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing "password enforced for read-only public link shares" + Given parameter "shareapi_enforce_links_password_read_only" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | public@@@password@@@enforced_for@@@read_only | 1 | + | files_sharing | public@@@password@@@enforced_for@@@read_write | EMPTY | + | files_sharing | public@@@password@@@enforced_for@@@upload_only | EMPTY | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing "password enforced for read-write public link shares" + Given parameter "shareapi_enforce_links_password_read_write" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | public@@@password@@@enforced_for@@@read_only | EMPTY | + | files_sharing | public@@@password@@@enforced_for@@@read_write | 1 | + | files_sharing | public@@@password@@@enforced_for@@@upload_only | EMPTY | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing "password enforced for write-only public link shares" + Given parameter "shareapi_enforce_links_password_write_only" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | public@@@password@@@enforced_for@@@read_only | EMPTY | + | files_sharing | public@@@password@@@enforced_for@@@read_write | EMPTY | + | files_sharing | public@@@password@@@enforced_for@@@upload_only | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing public notifications + Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | 1 | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing public social share + Given parameter "shareapi_allow_social_share" of app "core" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | EMPTY | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing expire date + Given parameter "shareapi_default_expire_date" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | public@@@expire_date@@@enabled | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing expire date enforcing + Given parameter "shareapi_default_expire_date" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | public@@@expire_date@@@enabled | 1 | + | files_sharing | public@@@expire_date@@@enforced | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing group sharing allowed + Given parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | EMPTY | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing only share with group member + Given parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | 1 | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing only share with membership groups + Given parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | share_with_membership_groups_only | 1 | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing auto accept share + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | share_with_membership_groups_only | EMPTY | + | files_sharing | auto_accept_share | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing allow share dialog user enumeration + Given parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing allow share dialog user enumeration for group members only + Given parameter "shareapi_share_dialog_user_enumeration_group_members" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | 1 | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing allow mail notification + Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes" + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files_sharing | user@@@send_mail | 1 | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: Changing exclude groups from sharing + Given parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And group "group1" has been created + And group "hash#group" has been created + And group "group-3" has been created + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["group1","hash#group","group-3"]' + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: When in a group that is excluded from sharing, can_share is off + Given parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And user "Alice" has been created with default attributes and without skeleton files + And group "group1" has been created + And group "hash#group" has been created + And group "group-3" has been created + And group "ordinary-group" has been created + And user "Alice" has been added to group "hash#group" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["group1","hash#group","group-3"]' + When user "Alice" retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | EMPTY | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: When not in any group that is excluded from sharing, can_share is on + Given parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And user "Alice" has been created with default attributes and without skeleton files + And group "group1" has been created + And group "hash#group" has been created + And group "group-3" has been created + And group "ordinary-group" has been created + And user "Alice" has been added to group "ordinary-group" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["group1","hash#group","group-3"]' + When user "Alice" retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | 1 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: When in a group that is excluded from sharing and in another group, can_share is off + Given parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And user "Alice" has been created with default attributes and without skeleton files + And group "group1" has been created + And group "hash#group" has been created + And group "group-3" has been created + And group "ordinary-group" has been created + And user "Alice" has been added to group "hash#group" + And user "Alice" has been added to group "ordinary-group" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["group1","hash#group","group-3"]' + When user "Alice" retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | files_sharing | api_enabled | 1 | + | files_sharing | can_share | EMPTY | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files | bigfilechunking | 1 | + + @skipOnOcis + Scenario: blacklisted_files_regex is reported in capabilities + When the administrator retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | files | blacklisted_files_regex | \.(part\|filepart)$ | + + @smokeTest + Scenario: getting default capabilities with admin user + When the administrator retrieves the capabilities using the capabilities API + Then the capabilities should contain + | capability | path_to_element | value | + | core | status@@@edition | %edition% | + | core | status@@@product | %productname% | + | core | status@@@productname | %productname% | + | core | status@@@version | %version% | + | core | status@@@versionstring | %versionstring% | + And the version data in the response should contain + | name | value | + | string | %versionstring% | + | edition | %edition% | + | product | %productname% | + And the major-minor-micro version data in the response should match the version string diff --git a/tests/acceptance/features/coreApiCapabilities/capabilitiesWithNormalUser.feature b/tests/acceptance/features/coreApiCapabilities/capabilitiesWithNormalUser.feature new file mode 100644 index 00000000000..55fa7a43840 --- /dev/null +++ b/tests/acceptance/features/coreApiCapabilities/capabilitiesWithNormalUser.feature @@ -0,0 +1,51 @@ +@api @files_sharing-app-required +Feature: default capabilities for normal user + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + # adjust this scenario after fixing tagged issues as its just created to show difference + # in the response items in different environment (core & ocis-reva) + @issue-ocis-reva-175 @issue-ocis-reva-176 + Scenario: getting default capabilities with normal user + When user "Alice" retrieves the capabilities using the capabilities API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the capabilities should contain + | capability | path_to_element | value | + | core | pollinterval | 30000 | + | core | webdav-root | remote.php/webdav | + | core | status@@@edition | %edition% | + | core | status@@@productname | %productname% | + | core | status@@@version | %version% | + | core | status@@@versionstring | %versionstring% | + | files_sharing | api_enabled | 1 | + | files_sharing | default_permissions | 31 | + | files_sharing | search_min_length | 2 | + | files_sharing | public@@@enabled | 1 | + | files_sharing | public@@@multiple | 1 | + | files_sharing | public@@@upload | 1 | + | files_sharing | public@@@supports_upload_only | 1 | + | files_sharing | public@@@send_mail | EMPTY | + | files_sharing | public@@@social_share | 1 | + | files_sharing | public@@@enforced | EMPTY | + | files_sharing | public@@@enforced_for@@@read_only | EMPTY | + | files_sharing | public@@@enforced_for@@@read_write | EMPTY | + | files_sharing | public@@@enforced_for@@@upload_only | EMPTY | + | files_sharing | public@@@enforced_for@@@read_write_delete | EMPTY | + | files_sharing | public@@@expire_date@@@enabled | EMPTY | + | files_sharing | public@@@defaultPublicLinkShareName | Public link | + | files_sharing | resharing | 1 | + | files_sharing | federation@@@outgoing | 1 | + | files_sharing | federation@@@incoming | 1 | + | files_sharing | group_sharing | 1 | + | files_sharing | share_with_group_members_only | EMPTY | + | files_sharing | share_with_membership_groups_only | EMPTY | + | files_sharing | auto_accept_share | 1 | + | files_sharing | user_enumeration@@@enabled | 1 | + | files_sharing | user_enumeration@@@group_members_only | EMPTY | + | files_sharing | user@@@send_mail | EMPTY | + | files | bigfilechunking | 1 | + | files | privateLinks | 1 | + | files | privateLinksDetailsParam | 1 | diff --git a/tests/acceptance/features/coreApiComments/comments.feature b/tests/acceptance/features/coreApiComments/comments.feature new file mode 100644 index 00000000000..20641d996a3 --- /dev/null +++ b/tests/acceptance/features/coreApiComments/comments.feature @@ -0,0 +1,80 @@ +@api @comments-app-required @issue-ocis-reva-38 +Feature: Comments + + Background: + Given using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario: Getting info of comments using files endpoint + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + And user "Alice" has commented with content "My first comment" on file "/myFileToComment.txt" + And user "Alice" should have the following comments on file "/myFileToComment.txt" + | user | comment | + | Alice | My first comment | + When user "Alice" gets the following properties of folder "/myFileToComment.txt" using the WebDAV API + | propertyName | + | oc:comments-href | + | oc:comments-count | + | oc:comments-unread | + Then the HTTP status code should be "201" + And the single response should contain a property "oc:comments-count" with value "1" + And the single response should contain a property "oc:comments-unread" with value "0" + And the single response should contain a property "oc:comments-href" with value "%a_comment_url%" + + + Scenario: Getting info on comments for a folder using the endpoint + Given user "Alice" has created folder "/PARENT" + And user "Alice" has commented with content "My first comment" on folder "/PARENT" + And user "Alice" should have the following comments on folder "/PARENT" + | user | comment | + | Alice | My first comment | + When user "Alice" gets the following properties of folder "/PARENT" using the WebDAV API + | propertyName | + | oc:comments-href | + | oc:comments-count | + | oc:comments-unread | + Then the HTTP status code should be "201" + And the single response should contain a property "oc:comments-count" with value "1" + And the single response should contain a property "oc:comments-unread" with value "0" + And the single response should contain a property "oc:comments-href" with value "%a_comment_url%" + + + Scenario: Getting more info about comments using REPORT method + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + And user "Alice" has commented with content "My first comment" on file "/myFileToComment.txt" + When user "Alice" gets all information about the comments on file "myFileToComment.txt" using the WebDAV REPORT API + Then the HTTP status code should be "201" + And the following comment properties should be listed about user "Alice" + | propertyName | propertyValue | + | verb | comment | + | actorType | users | + | actorId | %username% | + | objectType | files | + | isUnread | false | + | actorDisplayName | %displayname% | + | message | My first comment | + + + Scenario: Getting more info about comments using PROPFIND method + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + And user "Alice" has commented with content "My first comment" on file "myFileToComment.txt" + When user "Alice" gets the following comment properties of file "myFileToComment.txt" using the WebDAV PROPFIND API + | propertyName | + | oc:verb | + | oc:actorType | + | oc:actorId | + | oc:objectType | + | oc:isUnread | + | oc:actorDisplayName | + | oc:message | + Then the HTTP status code should be success + And the following comment properties should be listed about user "Alice" + | propertyName | propertyValue | + | verb | comment | + | actorType | users | + | actorId | %username% | + | objectType | files | + | isUnread | false | + | actorDisplayName | %displayname% | + | message | My first comment | diff --git a/tests/acceptance/features/coreApiComments/createComments.feature b/tests/acceptance/features/coreApiComments/createComments.feature new file mode 100644 index 00000000000..c22b7a108df --- /dev/null +++ b/tests/acceptance/features/coreApiComments/createComments.feature @@ -0,0 +1,106 @@ +@api @comments-app-required @files_sharing-app-required @issue-ocis-reva-38 +Feature: Comments + + Background: + Given using new DAV path + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario Outline: Creating a comment on a file belonging to myself + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + When user "Alice" comments with content "" on file "/myFileToComment.txt" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should have the following comments on file "/myFileToComment.txt" + | user | comment | + | Alice | | + Examples: + | comment | + | My first comment | + | 😀 🤖 | + | नेपालि | + + + Scenario: Creating a comment on a shared file belonging to another user + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + And user "Alice" has shared file "/myFileToComment.txt" with user "Brian" + When user "Brian" comments with content "A comment from sharee" on file "/myFileToComment.txt" using the WebDAV API + And user "Alice" comments with content "A comment from sharer" on file "/myFileToComment.txt" using the WebDAV API + Then the HTTP status code should be "201" + And user "Brian" should have the following comments on file "/myFileToComment.txt" + | user | comment | + | Brian | A comment from sharee | + | Alice | A comment from sharer | + + + Scenario: sharee comments on a group shared file + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + And user "Alice" has shared file "/myFileToComment.txt" with group "grp1" + When user "Brian" comments with content "Comment from sharee" on file "/myFileToComment.txt" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should have the following comments on file "/myFileToComment.txt" + | user | comment | + | Brian | Comment from sharee | + + + Scenario: sharee comments on read-only shared file + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + And user "Alice" has created a share with settings + | path | /myFileToComment.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read | + When user "Brian" comments with content "Comment from sharee" on file "/myFileToComment.txt" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should have the following comments on file "/myFileToComment.txt" + | user | comment | + | Brian | Comment from sharee | + + + Scenario: sharee comments on upload-only shared folder + Given user "Alice" has created folder "/FOLDER_TO_SHARE" + And user "Alice" has created a share with settings + | path | /FOLDER_TO_SHARE | + | shareType | user | + | shareWith | Brian | + | permissions | create | + When user "Brian" comments with content "Comment from sharee" on folder "/FOLDER_TO_SHARE" using the WebDAV API + Then the HTTP status code should be "501" + And user "Alice" should have 0 comments on file "/FOLDER_TO_SHARE" + + + Scenario: Creating a comment on a folder belonging to myself + Given user "Alice" has created folder "/FOLDER" + When user "Alice" comments with content "My first comment" on folder "/FOLDER" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should have the following comments on folder "/FOLDER" + | user | comment | + | Alice | My first comment | + + + Scenario: Creating a comment on a shared folder belonging to another user + Given user "Alice" has created folder "/FOLDER_TO_SHARE" + And user "Alice" has shared folder "/FOLDER_TO_SHARE" with user "Brian" + When user "Brian" comments with content "A comment from sharee" on folder "/FOLDER_TO_SHARE" using the WebDAV API + And user "Alice" comments with content "A comment from sharer" on folder "/FOLDER_TO_SHARE" using the WebDAV API + Then the HTTP status code should be "201" + And user "Brian" should have the following comments on file "/FOLDER_TO_SHARE" + | user | comment | + | Brian | A comment from sharee | + | Alice | A comment from sharer | + + + Scenario: sharee comments on a group shared folder + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/FOLDER_TO_COMMENT" + And user "Alice" has shared folder "/FOLDER_TO_COMMENT" with group "grp1" + When user "Brian" comments with content "Comment from sharee" on folder "/FOLDER_TO_COMMENT" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should have the following comments on folder "/FOLDER_TO_COMMENT" + | user | comment | + | Brian | Comment from sharee | diff --git a/tests/acceptance/features/coreApiComments/deleteComments.feature b/tests/acceptance/features/coreApiComments/deleteComments.feature new file mode 100644 index 00000000000..70094c7299f --- /dev/null +++ b/tests/acceptance/features/coreApiComments/deleteComments.feature @@ -0,0 +1,110 @@ +@api @comments-app-required @issue-ocis-reva-38 +Feature: Comments + + Background: + Given using new DAV path + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + + @smokeTest + Scenario Outline: Deleting my own comments on a file belonging to myself + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + And user "Alice" has commented with content "" on file "/myFileToComment.txt" + When user "Alice" deletes the last created comment using the WebDAV API + Then the HTTP status code should be "204" + And user "Alice" should have 0 comments on file "/myFileToComment.txt" + Examples: + | comment | + | My first comment | + | 😀 🤖 | + | नेपालि | + + + Scenario: Deleting a comment on a file belonging to myself having several comments + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + And user "Alice" has commented with content "My first comment" on file "/myFileToComment.txt" + And user "Alice" has commented with content "My second comment" on file "/myFileToComment.txt" + And user "Alice" has commented with content "My third comment" on file "/myFileToComment.txt" + And user "Alice" has commented with content "My fourth comment" on file "/myFileToComment.txt" + When user "Alice" deletes the last created comment using the WebDAV API + Then the HTTP status code should be "204" + And user "Alice" should have 3 comments on file "/myFileToComment.txt" + + @files_sharing-app-required + Scenario: Deleting my own comments on a file shared by somebody else + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToComment.txt" + And user "Alice" has shared file "/myFileToComment.txt" with user "Brian" + And user "Alice" has commented with content "File owner comment" on file "/myFileToComment.txt" + And user "Brian" has commented with content "Sharee comment" on file "/myFileToComment.txt" + And user "Brian" should have the following comments on file "/myFileToComment.txt" + | user | comment | + | Alice | File owner comment | + | Brian | Sharee comment | + When user "Brian" deletes the last created comment using the WebDAV API + Then the HTTP status code should be "204" + And user "Brian" should have 1 comments on file "/myFileToComment.txt" + + + Scenario: Deleting my own comments on a folder belonging to myself + Given user "Alice" has created folder "/FOLDER_TO_COMMENT_AND_DELETE" + And user "Alice" has commented with content "My first comment" on folder "/FOLDER_TO_COMMENT_AND_DELETE" + When user "Alice" deletes the last created comment using the WebDAV API + Then the HTTP status code should be "204" + And user "Alice" should have 0 comments on folder "/FOLDER_TO_COMMENT_AND_DELETE" + + + Scenario: Deleting a comment on a folder belonging to myself having several comments + Given user "Alice" has created folder "/FOLDER_TO_COMMENT" + And user "Alice" has commented with content "My first comment" on folder "/FOLDER_TO_COMMENT" + And user "Alice" has commented with content "My second comment" on folder "/FOLDER_TO_COMMENT" + And user "Alice" has commented with content "My third comment" on folder "/FOLDER_TO_COMMENT" + And user "Alice" has commented with content "My fourth comment" on folder "/FOLDER_TO_COMMENT" + When user "Alice" deletes the last created comment using the WebDAV API + Then the HTTP status code should be "204" + And user "Alice" should have 3 comments on folder "/FOLDER_TO_COMMENT" + + @files_sharing-app-required + Scenario: Deleting my own comments on a folder shared by somebody else + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/FOLDER_TO_COMMENT" + And user "Alice" has shared folder "/FOLDER_TO_COMMENT" with user "Brian" + And user "Alice" has commented with content "Folder owner comment" on folder "/FOLDER_TO_COMMENT" + And user "Brian" has commented with content "Sharee comment" on folder "/FOLDER_TO_COMMENT" + When user "Brian" deletes the last created comment using the WebDAV API + Then the HTTP status code should be "204" + And user "Brian" should have 1 comments on folder "/FOLDER_TO_COMMENT" + + + Scenario: deleting a folder removes existing comments on the folder + Given user "Alice" has created folder "/FOLDER_TO_DELETE" + When user "Alice" comments with content "This should be deleted" on folder "/FOLDER_TO_DELETE" using the WebDAV API + And user "Alice" deletes folder "/FOLDER_TO_DELETE" using the WebDAV API + And user "Alice" has created folder "/FOLDER_TO_DELETE" + Then the HTTP status code should be "201" + And user "Alice" should have 0 comments on folder "/FOLDER_TO_DELETE" + + @files_sharing-app-required + Scenario: deleting a user does not remove the comment + Given user "Alice" has created folder "/FOLDER_TO_COMMENT" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared folder "/FOLDER_TO_COMMENT" with user "Brian" + And user "Brian" has commented with content "Comment from sharee" on folder "/FOLDER_TO_COMMENT" + When the administrator deletes user "Brian" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should have 1 comments on folder "/FOLDER_TO_COMMENT" + And user "Alice" should have the following comments on folder "/FOLDER_TO_COMMENT" + | user | comment | + | deleted_users | Comment from sharee | + + + Scenario: deleting a content owner deletes the comment + Given user "Alice" has created folder "/FOLDER_TO_COMMENT" + And user "Alice" has commented with content "Comment from owner" on folder "/FOLDER_TO_COMMENT" + And user "Alice" has been deleted + And user "Alice" has been created with default attributes and without skeleton files + When user "Alice" creates folder "/FOLDER_TO_COMMENT" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should have 0 comments on folder "/FOLDER_TO_COMMENT" diff --git a/tests/acceptance/features/coreApiComments/editComments.feature b/tests/acceptance/features/coreApiComments/editComments.feature new file mode 100644 index 00000000000..49eed785a18 --- /dev/null +++ b/tests/acceptance/features/coreApiComments/editComments.feature @@ -0,0 +1,60 @@ +@api @comments-app-required @issue-ocis-reva-38 +Feature: Comments + + Background: + Given using new DAV path + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + + @smokeTest + Scenario Outline: Edit my own comments on a file belonging to myself + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has commented with content "File owner comment" on file "/textfile0.txt" + When user "Alice" edits the last created comment with content "" using the WebDAV API + Then the HTTP status code should be "207" + And user "Alice" should have the following comments on file "/textfile0.txt" + | user | comment | + | Alice | | + Examples: + | comment | + | My edited comment | + | 😀 🤖 | + | नेपालि | + + @files_sharing-app-required + Scenario: Edit my own comments on a file shared by someone with me + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Brian" has commented with content "Sharee comment" on file "/textfile0.txt" + When user "Brian" edits the last created comment with content "My edited comment" using the WebDAV API + Then the HTTP status code should be "207" + And user "Brian" should have the following comments on file "/textfile0.txt" + | user | comment | + | Brian | My edited comment | + + @files_sharing-app-required + Scenario: Editing comments of other users should not be possible + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Brian" has commented with content "Sharee comment" on file "/textfile0.txt" + And user "Alice" should have the following comments on file "/textfile0.txt" + | user | comment | + | Brian | Sharee comment | + When user "Alice" edits the last created comment with content "Edit the comment of another user" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should have the following comments on file "/textfile0.txt" + | user | comment | + | Brian | Sharee comment | + + + Scenario: Edit my own comments on a folder belonging to myself + Given user "Alice" has created folder "FOLDER" + And user "Alice" has commented with content "Folder owner comment" on folder "/FOLDER" + When user "Alice" edits the last created comment with content "My edited comment" using the WebDAV API + Then the HTTP status code should be "207" + And user "Alice" should have the following comments on folder "/FOLDER" + | user | comment | + | Alice | My edited comment | diff --git a/tests/acceptance/features/coreApiFavorites/favorites.feature b/tests/acceptance/features/coreApiFavorites/favorites.feature new file mode 100644 index 00000000000..553c4c1af85 --- /dev/null +++ b/tests/acceptance/features/coreApiFavorites/favorites.feature @@ -0,0 +1,307 @@ +@api +Feature: favorite + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile2.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile3.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile4.txt" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @issue-ocis-reva-276 + Scenario Outline: Favorite a folder + Given using DAV path + When user "Alice" favorites element "/FOLDER" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Alice" folder "/FOLDER" should be favorited + When user "Alice" gets the following properties of folder "/FOLDER" using the WebDAV API + | propertyName | + | oc:favorite | + Then the HTTP status code should be "207" + And the single response should contain a property "oc:favorite" with value "1" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-276 + Scenario Outline: Unfavorite a folder + Given using DAV path + And user "Alice" has favorited element "/FOLDER" + When user "Alice" unfavorites element "/FOLDER" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Alice" folder "/FOLDER" should not be favorited + When user "Alice" gets the following properties of folder "/FOLDER" using the WebDAV API + | propertyName | + | oc:favorite | + Then the HTTP status code should be "207" + And the single response should contain a property "oc:favorite" with value "0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest @issue-ocis-reva-276 + Scenario Outline: Favorite a file + Given using DAV path + When user "Alice" favorites element "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Alice" file "/textfile0.txt" should be favorited + When user "Alice" gets the following properties of file "/textfile0.txt" using the WebDAV API + | propertyName | + | oc:favorite | + Then the HTTP status code should be "207" + And the single response should contain a property "oc:favorite" with value "1" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest @issue-ocis-reva-276 + Scenario Outline: Unfavorite a file + Given using DAV path + And user "Alice" has favorited element "/textfile0.txt" + When user "Alice" unfavorites element "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Alice" file "/textfile0.txt" should not be favorited + When user "Alice" gets the following properties of file "/textfile0.txt" using the WebDAV API + | propertyName | + | oc:favorite | + Then the HTTP status code should be "207" + And the single response should contain a property "oc:favorite" with value "0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest + Scenario Outline: Get favorited elements of a folder + Given using DAV path + When user "Alice" favorites element "/FOLDER" using the WebDAV API + And user "Alice" favorites element "/textfile0.txt" using the WebDAV API + And user "Alice" favorites element "/textfile1.txt" using the WebDAV API + Then the HTTP status code should be "207" + And user "Alice" should have favorited the following elements + | /FOLDER | + | /textfile0.txt | + | /textfile1.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Get favorited elements of a subfolder + Given using DAV path + And user "Alice" has created folder "/subfolder" + And user "Alice" has uploaded file with content "some data" to "/subfolder/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/subfolder/textfile1.txt" + And user "Alice" has uploaded file with content "some data" to "/subfolder/textfile2.txt" + When user "Alice" favorites element "/subfolder/textfile0.txt" using the WebDAV API + And user "Alice" favorites element "/subfolder/textfile1.txt" using the WebDAV API + And user "Alice" favorites element "/subfolder/textfile2.txt" using the WebDAV API + And user "Alice" unfavorites element "/subfolder/textfile1.txt" using the WebDAV API + Then the HTTP status code should be "207" + And user "Alice" should have favorited the following elements + | /subfolder/textfile0.txt | + | /subfolder/textfile2.txt | + And user "Alice" should not have favorited the following elements + | /subfolder/textfile1.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @notToImplementOnOCIS + 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 + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has favorited element "/shared/shared_file.txt" + When user "Brian" moves file "/shared/shared_file.txt" to "/taken_out.txt" using the WebDAV API + Then user "Brian" should have favorited the following elements + | /taken_out.txt | + Examples: + | dav_version | + | old | + | new | + + @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" + And user "Alice" has favorited element "/textfile1.txt" + And user "Alice" has favorited element "/textfile2.txt" + And user "Alice" has favorited element "/textfile3.txt" + And user "Alice" has favorited element "/textfile4.txt" + When user "Alice" lists the favorites and limits the result to 3 elements using the WebDAV API + Then the search result should contain any "3" of these entries: + | /textfile0.txt | + | /textfile1.txt | + | /textfile2.txt | + | /textfile3.txt | + | /textfile4.txt | + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-33840 @skipOnOcV10 + Scenario Outline: Get favorited elements paginated in subfolder + Given using DAV path + And user "Alice" has created folder "/subfolder" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile1.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile2.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile3.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile4.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile5.txt" + And user "Alice" has favorited element "/subfolder/textfile0.txt" + And user "Alice" has favorited element "/subfolder/textfile1.txt" + And user "Alice" has favorited element "/subfolder/textfile2.txt" + And user "Alice" has favorited element "/subfolder/textfile3.txt" + And user "Alice" has favorited element "/subfolder/textfile4.txt" + And user "Alice" has favorited element "/subfolder/textfile5.txt" + When user "Alice" lists the favorites and limits the result to 3 elements using the WebDAV API + Then the search result should contain any "3" of these entries: + | /subfolder/textfile0.txt | + | /subfolder/textfile1.txt | + | /subfolder/textfile2.txt | + | /subfolder/textfile3.txt | + | /subfolder/textfile4.txt | + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @notToImplementOnOCIS + 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 + And user "Alice" has moved file "/textfile0.txt" to "/favoriteFile.txt" + And user "Alice" has shared file "/favoriteFile.txt" with user "Brian" + When user "Alice" favorites element "/favoriteFile.txt" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Alice" file "/favoriteFile.txt" should be favorited + And as user "Brian" file "/favoriteFile.txt" should not be favorited + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required @notToImplementOnOCIS + 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 + And user "Alice" has moved file "/textfile0.txt" to "/favoriteFile.txt" + And user "Alice" has shared file "/favoriteFile.txt" with user "Brian" + When user "Brian" favorites element "/favoriteFile.txt" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Alice" file "/favoriteFile.txt" should not be favorited + Examples: + | dav_version | + | old | + | new | + + + 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 + And user "Alice" favorites element "/PARENT" using the WebDAV API + Then the HTTP status code should be "207" + And user "Alice" should have favorited the following elements + | /PARENT | + | /PARENT/parent.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @notToImplementOnOCIS + Scenario Outline: favorite a file inside of a received share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared folder "/PARENT" with user "Brian" + When user "Brian" favorites element "/PARENT/parent.txt" using the WebDAV API + Then as user "Brian" file "/PARENT/parent.txt" should be favorited + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required @notToImplementOnOCIS + Scenario Outline: favorite a folder inside of a received share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT/sub-folder" + And user "Alice" has shared folder "/PARENT" with user "Brian" + When user "Brian" favorites element "/PARENT/sub-folder" using the WebDAV API + Then as user "Brian" folder "/PARENT/sub-folder" should be favorited + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required @notToImplementOnOCIS + Scenario Outline: favorite a received share itself + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared folder "/PARENT" with user "Brian" + When user "Brian" favorites element "/PARENT" using the WebDAV API + Then as user "Brian" folder "/PARENT" should be favorited + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/coreApiFavorites/favoritesOc10Issue33840.feature b/tests/acceptance/features/coreApiFavorites/favoritesOc10Issue33840.feature new file mode 100644 index 00000000000..2262639eb46 --- /dev/null +++ b/tests/acceptance/features/coreApiFavorites/favoritesOc10Issue33840.feature @@ -0,0 +1,66 @@ +@api @notToImplementOnOCIS +Feature: current oC10 behavior for issue-33840 + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile2.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile3.txt" + And user "Alice" has uploaded file with content "some data" to "/textfile4.txt" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + @issue-33840 @issue-ocis-reva-39 + Scenario Outline: Get favorited elements and limit count of entries + Given using DAV path + And user "Alice" has favorited element "/textfile0.txt" + And user "Alice" has favorited element "/textfile1.txt" + And user "Alice" has favorited element "/textfile2.txt" + And user "Alice" has favorited element "/textfile3.txt" + And user "Alice" has favorited element "/textfile4.txt" + When user "Alice" lists the favorites and limits the result to 3 elements using the WebDAV API + #Then the search result should contain any "3" of these entries: + Then the HTTP status code should be "207" + And the search result should contain any "0" of these entries: + | /textfile0.txt | + | /textfile1.txt | + | /textfile2.txt | + | /textfile3.txt | + | /textfile4.txt | + Examples: + | dav_version | + | old | + | new | + + @issue-33840 @issue-ocis-reva-39 + Scenario Outline: Get favorited elements paginated in subfolder + Given using DAV path + And user "Alice" has created folder "/subfolder" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile1.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile2.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile3.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile4.txt" + And user "Alice" has copied file "/textfile0.txt" to "/subfolder/textfile5.txt" + And user "Alice" has favorited element "/subfolder/textfile0.txt" + And user "Alice" has favorited element "/subfolder/textfile1.txt" + And user "Alice" has favorited element "/subfolder/textfile2.txt" + And user "Alice" has favorited element "/subfolder/textfile3.txt" + And user "Alice" has favorited element "/subfolder/textfile4.txt" + And user "Alice" has favorited element "/subfolder/textfile5.txt" + When user "Alice" lists the favorites and limits the result to 3 elements using the WebDAV API + #Then the search result should contain any "3" of these entries: + Then the HTTP status code should be "207" + And the search result should contain any "0" of these entries: + | /subfolder/textfile0.txt | + | /subfolder/textfile1.txt | + | /subfolder/textfile2.txt | + | /subfolder/textfile3.txt | + | /subfolder/textfile4.txt | + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/coreApiFavorites/favoritesSharingToShares.feature b/tests/acceptance/features/coreApiFavorites/favoritesSharingToShares.feature new file mode 100644 index 00000000000..937624f5d50 --- /dev/null +++ b/tests/acceptance/features/coreApiFavorites/favoritesSharingToShares.feature @@ -0,0 +1,83 @@ +@api @files_sharing-app-required +Feature: favorite + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + + + Scenario Outline: favorite a file inside of a received share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" favorites element "/Shares/PARENT/parent.txt" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Brian" file "/Shares/PARENT/parent.txt" should be favorited + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: favorite a folder inside of a received share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT/sub-folder" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" favorites element "/Shares/PARENT/sub-folder" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Brian" folder "/Shares/PARENT/sub-folder" should be favorited + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: favorite a received share itself + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" favorites element "/Shares/PARENT" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Brian" folder "/Shares/PARENT" should be favorited + Examples: + | dav_version | + | old | + | new | + + + 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 + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has favorited element "/Shares/PARENT/parent.txt" + When user "Brian" moves file "/Shares/PARENT/parent.txt" to "/taken_out.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/taken_out.txt" should exist + And as user "Brian" file "/taken_out.txt" should be favorited + Examples: + | dav_version | + | old | + | new | + + + 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 + And user "Alice" has shared file "/PARENT/parent.txt" with user "Brian" + And user "Brian" has accepted share "/parent.txt" offered by user "Alice" + When user "Brian" favorites element "/Shares/parent.txt" using the WebDAV API + Then the HTTP status code should be "207" + And as user "Brian" file "/Shares/parent.txt" should be favorited + And as user "Alice" file "/PARENT/parent.txt" should not be favorited + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/coreApiFederationToRoot1/etagPropagation.feature b/tests/acceptance/features/coreApiFederationToRoot1/etagPropagation.feature new file mode 100644 index 00000000000..58792f5173f --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToRoot1/etagPropagation.feature @@ -0,0 +1,98 @@ +@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: propagation of etags between federated and local server + + Background: + Given using OCS API version "1" + And using server "REMOTE" + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "PARENT" + And using server "LOCAL" + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "PARENT" + + + Scenario: Overwrite a federated shared folder as sharer propagates etag for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/PARENT (2)" + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/PARENT (2)" of user "Alice" on server "REMOTE" should have changed + + @issue-enterprise-2848 + Scenario: Overwrite a federated shared folder as sharer propagates etag to root folder for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/" + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + # After fixing issue-enterprise-2848, change the following step to "should have changed" + And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed + #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + + @issue-enterprise-2848 + Scenario: Adding a file to a federated shared folder as sharer propagates etag to root folder for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/" + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/lorem.txt" to "/PARENT/new-textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + # After fixing issue-enterprise-2848, change the following step to "should have changed" + And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed + #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + + + Scenario: Overwrite a federated shared folder as recipient propagates etag for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/PARENT (2)" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/PARENT (2)" of user "Alice" on server "REMOTE" should have changed + + + Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + + + Scenario: Overwrite a federated shared folder as recipient propagates etag for sharer + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Brian" has stored etag of element "/PARENT" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/PARENT" of user "Brian" on server "LOCAL" should have changed + + + Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for sharer + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Brian" has stored etag of element "/" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT (2)/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/" of user "Brian" on server "LOCAL" should have changed + + + Scenario: Adding a file to a federated shared folder as recipient propagates etag to root folder for sharer + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Brian" has stored etag of element "/" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/lorem.txt" to "/PARENT (2)/new-textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/" of user "Brian" on server "LOCAL" should have changed diff --git a/tests/acceptance/features/coreApiFederationToRoot1/federated.feature b/tests/acceptance/features/coreApiFederationToRoot1/federated.feature new file mode 100644 index 00000000000..222fe003cea --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToRoot1/federated.feature @@ -0,0 +1,585 @@ +@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: federated + + Background: + Given using server "REMOTE" + And user "Alice" has been created with default attributes and without skeleton files + And using server "LOCAL" + And user "Brian" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: Federate share a file with another server + Given using OCS API version "" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | federated | + | file_source | A_STRING | + | path | /textfile0.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | share_with | %username%@REMOTE | + | share_with_displayname | %username%@REMOTE | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: Federate share a file with local server + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And using server "LOCAL" + When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | federated | + | file_source | A_STRING | + | path | /textfile0.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | share_with | %username%@LOCAL | + | share_with_displayname | %username%@LOCAL | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharee can see the pending share + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + And using server "LOCAL" + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | {{TemporaryMountPointName#/textfile0.txt}} | + | accepted | 0 | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharee requests information of only one share + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + When user "Brian" retrieves the information of the last federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | /textfile0.txt | + | accepted | 1 | + | type | file | + | permissions | share,read,update,delete | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharee requests information of only one share before accepting it + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + And using server "LOCAL" + When user "Brian" retrieves the information of the last pending federated cloud share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | {{TemporaryMountPointName#/textfile0.txt}} | + | accepted | 0 | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sending a GET request to a pending federated share is not valid + Given using OCS API version "" + When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/pending/12" + Then the HTTP status code should be "405" + And the body of the response should be empty + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sending a GET request to a nonexistent federated share + Given using OCS API version "" + When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/9999999999" + Then the OCS status code should be "" + And the HTTP status code should be "" + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 404 | 200 | + | 2 | 404 | 404 | + + + Scenario Outline: accept a pending federated share + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + When user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Reshare a federated shared file + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + And user "Carol" has been created with default attributes and small skeleton files + When user "Brian" creates a share using the sharing API with settings + | path | /textfile0.txt | + | shareType | user | + | shareWith | Carol | + | permissions | share,read,update | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Carol" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | user | + | file_source | A_STRING | + | path | /textfile0.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | share_with | %username% | + | share_with_displayname | %displayname% | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Overwrite a federated shared file as recipient - local server shares - remote server receives + Given using OCS API version "" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" from server "LOCAL" has shared "/textfile0.txt" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textfile0.txt" for user "Brian" on server "LOCAL" should be "BLABLABLA" plus end-of-line + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Overwrite a federated shared file as recipient - remote server shares - local server receives + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textfile0.txt" for user "Alice" on server "REMOTE" should be "BLABLABLA" plus end-of-line + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Overwrite a file in a federated shared folder as recipient - local server shares - remote server receives + Given using OCS API version "" + And user "Brian" has created folder "PARENT" + And user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/PARENT/textfile0.txt" for user "Brian" on server "LOCAL" should be "BLABLABLA" plus end-of-line + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Overwrite a file in a federated shared folder as recipient - remote server shares - local server receives + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has created folder "PARENT" + And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/PARENT/textfile0.txt" for user "Alice" on server "REMOTE" should be "BLABLABLA" plus end-of-line + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Overwrite a federated shared file as recipient using old chunking + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + When user "Brian" uploads the following "3" chunks to "/textfile0.txt" with old chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And the content of file "/textfile0.txt" for user "Brian" should be "AAAAABBBBBCCCCC" + And the content of file "/textfile0.txt" for user "Alice" on server "REMOTE" should be "AAAAABBBBBCCCCC" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Overwrite a file in a federated shared folder as recipient using old chunking + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has created folder "PARENT" + And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + When user "Brian" uploads the following "3" chunks to "/PARENT/textfile0.txt" with old chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And the content of file "/PARENT/textfile0.txt" for user "Brian" should be "AAAAABBBBBCCCCC" + And the content of file "/PARENT/textfile0.txt" for user "Alice" on server "REMOTE" should be "AAAAABBBBBCCCCC" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Federated sharee deletes an accepted federated share + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + When user "Brian" deletes the last federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should not see the following elements + | /textfile0.txt | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the response should contain 0 entries + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the response should contain 0 entries + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + @issue-31276 @skipOnOcV10 + Scenario Outline: Federated sharee tries to delete an accepted federated share sending wrong password + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + When user "Brian" deletes the last federated cloud share with password "invalid" using the sharing API + 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.txt | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | /textfile0.txt | + | accepted | 1 | + | type | file | + | permissions | share,delete,update,read | + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the response should contain 0 entries + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Federated sharee deletes a pending federated share + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + And using server "LOCAL" + And using OCS API version "" + When user "Brian" deletes the last pending federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should not see the following elements + | /textfile0.txt | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the response should contain 0 entries + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the response should contain 0 entries + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + @issue-31276 @skipOnOcV10 + Scenario Outline: Federated sharee tries to delete a pending federated share sending wrong password + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + And using 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" + And the HTTP status code should be "401" + And user "Brian" should not see the following elements + | /textfile0.txt | + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | {{TemporaryMountPointName#/textfile0.txt}} | + | accepted | 0 | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the response should contain 0 entries + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Trusted server handshake does not require authenticated requests - we force 403 by sending an empty body + Given using OCS API version "" + When user "UNAUTHORIZED_USER" requests shared secret using the federation API + Then the HTTP status code should be "" + And the OCS status code should be "403" + Examples: + | ocs-api-version | http-status | + | 1 | 200 | + | 2 | 403 | + + @skipOnLDAP + Scenario: Upload file to received federated share while quota is set on home storage + Given using server "REMOTE" + And user "Alice" has created folder "PARENT" + And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/PARENT/testquota.txt" with all mechanisms using the WebDAV API + Then the HTTP status code of all upload responses should be "201" + And as user "Alice" on server "REMOTE" the files uploaded to "/PARENT/testquota.txt" with all mechanisms should exist + + @skipOnLDAP + Scenario: Upload file to received federated share while quota is set on remote storage - local server shares - remote server receives + Given the quota of user "Brian" has been set to "20 B" + And user "Brian" has created folder "PARENT" + And user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/PARENT/testquota.txt" with all mechanisms using the WebDAV API + Then the HTTP status code of all upload responses should be "507" + + @skipOnLDAP + Scenario: Upload file to received federated share while quota is set on remote storage - remote server shares - local server receives + Given using server "REMOTE" + And the quota of user "Alice" has been set to "20 B" + And user "Alice" has created folder "PARENT" + And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/PARENT/testquota.txt" with all mechanisms using the WebDAV API + Then the HTTP status code of all upload responses should be "507" + + + Scenario Outline: share of a folder to a federated user who already has a folder with the same name + Given using server "REMOTE" + And user "Alice" has created folder "/zzzfolder" + And user "Alice" has created folder "zzzfolder/Alice" + And using server "LOCAL" + And user "Brian" has created folder "/zzzfolder" + And user "Brian" has created folder "zzzfolder/Brian" + When user "Alice" from server "REMOTE" shares "zzzfolder" with user "Brian" from server "LOCAL" using the sharing API + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + And user "Brian" retrieves the information of the last federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | name | /zzzfolder | + | owner | %username% | + | user | %username% | + | mountpoint | /zzzfolder (2) | + | type | dir | + | permissions | all | + And as "Brian" folder "zzzfolder/Brian" should exist + And as "Brian" folder "zzzfolder (2)/Alice" should exist + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: share of a file to the federated user who already has a file with the same name + Given using server "REMOTE" + And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt" + And using server "LOCAL" + And user "Brian" has uploaded file with content "local content" to "/randomfile.txt" + When user "Alice" from server "REMOTE" shares "/randomfile.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 OCS API version "" + And user "Brian" retrieves the information of the last federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /randomfile.txt | + | owner | %username% | + | user | %username% | + | mountpoint | /randomfile (2).txt | + | accepted | 1 | + | type | file | + | permissions | share,delete,update,read | + And the content of file "/randomfile.txt" for user "Brian" on server "LOCAL" should be "local content" + And the content of file "/randomfile (2).txt" for user "Brian" on server "LOCAL" should be "remote content" + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + @issue-35154 + Scenario: receive a local share that has the same name as a previously received federated share + Given using server "REMOTE" + And user "Alice" has created folder "/zzzfolder" + And user "Alice" has created folder "zzzfolder/remote" + And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt" + And using server "LOCAL" + And user "Carol" has been created with default attributes and small skeleton files + And user "Brian" has created folder "/zzzfolder" + And user "Brian" has created folder "zzzfolder/local" + And user "Brian" has uploaded file with content "local content" to "/randomfile.txt" + When user "Alice" from server "REMOTE" shares "zzzfolder" with user "Carol" from server "LOCAL" using the sharing API + And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API + And user "Alice" from server "REMOTE" shares "randomfile.txt" with user "Carol" from server "LOCAL" using the sharing API + And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API + And user "Brian" shares folder "zzzfolder" with user "Carol" using the sharing API + And user "Brian" shares folder "randomfile.txt" with user "Carol" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + # local shares are taking priority at the moment + And as "Carol" folder "zzzfolder (2)/remote" should exist + And as "Carol" folder "zzzfolder/local" should exist + And the content of file "/randomfile (2).txt" for user "Carol" on server "LOCAL" should be "remote content" + And the content of file "/randomfile.txt" for user "Carol" on server "LOCAL" should be "local content" + + + Scenario: receive a federated share that has the same name as a previously received local share + Given using server "REMOTE" + And user "Alice" has created folder "/zzzfolder" + And user "Alice" has created folder "zzzfolder/remote" + And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt" + And using server "LOCAL" + And user "Carol" has been created with default attributes and small skeleton files + And user "Brian" has created folder "/zzzfolder" + And user "Brian" has created folder "zzzfolder/local" + And user "Brian" has uploaded file with content "local content" to "/randomfile.txt" + When user "Brian" shares folder "zzzfolder" with user "Carol" using the sharing API + And user "Brian" shares folder "randomfile.txt" with user "Carol" using the sharing API + And user "Alice" from server "REMOTE" shares "zzzfolder" with user "Carol" from server "LOCAL" using the sharing API + And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API + And user "Alice" from server "REMOTE" shares "randomfile.txt" with user "Carol" from server "LOCAL" using the sharing API + And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Carol" folder "zzzfolder/local" should exist + And as "Carol" folder "zzzfolder (2)/remote" should exist + And the content of file "/randomfile.txt" for user "Carol" on server "LOCAL" should be "local content" + And the content of file "/randomfile (2).txt" for user "Carol" on server "LOCAL" should be "remote content" diff --git a/tests/acceptance/features/coreApiFederationToRoot1/federatedOc10Issue31276.feature b/tests/acceptance/features/coreApiFederationToRoot1/federatedOc10Issue31276.feature new file mode 100644 index 00000000000..54aa5319e10 --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToRoot1/federatedOc10Issue31276.feature @@ -0,0 +1,69 @@ +@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: current oC10 behavior for issue-31276 + + Background: + Given using server "REMOTE" + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And using server "LOCAL" + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + + @issue-31276 + Scenario Outline: Federated 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 "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 (2).txt | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | /textfile0 (2).txt | + | accepted | 1 | + | type | file | + | permissions | share,delete,update,read | + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the response should contain 0 entries + Examples: + | ocs-api-version | + | 1 | + | 2 | + + @issue-31276 + Scenario Outline: Federated 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 (2).txt | + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | {{TemporaryMountPointName#/textfile0.txt}} | + | accepted | 0 | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the response should contain 0 entries + Examples: + | ocs-api-version | + | 1 | + | 2 | diff --git a/tests/acceptance/features/coreApiFederationToRoot1/savePublicShare.feature b/tests/acceptance/features/coreApiFederationToRoot1/savePublicShare.feature new file mode 100644 index 00000000000..885f13e0269 --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToRoot1/savePublicShare.feature @@ -0,0 +1,141 @@ +@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: Save public shares created by oC users + + Background: + Given using server "LOCAL" + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario: Mount public share created from local server + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/lorem.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When user "Brian" adds the public share created from server "LOCAL" using the sharing API + Then the HTTP status code should be "200" + And as "Brian" folder "/PARENT" should exist + And as "Brian" file "/PARENT/lorem.txt" should exist + + + Scenario: Mount public share and then delete (local server share) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read | + And user "Brian" has added the public share created from server "LOCAL" using the sharing API + When user "Brian" deletes folder "/PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" folder "/PARENT" should not exist + + + Scenario Outline: Mount public share and sharer unshares the share (local server share) + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read | + | name | sharedlink | + And user "Brian" has added the public share created from server "LOCAL" using the sharing API + When user "Alice" deletes public link share named "sharedlink" in file "/PARENT" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" folder "/PARENT" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Mount public share and try to reshare (local server share) + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + And user "Brian" has added the public share created from server "LOCAL" using the sharing API + When user "Brian" creates a public link share using the sharing API with settings + | path | PARENT | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario: Mount public share created from remote server + Given using server "REMOTE" + And user "RemoteAlice" has been created with default attributes and without skeleton files + And user "RemoteAlice" has created folder "/PARENT" + And user "RemoteAlice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/lorem.txt" + And user "RemoteAlice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + And using server "LOCAL" + When user "Alice" adds the public share created from server "REMOTE" using the sharing API + Then the HTTP status code should be "200" + And as "Alice" folder "/PARENT" should exist + And as "Alice" file "/PARENT/lorem.txt" should exist + + + Scenario: Mount public share and then delete (remote server share) + Given using server "REMOTE" + And user "RemoteAlice" has been created with default attributes and without skeleton files + And user "RemoteAlice" has created folder "/PARENT" + And user "RemoteAlice" has created a public link share with settings + | path | /PARENT | + | permissions | read | + And using server "LOCAL" + And user "Alice" has added the public share created from server "REMOTE" using the sharing API + When user "Alice" deletes folder "/PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/PARENT" should not exist + + + Scenario Outline: Mount public share and sharer unshares the share (remote server share) + Given using OCS API version "" + And using server "REMOTE" + And user "RemoteAlice" has been created with default attributes and without skeleton files + And user "RemoteAlice" has created folder "/PARENT" + And user "RemoteAlice" has created a public link share with settings + | path | /PARENT | + | permissions | read | + | name | sharedlink | + And using server "LOCAL" + And user "Alice" has added the public share created from server "REMOTE" using the sharing API + And using server "REMOTE" + When user "RemoteAlice" deletes public link share named "sharedlink" in file "/PARENT" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When using server "LOCAL" + Then the HTTP status code should be "200" + And as "Alice" folder "/PARENT" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Mount public share and try to reshare (remote server share) + Given using OCS API version "" + And using server "REMOTE" + And user "RemoteAlice" has been created with default attributes and without skeleton files + And user "RemoteAlice" has created folder "/PARENT" + And user "RemoteAlice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + And using server "LOCAL" + And user "Alice" has added the public share created from server "REMOTE" using the sharing API + When user "Alice" creates a public link share using the sharing API with settings + | path | PARENT | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiFederationToRoot2/federated.feature b/tests/acceptance/features/coreApiFederationToRoot2/federated.feature new file mode 100644 index 00000000000..d117cd0581f --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToRoot2/federated.feature @@ -0,0 +1,763 @@ +@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: federated + + Background: + Given using server "REMOTE" + And user "Alice" has been created with default attributes and without skeleton files + And using server "LOCAL" + And user "Brian" has been created with default attributes and without skeleton files + + @issue-35839 @skipOnOcV10 + Scenario: "Auto accept from trusted servers" enabled with remote server + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And using server "LOCAL" + And the trusted server list is cleared + 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 the OCS status code of responses on each endpoint should be "201, 100" respectively + And the HTTP status code of responses on each endpoint should be "201, 200" respectively + And as "Brian" file "textfile1 (2).txt" should exist + And url "%remote_server%" should be a trusted server + + @issue-35839 @skipOnOcV10 + Scenario: "Auto accept from trusted servers" disabled with remote server + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And using server "LOCAL" + And the trusted server list is cleared + 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 the OCS status code of responses on each endpoint should be "201, 100" respectively + And the HTTP status code of responses on each endpoint should be "201, 200" respectively + And as "Brian" file "textfile1.txt" should not exist + And url "%remote_server%" should be a trusted server + + + Scenario: Federated share with "Auto add server" enabled + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And using server "LOCAL" + And the trusted server list is cleared + And parameter "autoAddServers" of app "federation" has been set to "1" + When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + And using server "LOCAL" + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" file "textfile1.txt" should exist + And url "%remote_server%" should be a trusted server + + + Scenario: Federated share with "Auto add server" disabled + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And using server "LOCAL" + And the trusted server list is cleared + And parameter "autoAddServers" of app "federation" has been set to "0" + When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + And using server "LOCAL" + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" file "textfile1.txt" should exist + And url "%remote_server%" should not be a trusted server + + @issue-35839 @skipOnOcV10 + Scenario: enable "Add server automatically" once a federated share was created successfully + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And using server "LOCAL" + 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" accepts the last pending share using the sharing API + And using server "LOCAL" + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And 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 the OCS status code should be "100" + And the HTTP status code should be "200" + And as "Brian" file "textfile1.txt" should exist + + @issue-35839 @skipOnOcV10 + Scenario: disable "Add server automatically" once a federated share was created successfully + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And 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" accepts the last pending share using the sharing API + And using server "LOCAL" + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And url "%remote_server%" should not be a trusted server + When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And as "Brian" file "textfile1.txt" should not exist + + + Scenario Outline: federated share receiver sees the original content of a received file + Given using server "REMOTE" + And user "Alice" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And user "Alice" from server "REMOTE" has shared "file-to-share" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + When using server "LOCAL" + Then the content of file "/file-to-share" for user "Brian" should be "thisContentIsVisible" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: federated share receiver sees the original content of a received file in multiple levels of folders + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has uploaded file with content "thisContentIsVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder/file-to-share" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + When using server "LOCAL" + Then the content of file "/file-to-share" for user "Brian" should be "thisContentIsVisible" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: remote federated share receiver adds files/folders in the federated share + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + And using server "REMOTE" + When user "Alice" uploads file with content "thisContentIsFinal" to "/RandomFolder/new-file" using the WebDAV API + And user "Alice" creates folder "/RandomFolder/sub-folder" using the WebDAV API + And using server "LOCAL" + Then the HTTP status code of responses on all endpoints should be "201" + And as "Brian" file "/PARENT/RandomFolder/new-file" should exist + And as "Brian" file "/PARENT/RandomFolder/file-to-share" should exist + And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should exist + And the content of file "/PARENT/RandomFolder/new-file" for user "Brian" should be "thisContentIsFinal" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: local federated share receiver adds files/folders in the federated share + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + And using server "LOCAL" + When user "Brian" uploads file with content "thisContentIsFinal" to "/RandomFolder/new-file" using the WebDAV API + And user "Brian" creates folder "/RandomFolder/sub-folder" using the WebDAV API + And using server "REMOTE" + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" file "/PARENT/RandomFolder/new-file" should exist + And as "Alice" file "/PARENT/RandomFolder/file-to-share" should exist + And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should exist + And the content of file "/PARENT/RandomFolder/new-file" for user "Alice" should be "thisContentIsFinal" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: local federated share receiver deletes files/folders of the received share + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + And using server "LOCAL" + When user "Brian" deletes folder "/RandomFolder/sub-folder" using the WebDAV API + And user "Brian" deletes file "/RandomFolder/file-to-share" using the WebDAV API + And using server "REMOTE" + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" file "/PARENT/RandomFolder/file-to-share" should not exist + And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should not exist + But as "Alice" folder "/PARENT/RandomFolder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: remote federated share receiver deletes files/folders of the received share + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + And using server "REMOTE" + When user "Alice" deletes folder "/RandomFolder/sub-folder" using the WebDAV API + And user "Alice" deletes file "/RandomFolder/file-to-share" using the WebDAV API + And using server "LOCAL" + Then the HTTP status code of responses on all endpoints should be "204" + And as "Brian" file "/PARENT/RandomFolder/file-to-share" should not exist + And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should not exist + But as "Brian" folder "/PARENT/RandomFolder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: local federated share receiver renames files/folders of the received share + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + And using server "LOCAL" + When user "Brian" moves folder "/RandomFolder/sub-folder" to "/RandomFolder/renamed-sub-folder" using the WebDAV API + And user "Brian" moves file "/RandomFolder/file-to-share" to "/RandomFolder/renamedFile" using the WebDAV API + And using server "REMOTE" + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" file "/PARENT/RandomFolder/file-to-share" should not exist + But as "Alice" file "/PARENT/RandomFolder/renamedFile" should exist + And the content of file "/PARENT/RandomFolder/renamedFile" for user "Alice" should be "thisContentShouldBeVisible" + And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should not exist + But as "Alice" folder "/PARENT/RandomFolder/renamed-sub-folder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: remote federated share receiver renames files/folders of the received share + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + And using server "REMOTE" + When user "Alice" moves folder "/RandomFolder/sub-folder" to "/RandomFolder/renamed-sub-folder" using the WebDAV API + And user "Alice" moves file "/RandomFolder/file-to-share" to "/RandomFolder/renamedFile" using the WebDAV API + And using server "LOCAL" + Then the HTTP status code of responses on all endpoints should be "201" + And as "Brian" file "/PARENT/RandomFolder/file-to-share" should not exist + But as "Brian" file "/PARENT/RandomFolder/renamedFile" should exist + And the content of file "/PARENT/RandomFolder/renamedFile" for user "Brian" should be "thisContentShouldBeVisible" + And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should not exist + But as "Brian" folder "/PARENT/RandomFolder/renamed-sub-folder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer modifies the share which was shared to the federated share receiver + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has uploaded file with content "thisContentShouldBeChanged" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder/file-to-share" 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 "Alice" uploads file with content "thisContentIsFinal" to "/PARENT/RandomFolder/file-to-share" using the WebDAV API + And using server "LOCAL" + Then the HTTP status code should be "204" + And the content of file "/file-to-share" for user "Brian" should be "thisContentIsFinal" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer adds files/folders in the share which was shared to the federated share receiver + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" 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 "Alice" uploads file with content "thisContentIsFinal" to "/PARENT/RandomFolder/new-file" using the WebDAV API + And user "Alice" creates folder "/PARENT/RandomFolder/sub-folder" using the WebDAV API + And using server "LOCAL" + Then the HTTP status code of responses on all endpoints should be "201" + And as "Brian" file "/RandomFolder/new-file" should exist + And as "Brian" file "/RandomFolder/file-to-share" should exist + And as "Brian" folder "/RandomFolder/sub-folder" should exist + And the content of file "/RandomFolder/new-file" for user "Brian" should be "thisContentIsFinal" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer deletes files/folders of the share which was shared to the federated share receiver + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" 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 "Alice" deletes folder "/PARENT/RandomFolder/sub-folder" using the WebDAV API + And user "Alice" deletes file "/PARENT/RandomFolder/file-to-share" using the WebDAV API + And using server "LOCAL" + Then the HTTP status code of responses on all endpoints should be "204" + And as "Brian" file "/RandomFolder/file-to-share" should not exist + And as "Brian" folder "/RandomFolder/sub-folder" should not exist + But as "Brian" folder "/RandomFolder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer renames files/folders of the share which was shared to the federated share receiver + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" 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 "Alice" moves folder "/PARENT/RandomFolder/sub-folder" to "/PARENT/RandomFolder/renamed-sub-folder" using the WebDAV API + And user "Alice" moves file "/PARENT/RandomFolder/file-to-share" to "/PARENT/RandomFolder/renamedFile" using the WebDAV API + And using server "LOCAL" + Then the HTTP status code of responses on all endpoints should be "201" + And as "Brian" file "/RandomFolder/file-to-share" should not exist + But as "Brian" file "/RandomFolder/renamedFile" should exist + And the content of file "/RandomFolder/renamedFile" for user "Brian" should be "thisContentShouldBeVisible" + And as "Brian" folder "/RandomFolder/sub-folder" should not exist + But as "Brian" folder "/RandomFolder/renamed-sub-folder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer unshares the federated share and the receiver no longer sees the files/folders + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + When user "Brian" deletes the last share using the sharing API + And using server "REMOTE" + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Alice" file "/RandomFolder/file-to-share" should not exist + And as "Alice" folder "/RandomFolder" should not exist + Examples: + | ocs-api-version | ocs-status-code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: federated share receiver can move the location of the received share and changes are correctly seen at both ends + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + And using server "REMOTE" + When user "Alice" creates folder "/CHILD" using the WebDAV API + And user "Alice" creates folder "/CHILD/newRandomFolder" using the WebDAV API + And user "Alice" moves folder "/RandomFolder" to "/CHILD/newRandomFolder/RandomFolder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" file "/CHILD/newRandomFolder/RandomFolder/file-to-share" should exist + When using server "LOCAL" + Then as "Brian" file "/PARENT/RandomFolder/file-to-share" should exist + When user "Brian" uploads file with content "thisIsTheContentOfNewFile" to "/PARENT/RandomFolder/newFile" using the WebDAV API + And user "Brian" uploads file with content "theContentIsChanged" to "/PARENT/RandomFolder/file-to-share" using the WebDAV API + And using server "REMOTE" + Then the HTTP status code of responses on each endpoint should be "201, 204" respectively + And as "Alice" file "/CHILD/newRandomFolder/RandomFolder/newFile" should exist + And the content of file "/CHILD/newRandomFolder/RandomFolder/file-to-share" for user "Alice" should be "theContentIsChanged" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: federated sharer can move the location of the received share and changes are correctly seen at both ends + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + When user "Brian" creates folder "/CHILD" using the WebDAV API + And user "Brian" creates folder "/CHILD/newRandomFolder" using the WebDAV API + And user "Brian" moves folder "PARENT/RandomFolder" to "/CHILD/newRandomFolder/RandomFolder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And as "Brian" file "/CHILD/newRandomFolder/RandomFolder/file-to-share" should exist + When using server "REMOTE" + Then as "Alice" file "/RandomFolder/file-to-share" should exist + When user "Alice" uploads file with content "thisIsTheContentOfNewFile" to "/RandomFolder/newFile" using the WebDAV API + And user "Alice" uploads file with content "theContentIsChanged" to "/RandomFolder/file-to-share" using the WebDAV API + When using server "LOCAL" + Then the HTTP status code of responses on each endpoint should be "201, 204" respectively + And as "Brian" file "/CHILD/newRandomFolder/RandomFolder/newFile" should exist + And the content of file "/CHILD/newRandomFolder/RandomFolder/file-to-share" for user "Brian" should be "theContentIsChanged" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Both Incoming and Outgoing federation shares are allowed + Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And using OCS API version "" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + When user "Brian" from server "LOCAL" shares "file-to-share" with user "Alice" from server "REMOTE" using the sharing API + And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API + And using server "REMOTE" + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + Then as "Alice" file "/file-to-share" should exist + And the content of file "/file-to-share" for user "Alice" should be "thisContentIsVisible" + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + And using server "LOCAL" + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on each endpoint should be "201, 200, 200" respectively + And as "Brian" file "/newFile" should exist + And the content of file "/newFile" for user "Brian" should be "thisFileIsShared" + Examples: + | ocs-api-version | ocs-status-code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Incoming federation shares are allowed but outgoing federation shares are restricted + Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And using OCS API version "" + When user "Brian" from server "LOCAL" shares "file-to-share" with user "Alice" from server "REMOTE" using the sharing API + And using server "REMOTE" + Then the OCS status code should be "403" + And the HTTP status code should be "" + And user "Alice" should not have any pending federated cloud share + And as "Alice" file "/file-to-share" should not exist + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + And using server "LOCAL" + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on each endpoint should be "201, 200, 200" respectively + And as "Brian" file "/newFile" should exist + Examples: + | ocs-api-version | ocs-status-code | http-status-code | + | 1 | 100 | 200 | + | 2 | 200 | 403 | + + + Scenario Outline: Incoming federation shares are restricted but outgoing federation shares are allowed + Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And using OCS API version "" + And user "Brian" from server "LOCAL" has shared "/file-to-share" with user "Alice" from server "REMOTE" + And using server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + And using server "LOCAL" + Then the OCS status code of responses on all endpoints should be "403" + And the HTTP status code of responses on each endpoint should be "" respectively + And user "Brian" should not have any pending federated cloud share + And as "Brian" file "/newFile" should not exist + Examples: + | ocs-api-version | http-status-code | + | 1 | 201, 200 | + | 2 | 201, 403 | + + + Scenario Outline: Both Incoming and outgoing federation shares are restricted + Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no" + And using OCS API version "" + When user "Brian" uploads file with content "thisContentIsVisible" to "/file-to-share" using the WebDAV API + And user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API + And using server "REMOTE" + Then the OCS status code should be "403" + And the HTTP status code of responses on each endpoint should be "" respectively + And user "Alice" should not have any pending federated cloud share + And as "Alice" file "/file-to-share" should not exist + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + And using server "LOCAL" + Then the OCS status code should be "403" + And the HTTP status code of responses on each endpoint should be "" respectively + And user "Brian" should not have any pending federated cloud share + And as "Brian" file "/newFile" should not exist + Examples: + | ocs-api-version | http-status-code | + | 1 | 201, 200 | + | 2 | 201, 403 | + + + Scenario Outline: Incoming and outgoing federation shares are enabled for local server but incoming federation shares are restricted for remote server + Given using server "REMOTE" + And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And using server "LOCAL" + And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And using OCS API version "" + When user "Brian" uploads file with content "thisContentIsVisible" to "/file-to-share" using the WebDAV API + And user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API + And using server "REMOTE" + Then the OCS status code should be "403" + And the HTTP status code of responses on each endpoint should be "" respectively + And user "Alice" should not have any pending federated cloud share + And as "Alice" file "/file-to-share" should not exist + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + Then the OCS status code should be "" + And the HTTP status code of responses on each endpoint should be "201, 200" respectively + And using server "LOCAL" + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + Then as "Brian" file "/newFile" should exist + Examples: + | ocs-api-version | ocs-status-code | http-status-code | + | 1 | 100 | 201, 200 | + | 2 | 200 | 201, 403 | + + + Scenario Outline: Incoming and outgoing federation shares are enabled for local server but outgoing federation shares are restricted for remote server + Given using server "REMOTE" + And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no" + And using server "LOCAL" + And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And using OCS API version "" + When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API + And using server "REMOTE" + And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And as "Alice" file "/file-to-share" should exist + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + And using server "LOCAL" + Then the OCS status code should be "403" + And the HTTP status code of responses on each endpoint should be "" respectively + And user "Brian" should not have any pending federated cloud share + And as "Brian" file "/newFile" should not exist + Examples: + | ocs-api-version | ocs-status-code | http-status-code | + | 1 | 100 | 201, 200 | + | 2 | 200 | 201, 403 | + + + Scenario Outline: Federated share a file with another server with expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + When user "Brian" from server "LOCAL" shares "/textfile1.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | id | A_NUMBER | + | item_type | file | + | item_source | A_NUMBER | + | share_type | federated | + | file_source | A_NUMBER | + | path | /textfile1.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_NUMBER | + | mail_send | 0 | + | uid_owner | %username% | + | file_parent | A_NUMBER | + | displayname_owner | %displayname% | + | share_with | %username%@REMOTE | + | share_with_displayname | %username%@REMOTE | + | expiration | +7 days | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharing with default expiration date enabled but not enforced, user shares without specifying expireDate + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | expiration | | + Examples: + | ocs_api_version | ocs-status | + | 1 | 100 | +# | 2 | 200 | + + + Scenario Outline: Federated sharing with default expiration date enabled and enforced, user shares without specifying expireDate + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | expiration | +7days | + Examples: + | ocs_api_version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharing with default expiration date disabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "no" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | expiration | | + Examples: + | ocs_api_version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Expiration date is enforced for federated share, user modifies expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + And user "Brian" updates the last share using the sharing API with + | expireDate | +3 days | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | expiration | +3 days | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharing with default expiration date enabled and enforced, user shares with expiration date more than the default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + And user "Brian" updates the last share using the sharing API with + | expireDate | +10 days | + Then the OCS status code should be "404" + And the HTTP status code should be "" + + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: User modifies expiration date for federated reshare of a file with another server with default expiration date + Given using OCS API version "" + And using server "LOCAL" + And user "Carol" has been created with default attributes and without skeleton files + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" has shared file "/textfile0.txt" with user "Carol" with permissions "read,update,share" + When user "Carol" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + And user "Carol" updates the last share using the sharing API with + | expireDate | +3 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Carol" sharing with user "Alice" should include + | expiration | +3 days | + + Examples: + | ocs_api_version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User modifies expiration date more than the default for federated reshare of a file + Given using OCS API version "" + And using server "LOCAL" + And user "Carol" has been created with default attributes and without skeleton files + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" has shared file "/textfile0.txt" with user "Carol" with permissions "read,update,share" + When user "Carol" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + And user "Carol" updates the last share using the sharing API with + | expireDate | +10 days | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And the information of the last share of user "Carol" should include + | expiration | +7 days | + + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @skipOnFedOcV10.7 @skipOnFedOcV10.6 + Scenario: set a federated user share to expire yesterday and verify that it is not accessible + Given using OCS API version "2" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" with expiry date of "+5 days" + And the administrator has expired the last created share using the testing API + And using server "LOCAL" + When user "Brian" gets the info of the last share using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "404" + And user "Brian" should not see the share id of the last share + And as "Brian" file "/textfile0.txt" should not exist + And using server "REMOTE" + And user "Alice" should not see the share id of the last share + And as "Alice" file "/textfile0.txt" should exist diff --git a/tests/acceptance/features/coreApiFederationToRoot2/federatedOc10Issue35839.feature b/tests/acceptance/features/coreApiFederationToRoot2/federatedOc10Issue35839.feature new file mode 100644 index 00000000000..9db6ed73e51 --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToRoot2/federatedOc10Issue35839.feature @@ -0,0 +1,75 @@ +@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 without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And using server "LOCAL" + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + + @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 the OCS status code of responses on each endpoint should be "201, 100" respectively + And the HTTP status code of responses on each endpoint should be "201, 200" respectively + And 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 the OCS status code of responses on each endpoint should be "201, 100" respectively + And the HTTP status code of responses on each endpoint should be "201, 200" respectively + And 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" accepts the last pending share using the sharing API + And using server "LOCAL" + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And 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 the OCS status code should be "100" + And the HTTP status code should be "200" + #Then as "Brian" file "textfile1 (2).txt" should exist + And 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" accepts the last pending share using the sharing API + And using server "LOCAL" + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And 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 + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" file "textfile1 (2).txt" should not exist diff --git a/tests/acceptance/features/coreApiFederationToShares1/etagPropagation.feature b/tests/acceptance/features/coreApiFederationToShares1/etagPropagation.feature new file mode 100644 index 00000000000..84f56851c32 --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToShares1/etagPropagation.feature @@ -0,0 +1,100 @@ +@api @federation-app-required @files_sharing-app-required +Feature: propagation of etags between federated and local server + + Background: + Given using OCS API version "1" + And using server "REMOTE" + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And using server "LOCAL" + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "PARENT" + + Scenario: Overwrite a federated shared folder as sharer propagates etag for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/Shares/PARENT" + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/Shares/PARENT" of user "Alice" on server "REMOTE" should have changed + + @issue-enterprise-2848 + Scenario: Overwrite a federated shared folder as sharer propagates etag to root folder for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/" + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + # After fixing issue-enterprise-2848, change the following step to "should have changed" + And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed + #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + + @issue-enterprise-2848 + Scenario: Adding a file to a federated shared folder as sharer propagates etag to root folder for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/" + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/lorem.txt" to "/PARENT/new-textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + # After fixing issue-enterprise-2848, change the following step to "should have changed" + And the etag of element "/" of user "Alice" on server "REMOTE" should not have changed + #And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + + + Scenario: Overwrite a federated shared folder as recipient propagates etag for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/Shares/PARENT" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/Shares/PARENT" of user "Alice" on server "REMOTE" should have changed + + + Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for recipient + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And user "Alice" has stored etag of element "/" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/" of user "Alice" on server "REMOTE" should have changed + + + Scenario: Overwrite a federated shared folder as recipient propagates etag for sharer + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Brian" has stored etag of element "/PARENT" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/PARENT" of user "Brian" on server "LOCAL" should have changed + + + Scenario: Overwrite a federated shared folder as recipient propagates etag to root folder for sharer + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Brian" has stored etag of element "/" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/" of user "Brian" on server "LOCAL" should have changed + + + Scenario: Adding a file to a federated shared folder as recipient propagates etag to root folder for sharer + Given user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Brian" has stored etag of element "/" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/lorem.txt" to "/Shares/PARENT/new-textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the etag of element "/" of user "Brian" on server "LOCAL" should have changed diff --git a/tests/acceptance/features/coreApiFederationToShares1/federated.feature b/tests/acceptance/features/coreApiFederationToShares1/federated.feature new file mode 100644 index 00000000000..4e2cec91389 --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToShares1/federated.feature @@ -0,0 +1,586 @@ +@api @federation-app-required @files_sharing-app-required +Feature: federated + + Background: + Given using server "REMOTE" + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And using server "LOCAL" + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: Federate share a file with another server + Given using OCS API version "" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | federated | + | file_source | A_STRING | + | path | /textfile0.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | share_with | %username%@REMOTE | + | share_with_displayname | %username%@REMOTE | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: Federate share a file with local server + Given using OCS API version "" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Alice" from server "REMOTE" shares "/textfile0.txt" with user "Brian" from server "LOCAL" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | federated | + | file_source | A_STRING | + | path | /textfile0.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | share_with | %username%@LOCAL | + | share_with_displayname | %username%@LOCAL | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharee can see the pending share + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + And using server "LOCAL" + And using OCS API version "" + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | {{TemporaryMountPointName#/textfile0.txt}} | + | accepted | 0 | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharee requests information of only one share + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + And using OCS API version "" + When user "Brian" retrieves the information of the last federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | /Shares/textfile0.txt | + | accepted | 1 | + | type | file | + | permissions | share,read,update,delete | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharee requests information of only one share before accepting it + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + And using server "LOCAL" + And using OCS API version "" + When user "Brian" retrieves the information of the last pending federated cloud share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | {{TemporaryMountPointName#/textfile0.txt}} | + | accepted | 0 | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sending a GET request to a pending federated share is not valid + Given using OCS API version "" + When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/pending/12" + Then the HTTP status code should be "405" + And the body of the response should be empty + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sending a GET request to a nonexistent federated share + Given using OCS API version "" + When user "Brian" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/remote_shares/9999999999" + Then the OCS status code should be "" + And the HTTP status code should be "" + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 404 | 200 | + | 2 | 404 | 404 | + + + Scenario Outline: accept a pending federated share + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + And using OCS API version "" + When user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Reshare a federated shared file + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + And user "Carol" has been created with default attributes and small skeleton files + And using OCS API version "" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | shareWith | Carol | + | permissions | share,read,update | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Carol" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | user | + | file_source | A_STRING | + | path | /Shares/textfile0.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | share_with | %username% | + | share_with_displayname | %displayname% | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Overwrite a federated shared file as recipient - local server shares - remote server receives + Given user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" from server "LOCAL" has shared "/textfile0.txt" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And using OCS API version "" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textfile0.txt" for user "Brian" on server "LOCAL" should be "BLABLABLA" plus end-of-line + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Overwrite a federated shared file as recipient - remote server shares - local server receives + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + And using OCS API version "" + When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textfile0.txt" for user "Alice" on server "REMOTE" should be "BLABLABLA" plus end-of-line + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Overwrite a file in a federated shared folder as recipient - local server shares - remote server receives + Given user "Brian" has created folder "PARENT" + And user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + And using OCS API version "" + When user "Alice" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/PARENT/textfile0.txt" for user "Brian" on server "LOCAL" should be "BLABLABLA" plus end-of-line + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Overwrite a file in a federated shared folder as recipient - remote server shares - local server receives + Given using server "REMOTE" + And user "Alice" has created folder "PARENT" + And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + And using OCS API version "" + When user "Brian" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/PARENT/textfile0.txt" for user "Alice" on server "REMOTE" should be "BLABLABLA" plus end-of-line + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Overwrite a federated shared file as recipient using old chunking + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + And using OCS API version "" + When user "Brian" uploads the following "3" chunks to "/Shares/textfile0.txt" with old chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And the content of file "/Shares/textfile0.txt" for user "Brian" should be "AAAAABBBBBCCCCC" + And the content of file "/textfile0.txt" for user "Alice" on server "REMOTE" should be "AAAAABBBBBCCCCC" + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Overwrite a file in a federated shared folder as recipient using old chunking + Given using server "REMOTE" + And user "Alice" has created folder "PARENT" + And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + And using OCS API version "" + When user "Brian" uploads the following "3" chunks to "/Shares/PARENT/textfile0.txt" with old chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And the content of file "/Shares/PARENT/textfile0.txt" for user "Brian" should be "AAAAABBBBBCCCCC" + And the content of file "/PARENT/textfile0.txt" for user "Alice" on server "REMOTE" should be "AAAAABBBBBCCCCC" + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharee deletes an accepted federated share + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + And using OCS API version "" + When user "Brian" deletes the last federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should not see the following elements + | /Shares/textfile0.txt | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the response should contain 0 entries + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the response should contain 0 entries + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + @issue-31276 @skipOnOcV10 + Scenario Outline: Federated sharee tries to delete an accepted federated share sending wrong password + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And 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 server "LOCAL" + 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" + And the HTTP status code should be "401" + And user "Brian" should see the following elements + | /Shares/textfile0.txt | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | /Shares/textfile0.txt | + | accepted | 1 | + | type | file | + | permissions | share,delete,update,read | + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the response should contain 0 entries + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Federated sharee deletes a pending federated share + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + And using server "LOCAL" + And using OCS API version "" + When user "Brian" deletes the last pending federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should not see the following elements + | /Shares/textfile0.txt | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the response should contain 0 entries + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the response should contain 0 entries + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + @issue-31276 @skipOnOcV10 + Scenario Outline: Federated sharee tries to delete a pending federated share sending wrong password + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" from server "REMOTE" has shared "/textfile0.txt" with user "Brian" from server "LOCAL" + And using 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" + And the HTTP status code should be "401" + And user "Brian" should not see the following elements + | /Shares/textfile0.txt | + When user "Brian" gets the list of pending federated cloud shares using the sharing API + Then the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /textfile0.txt | + | owner | %username% | + | user | %username% | + | mountpoint | {{TemporaryMountPointName#/textfile0.txt}} | + | accepted | 0 | + When user "Brian" gets the list of federated cloud shares using the sharing API + Then the response should contain 0 entries + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Trusted server handshake does not require authenticated requests - we force 403 by sending an empty body + Given using server "LOCAL" + And using OCS API version "" + When user "UNAUTHORIZED_USER" requests shared secret using the federation API + Then the HTTP status code should be "" + And the OCS status code should be "403" + Examples: + | ocs-api-version | http-status | + | 1 | 200 | + | 2 | 403 | + + @skipOnLDAP + Scenario: Upload file to received federated share while quota is set on home storage + Given using server "REMOTE" + And user "Alice" has created folder "PARENT" + And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/Shares/PARENT/testquota.txt" with all mechanisms using the WebDAV API + Then the HTTP status code of all upload responses should be "201" + And as user "Alice" on server "REMOTE" the files uploaded to "/PARENT/testquota.txt" with all mechanisms should exist + + @skipOnLDAP + Scenario: Upload file to received federated share while quota is set on remote storage - local server shares - remote server receives + Given using server "LOCAL" + And the quota of user "Brian" has been set to "20 B" + And user "Brian" has created folder "PARENT" + And user "Brian" from server "LOCAL" has shared "/PARENT" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using server "REMOTE" + When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/Shares/PARENT/testquota.txt" with all mechanisms using the WebDAV API + Then the HTTP status code of all upload responses should be "507" + + @skipOnLDAP + Scenario: Upload file to received federated share while quota is set on remote storage - remote server shares - local server receives + Given using server "REMOTE" + And the quota of user "Alice" has been set to "20 B" + And user "Alice" has created folder "PARENT" + And user "Alice" from server "REMOTE" has shared "/PARENT" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using server "LOCAL" + When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/Shares/PARENT/testquota.txt" with all mechanisms using the WebDAV API + Then the HTTP status code of all upload responses should be "507" + + + Scenario Outline: share of a folder to a federated user who already has a folder with the same name + Given using server "REMOTE" + And user "Alice" has created folder "/zzzfolder" + And user "Alice" has created folder "zzzfolder/Alice" + And using server "LOCAL" + And user "Brian" has created folder "/zzzfolder" + And user "Brian" has created folder "zzzfolder/Brian" + When user "Alice" from server "REMOTE" shares "zzzfolder" with user "Brian" from server "LOCAL" using the sharing API + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + And user "Brian" retrieves the information of the last federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | name | /zzzfolder | + | owner | %username% | + | user | %username% | + | mountpoint | /Shares/zzzfolder | + | type | dir | + | permissions | all | + And as "Brian" folder "zzzfolder/Brian" should exist + And as "Brian" folder "Shares/zzzfolder/Alice" should exist + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: share of a file to the federated user who already has a file with the same name + Given using server "REMOTE" + And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt" + And using server "LOCAL" + And user "Brian" has uploaded file with content "local content" to "/randomfile.txt" + When user "Alice" from server "REMOTE" shares "/randomfile.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 OCS API version "" + And user "Brian" retrieves the information of the last federated cloud share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response about user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | remote | REMOTE | + | remote_id | A_STRING | + | share_token | A_TOKEN | + | name | /randomfile.txt | + | owner | %username% | + | user | %username% | + | mountpoint | /Shares/randomfile.txt | + | accepted | 1 | + | type | file | + | permissions | share,delete,update,read | + And the content of file "/randomfile.txt" for user "Brian" on server "LOCAL" should be "local content" + And the content of file "/Shares/randomfile.txt" for user "Brian" on server "LOCAL" should be "remote content" + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + @issue-35154 + Scenario: receive a local share that has the same name as a previously received federated share + Given using server "REMOTE" + And user "Alice" has created folder "/zzzfolder" + And user "Alice" has created folder "zzzfolder/remote" + And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt" + And using server "LOCAL" + And user "Carol" has been created with default attributes and small skeleton files + And user "Brian" has created folder "/zzzfolder" + And user "Brian" has created folder "zzzfolder/local" + And user "Brian" has uploaded file with content "local content" to "/randomfile.txt" + And user "Alice" from server "REMOTE" has shared "zzzfolder" with user "Carol" from server "LOCAL" + And user "Alice" from server "REMOTE" has shared "randomfile.txt" with user "Carol" from server "LOCAL" + And user "Brian" has shared folder "zzzfolder" with user "Carol" + And user "Brian" has shared folder "randomfile.txt" with user "Carol" + When user "Carol" from server "LOCAL" accepts the last pending share using the sharing API + And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API + And user "Carol" accepts share "/zzzfolder" offered by user "Brian" using the sharing API + And user "Carol" accepts share "/randomfile.txt" offered by user "Brian" using the sharing API + 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 "100" + # local shares are taking priority at the moment + And as "Carol" folder "/Shares/zzzfolder/remote" should exist + And as "Carol" folder "/Shares/zzzfolder (2)/local" should exist + And the content of file "/Shares/randomfile.txt" for user "Carol" on server "LOCAL" should be "remote content" + And the content of file "/Shares/randomfile (2).txt" for user "Carol" on server "LOCAL" should be "local content" + + + Scenario: receive a federated share that has the same name as a previously received local share + Given using server "REMOTE" + And user "Alice" has created folder "/zzzfolder" + And user "Alice" has created folder "zzzfolder/remote" + And user "Alice" has uploaded file with content "remote content" to "/randomfile.txt" + And using server "LOCAL" + And user "Carol" has been created with default attributes and small skeleton files + And user "Brian" has created folder "/zzzfolder" + And user "Brian" has created folder "zzzfolder/local" + And user "Brian" has uploaded file with content "local content" to "/randomfile.txt" + And user "Brian" has shared folder "zzzfolder" with user "Carol" + And user "Brian" has shared folder "randomfile.txt" with user "Carol" + And user "Alice" from server "REMOTE" has shared "zzzfolder" with user "Carol" from server "LOCAL" + And user "Alice" from server "REMOTE" has shared "randomfile.txt" with user "Carol" from server "LOCAL" + When user "Carol" accepts share "/zzzfolder" offered by user "Brian" using the sharing API + And user "Carol" accepts share "/randomfile.txt" offered by user "Brian" using the sharing API + And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API + And user "Carol" from server "LOCAL" accepts the last pending share using the sharing API + 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 "100" + And as "Carol" folder "Shares/zzzfolder/local" should exist + And as "Carol" folder "Shares/zzzfolder (2)/remote" should exist + And the content of file "/Shares/randomfile.txt" for user "Carol" on server "LOCAL" should be "local content" + And the content of file "/Shares/randomfile (2).txt" for user "Carol" on server "LOCAL" should be "remote content" diff --git a/tests/acceptance/features/coreApiFederationToShares1/savePublicShare.feature b/tests/acceptance/features/coreApiFederationToShares1/savePublicShare.feature new file mode 100644 index 00000000000..3d7c5063c30 --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToShares1/savePublicShare.feature @@ -0,0 +1,131 @@ +@api @federation-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: Save public shares created by oC users + + Background: + Given using server "LOCAL" + And the administrator has set the default folder for received shares to "Shares" + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario: Mount public share created from local server + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/lorem.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When user "Brian" adds the public share created from server "LOCAL" using the sharing API + Then the HTTP status code should be "200" + And as "Brian" folder "/Shares/PARENT" should exist + And as "Brian" file "/Shares/PARENT/lorem.txt" should exist + + + Scenario: Mount public share and then delete (local server share) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read | + And user "Brian" has added the public share created from server "LOCAL" using the sharing API + When user "Brian" deletes folder "/Shares/PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" folder "/Shares/PARENT" should not exist + + + Scenario: Mount public share and sharer unshares the share (local server share) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read | + | name | sharedlink | + And user "Brian" has added the public share created from server "LOCAL" using the sharing API + When user "Alice" deletes public link share named "sharedlink" in file "/PARENT" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And as "Brian" folder "/Shares/PARENT" should not exist + + + Scenario Outline: Mount public share and try to reshare (local server share) + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + And user "Brian" has added the public share created from server "LOCAL" using the sharing API + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/PARENT | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario: Mount public share created from remote server + Given using server "REMOTE" + And user "RemoteAlice" has been created with default attributes and without skeleton files + And user "RemoteAlice" has created folder "/PARENT" + And user "RemoteAlice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/lorem.txt" + And user "RemoteAlice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + And using server "LOCAL" + When user "Alice" adds the public share created from server "REMOTE" using the sharing API + Then the HTTP status code should be "200" + And as "Alice" folder "/Shares/PARENT" should exist + And as "Alice" file "/Shares/PARENT/lorem.txt" should exist + + + Scenario: Mount public share and then delete (remote server share) + Given using server "REMOTE" + And user "RemoteAlice" has been created with default attributes and without skeleton files + And user "RemoteAlice" has created folder "/PARENT" + And user "RemoteAlice" has created a public link share with settings + | path | /PARENT | + | permissions | read | + And using server "LOCAL" + And user "Alice" has added the public share created from server "REMOTE" using the sharing API + When user "Alice" deletes folder "/Shares/PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/Shares/PARENT" should not exist + + + Scenario: Mount public share and sharer unshares the share (remote server share) + Given using server "REMOTE" + And user "RemoteAlice" has been created with default attributes and without skeleton files + And user "RemoteAlice" has created folder "/PARENT" + And user "RemoteAlice" has created a public link share with settings + | path | /PARENT | + | permissions | read | + | name | sharedlink | + And using server "LOCAL" + And user "Alice" has added the public share created from server "REMOTE" using the sharing API + And using server "REMOTE" + When user "RemoteAlice" deletes public link share named "sharedlink" in file "/PARENT" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + When using server "LOCAL" + Then as "Alice" folder "/Shares/PARENT" should not exist + + + Scenario Outline: Mount public share and try to reshare (remote server share) + Given using OCS API version "" + And using server "REMOTE" + And user "RemoteAlice" has been created with default attributes and without skeleton files + And user "RemoteAlice" has created folder "/PARENT" + And user "RemoteAlice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + And using server "LOCAL" + And user "Alice" has added the public share created from server "REMOTE" using the sharing API + When user "Alice" creates a public link share using the sharing API with settings + | path | /Shares/PARENT | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | diff --git a/tests/acceptance/features/coreApiFederationToShares2/federated.feature b/tests/acceptance/features/coreApiFederationToShares2/federated.feature new file mode 100644 index 00000000000..fe4ecd8a08f --- /dev/null +++ b/tests/acceptance/features/coreApiFederationToShares2/federated.feature @@ -0,0 +1,761 @@ +@api @federation-app-required @files_sharing-app-required +Feature: federated + + Background: + Given using server "REMOTE" + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And using server "LOCAL" + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + + + Scenario: "Auto accept from trusted servers" enabled with remote server + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And using server "LOCAL" + And the trusted server list is cleared + 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 + Then the OCS status code should be "100" + And the HTTP status code of responses on each endpoint should be "201, 200" respectively + When using server "LOCAL" + Then as "Brian" file "Shares/textfile1.txt" should exist + And url "%remote_server%" should be a trusted server + + + Scenario: "Auto accept from trusted servers" disabled with remote server + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And the trusted server list is cleared + And using server "LOCAL" + 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 + Then the OCS status code should be "100" + And the HTTP status code of responses on each endpoint should be "201, 200" respectively + When using server "LOCAL" + Then as "Brian" file "Shares/textfile1.txt" should not exist + And url "%remote_server%" should be a trusted server + + + Scenario: Federated share with "Auto add server" enabled + Given the trusted server list is cleared + And using server "LOCAL" + And parameter "autoAddServers" of app "federation" has been set to "1" + And using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + 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 "100" + When using server "LOCAL" + Then as "Brian" file "Shares/textfile1.txt" should exist + And url "%remote_server%" should be a trusted server + + + Scenario: Federated share with "Auto add server" disabled + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And using server "LOCAL" + And the trusted server list is cleared + And parameter "autoAddServers" of app "federation" has been set to "0" + When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + 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 "100" + When using server "LOCAL" + Then as "Brian" file "Shares/textfile1.txt" should exist + And url "%remote_server%" should not be a trusted server + + @issue-35839 @skipOnOcV10 + Scenario: enable "Add server automatically" once a federated share was created successfully + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And using server "LOCAL" + 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" accepts the last pending share using the sharing API + 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 "100" + When 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 the HTTP status code should be "200" + And the OCS status code should be "100" + Then as "Brian" file "Shares/textfile1.txt" should exist + + + Scenario: disable "Add server automatically" once a federated share was created successfully + Given using server "REMOTE" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And 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" accepts the last pending share using the sharing API + 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 "100" + When using server "LOCAL" + Then url "%remote_server%" should not be a trusted server + When user "Alice" from server "REMOTE" shares "/textfile1.txt" with user "Brian" from server "LOCAL" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And as "Brian" file "Shares/textfile1.txt" should not exist + + + Scenario Outline: federated share receiver sees the original content of a received file + Given using server "REMOTE" + And user "Alice" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And user "Alice" from server "REMOTE" has shared "file-to-share" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + When using server "LOCAL" + Then the content of file "/Shares/file-to-share" for user "Brian" should be "thisContentIsVisible" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: federated share receiver sees the original content of a received file in multiple levels of folders + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has uploaded file with content "thisContentIsVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder/file-to-share" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + When using server "LOCAL" + Then the content of file "/Shares/file-to-share" for user "Brian" should be "thisContentIsVisible" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: remote federated share receiver adds files/folders in the federated share + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + And using server "REMOTE" + When user "Alice" uploads file with content "thisContentIsFinal" to "/Shares/RandomFolder/new-file" using the WebDAV API + And user "Alice" creates folder "/Shares/RandomFolder/sub-folder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be 201 + When using server "LOCAL" + Then as "Brian" file "/PARENT/RandomFolder/new-file" should exist + And as "Brian" file "/PARENT/RandomFolder/file-to-share" should exist + And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should exist + And the content of file "/PARENT/RandomFolder/new-file" for user "Brian" should be "thisContentIsFinal" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: local federated share receiver adds files/folders in the federated share + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + And using server "LOCAL" + When user "Brian" uploads file with content "thisContentIsFinal" to "/Shares/RandomFolder/new-file" using the WebDAV API + And user "Brian" creates folder "/Shares/RandomFolder/sub-folder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be 201 + When using server "REMOTE" + Then as "Alice" file "/PARENT/RandomFolder/new-file" should exist + And as "Alice" file "/PARENT/RandomFolder/file-to-share" should exist + And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should exist + And the content of file "/PARENT/RandomFolder/new-file" for user "Alice" should be "thisContentIsFinal" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: local federated share receiver deletes files/folders of the received share + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + And using server "LOCAL" + When user "Brian" deletes folder "/Shares/RandomFolder/sub-folder" using the WebDAV API + And user "Brian" deletes file "/Shares/RandomFolder/file-to-share" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be 204 + When using server "REMOTE" + Then as "Alice" file "/PARENT/RandomFolder/file-to-share" should not exist + And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should not exist + But as "Alice" folder "/PARENT/RandomFolder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: remote federated share receiver deletes files/folders of the received share + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + And using server "REMOTE" + When user "Alice" deletes folder "/Shares/RandomFolder/sub-folder" using the WebDAV API + And user "Alice" deletes file "/Shares/RandomFolder/file-to-share" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be 204 + When using server "LOCAL" + Then as "Brian" file "/PARENT/RandomFolder/file-to-share" should not exist + And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should not exist + But as "Brian" folder "/PARENT/RandomFolder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: local federated share receiver renames files/folders of the received share + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" with user "Brian" from server "LOCAL" + And user "Brian" from server "LOCAL" has accepted the last pending share + And using OCS API version "" + And using server "LOCAL" + When user "Brian" moves folder "/Shares/RandomFolder/sub-folder" to "/Shares/RandomFolder/renamed-sub-folder" using the WebDAV API + And user "Brian" moves file "/Shares/RandomFolder/file-to-share" to "/Shares/RandomFolder/renamedFile" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be 201 + When using server "REMOTE" + Then as "Alice" file "/PARENT/RandomFolder/file-to-share" should not exist + But as "Alice" file "/PARENT/RandomFolder/renamedFile" should exist + And the content of file "/PARENT/RandomFolder/renamedFile" for user "Alice" should be "thisContentShouldBeVisible" + And as "Alice" folder "/PARENT/RandomFolder/sub-folder" should not exist + But as "Alice" folder "/PARENT/RandomFolder/renamed-sub-folder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: remote federated share receiver renames files/folders of the received share + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + And using server "REMOTE" + When user "Alice" moves folder "/Shares/RandomFolder/sub-folder" to "/Shares/RandomFolder/renamed-sub-folder" using the WebDAV API + And user "Alice" moves file "/Shares/RandomFolder/file-to-share" to "/Shares/RandomFolder/renamedFile" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be 201 + When using server "LOCAL" + Then as "Brian" file "/PARENT/RandomFolder/file-to-share" should not exist + But as "Brian" file "/PARENT/RandomFolder/renamedFile" should exist + And the content of file "/PARENT/RandomFolder/renamedFile" for user "Brian" should be "thisContentShouldBeVisible" + And as "Brian" folder "/PARENT/RandomFolder/sub-folder" should not exist + But as "Brian" folder "/PARENT/RandomFolder/renamed-sub-folder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer modifies the share which was shared to the federated share receiver + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has uploaded file with content "thisContentShouldBeChanged" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder/file-to-share" 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 "Alice" uploads file with content "thisContentIsFinal" to "/PARENT/RandomFolder/file-to-share" using the WebDAV API + Then the HTTP status code should be "204" + When using server "LOCAL" + Then the content of file "/Shares/file-to-share" for user "Brian" should be "thisContentIsFinal" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer adds files/folders in the share which was shared to the federated share receiver + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" 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 "Alice" uploads file with content "thisContentIsFinal" to "/PARENT/RandomFolder/new-file" using the WebDAV API + And user "Alice" creates folder "/PARENT/RandomFolder/sub-folder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be 201 + When using server "LOCAL" + Then as "Brian" file "/Shares/RandomFolder/new-file" should exist + And as "Brian" file "/Shares/RandomFolder/file-to-share" should exist + And as "Brian" folder "/Shares/RandomFolder/sub-folder" should exist + And the content of file "/Shares/RandomFolder/new-file" for user "Brian" should be "thisContentIsFinal" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer deletes files/folders of the share which was shared to the federated share receiver + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" 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 "Alice" deletes folder "/PARENT/RandomFolder/sub-folder" using the WebDAV API + And user "Alice" deletes file "/PARENT/RandomFolder/file-to-share" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be 204 + When using server "LOCAL" + Then as "Brian" file "/Shares/RandomFolder/file-to-share" should not exist + And as "Brian" folder "/Shares/RandomFolder/sub-folder" should not exist + But as "Brian" folder "/Shares/RandomFolder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer renames files/folders of the share which was shared to the federated share receiver + Given using server "REMOTE" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/RandomFolder" + And user "Alice" has created folder "/PARENT/RandomFolder/sub-folder" + And user "Alice" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Alice" from server "REMOTE" has shared "/PARENT/RandomFolder" 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 "Alice" moves folder "/PARENT/RandomFolder/sub-folder" to "/PARENT/RandomFolder/renamed-sub-folder" using the WebDAV API + And user "Alice" moves file "/PARENT/RandomFolder/file-to-share" to "/PARENT/RandomFolder/renamedFile" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be 201 + When using server "LOCAL" + Then as "Brian" file "/Shares/RandomFolder/file-to-share" should not exist + But as "Brian" file "/Shares/RandomFolder/renamedFile" should exist + And the content of file "/Shares/RandomFolder/renamedFile" for user "Brian" should be "thisContentShouldBeVisible" + And as "Brian" folder "/Shares/RandomFolder/sub-folder" should not exist + But as "Brian" folder "/Shares/RandomFolder/renamed-sub-folder" should exist + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: sharer unshares the federated share and the receiver no longer sees the files/folders + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has uploaded file with content "thisContentShouldBeVisible" to "/PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + When user "Brian" deletes the last share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + When using server "REMOTE" + Then as "Alice" file "/Shares/RandomFolder/file-to-share" should not exist + And as "Alice" folder "/Shares/RandomFolder" should not exist + Examples: + | ocs-api-version | ocs-status-code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: federated share receiver can move the location of the received share and changes are correctly seen at both ends + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + And using server "REMOTE" + When user "Alice" creates folder "/CHILD" using the WebDAV API + And user "Alice" creates folder "/CHILD/newRandomFolder" using the WebDAV API + And user "Alice" moves folder "/Shares/RandomFolder" to "/CHILD/newRandomFolder/RandomFolder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" file "/CHILD/newRandomFolder/RandomFolder/file-to-share" should exist + When using server "LOCAL" + Then as "Brian" file "/PARENT/RandomFolder/file-to-share" should exist + When user "Brian" uploads file with content "thisIsTheContentOfNewFile" to "/PARENT/RandomFolder/newFile" using the WebDAV API + And user "Brian" uploads file with content "theContentIsChanged" to "/PARENT/RandomFolder/file-to-share" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 204" respectively + When using server "REMOTE" + Then as "Alice" file "/CHILD/newRandomFolder/RandomFolder/newFile" should exist + And the content of file "/CHILD/newRandomFolder/RandomFolder/file-to-share" for user "Alice" should be "theContentIsChanged" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: federated sharer can move the location of the received share and changes are correctly seen at both ends + Given user "Brian" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT/RandomFolder" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "PARENT/RandomFolder/file-to-share" + And user "Brian" from server "LOCAL" has shared "/PARENT/RandomFolder" with user "Alice" from server "REMOTE" + And user "Alice" from server "REMOTE" has accepted the last pending share + And using OCS API version "" + When user "Brian" creates folder "/CHILD" using the WebDAV API + And user "Brian" creates folder "/CHILD/newRandomFolder" using the WebDAV API + And user "Brian" moves folder "PARENT/RandomFolder" to "/CHILD/newRandomFolder/RandomFolder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And as "Brian" file "/CHILD/newRandomFolder/RandomFolder/file-to-share" should exist + When using server "REMOTE" + Then as "Alice" file "/Shares/RandomFolder/file-to-share" should exist + When user "Alice" uploads file with content "thisIsTheContentOfNewFile" to "/Shares/RandomFolder/newFile" using the WebDAV API + And user "Alice" uploads file with content "theContentIsChanged" to "/Shares/RandomFolder/file-to-share" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 204" respectively + When using server "LOCAL" + Then as "Brian" file "/CHILD/newRandomFolder/RandomFolder/newFile" should exist + And the content of file "/CHILD/newRandomFolder/RandomFolder/file-to-share" for user "Brian" should be "theContentIsChanged" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + + Scenario Outline: Both Incoming and Outgoing federation shares are allowed + Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And using OCS API version "" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + When user "Brian" from server "LOCAL" shares "file-to-share" with user "Alice" from server "REMOTE" using the sharing API + And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API + 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 "" + When using server "REMOTE" + Then as "Alice" file "/Shares/file-to-share" should exist + And the content of file "/Shares/file-to-share" for user "Alice" should be "thisContentIsVisible" + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + Then the HTTP status code of responses on each endpoint should be "201, 200" respectively + And the OCS status code of responses on each endpoint should be "" respectively + And using server "LOCAL" + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + Then as "Brian" file "/Shares/newFile" should exist + And the content of file "/Shares/newFile" for user "Brian" should be "thisFileIsShared" + Examples: + | ocs-api-version | ocs-status-code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Incoming federation shares are allowed but outgoing federation shares are restricted + Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And using OCS API version "" + When user "Brian" from server "LOCAL" shares "file-to-share" with user "Alice" from server "REMOTE" using the sharing API + Then the HTTP status code should be "" + And the OCS status code should be "403" + When using server "REMOTE" + Then user "Alice" should not have any pending federated cloud share + And as "Alice" file "/Shares/file-to-share" should not exist + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + Then the HTTP status code of responses on each endpoint should be "201, 200" respectively + And the OCS status code of responses on each endpoint should be "" respectively + When using server "LOCAL" + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And as "Brian" file "/Shares/newFile" should exist + Examples: + | ocs-api-version | ocs-status-code | http-status-code | + | 1 | 100 | 200 | + | 2 | 200 | 403 | + + + Scenario Outline: Incoming federation shares are restricted but outgoing federation shares are allowed + Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And using OCS API version "" + When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + When using server "REMOTE" + And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And as "Alice" file "/Shares/file-to-share" should exist + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + Then the HTTP status code of responses on each endpoint should be "" respectively + And the OCS status code of responses on each endpoint should be "403" respectively + When using server "LOCAL" + Then user "Brian" should not have any pending federated cloud share + And as "Brian" file "/Shares/newFile" should not exist + Examples: + | ocs-api-version | ocs-status-code | http-status-code | + | 1 | 100 | 201,200 | + | 2 | 200 | 201,403 | + + + Scenario Outline: Both Incoming and outgoing federation shares are restricted + Given parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And using OCS API version "" + When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API + Then the HTTP status code should be "" + And the OCS status code should be "403" + When using server "REMOTE" + Then user "Alice" should not have any pending federated cloud share + And as "Alice" file "/Shares/file-to-share" should not exist + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + Then the HTTP status code of responses on each endpoint should be "201," respectively + And the OCS status code of responses on each endpoint should be "403" respectively + When using server "LOCAL" + Then user "Brian" should not have any pending federated cloud share + And as "Brian" file "/Shares/newFile" should not exist + Examples: + | ocs-api-version | http-status-code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: Incoming and outgoing federation shares are enabled for local server but incoming federation shares are restricted for remote server + Given using server "REMOTE" + And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "no" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And using server "LOCAL" + And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And using OCS API version "" + When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API + Then the HTTP status code should be "" + And the OCS status code should be "403" + When using server "REMOTE" + Then user "Alice" should not have any pending federated cloud share + And as "Alice" file "/Shares/file-to-share" should not exist + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + Then the HTTP status code of responses on each endpoint should be "201,200" respectively + And the OCS status code of responses on each endpoint should be "" respectively + When using server "LOCAL" + And user "Brian" from server "LOCAL" accepts the last pending share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And as "Brian" file "/Shares/newFile" should exist + Examples: + | ocs-api-version | ocs-status-code | http-status-code | + | 1 | 100 | 200 | + | 2 | 200 | 403 | + + + Scenario Outline: Incoming and outgoing federation shares are enabled for local server but outgoing federation shares are restricted for remote server + Given using server "REMOTE" + And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "no" + And using server "LOCAL" + And parameter "incoming_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And parameter "outgoing_server2server_share_enabled" of app "files_sharing" has been set to "yes" + And user "Brian" has uploaded file with content "thisContentIsVisible" to "/file-to-share" + And using OCS API version "" + When user "Brian" from server "LOCAL" shares "/file-to-share" with user "Alice" from server "REMOTE" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + When using server "REMOTE" + And user "Alice" from server "REMOTE" accepts the last pending share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And as "Alice" file "/Shares/file-to-share" should exist + When user "Alice" uploads file with content "thisFileIsShared" to "/newFile" using the WebDAV API + And user "Alice" from server "REMOTE" shares "/newFile" with user "Brian" from server "LOCAL" using the sharing API + Then the HTTP status code of responses on each endpoint should be "" respectively + And the OCS status code of responses on each endpoint should be "403" respectively + When using server "LOCAL" + Then user "Brian" should not have any pending federated cloud share + And as "Brian" file "/Shares/newFile" should not exist + Examples: + | ocs-api-version | ocs-status-code | http-status-code | + | 1 | 100 | 201,200 | + | 2 | 200 | 201,403 | + + + Scenario Outline: Federated share a file with another server with expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | id | A_NUMBER | + | item_type | file | + | item_source | A_NUMBER | + | share_type | federated | + | file_source | A_NUMBER | + | path | /textfile0.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_NUMBER | + | mail_send | 0 | + | uid_owner | %username% | + | file_parent | A_NUMBER | + | displayname_owner | %displayname% | + | share_with | %username%@REMOTE | + | share_with_displayname | %username%@REMOTE | + | expiration | +7 days | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharing with default expiration date enabled but not enforced, user shares without specifying expireDate + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | expiration | | + Examples: + | ocs_api_version | ocs-status | + | 1 | 100 | +# | 2 | 200 | + + + Scenario Outline: Federated sharing with default expiration date enabled and enforced, user shares without specifying expireDate + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | expiration | +7days | + Examples: + | ocs_api_version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharing with default expiration date disabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "no" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Brian" from server "LOCAL" shares "/textfile0.txt" with user "Alice" from server "REMOTE" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | expiration | | + Examples: + | ocs_api_version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Expiration date is enforced for federated share, user modifies expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Brian" from server "LOCAL" has shared "/textfile0.txt" with user "Alice" from server "REMOTE" + When user "Brian" updates the last share using the sharing API with + | expireDate | +3 days | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Alice" should include + | expiration | +3 days | + Examples: + | ocs-api-version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Federated sharing with default expiration date enabled and enforced, user updates the share with expiration date more than the default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Brian" from server "LOCAL" has shared "/textfile0.txt" with user "Alice" from server "REMOTE" + When user "Brian" updates the last share using the sharing API with + | expireDate | +10 days | + Then the OCS status code should be "404" + And the HTTP status code should be "" + + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: User modifies expiration date for federated reshare of a file with another server with default expiration date + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Brian" has shared file "/textfile0.txt" with user "Carol" with permissions "read,update,share" + And user "Carol" has accepted share "/textfile0.txt" offered by user "Brian" + And user "Carol" from server "LOCAL" has shared "/Shares/textfile0.txt" with user "Alice" from server "REMOTE" + When user "Carol" updates the last share using the sharing API with + | expireDate | +3 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Carol" sharing with user "Alice" should include + | expiration | +3 days | + + Examples: + | ocs_api_version | ocs-status | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User modifies expiration date more than the default for federated reshare of a file + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And parameter "shareapi_default_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_remote_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_remote_share" of app "core" has been set to "7" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Brian" has shared file "/textfile0.txt" with user "Carol" with permissions "read,update,share" + And user "Carol" has accepted share "/textfile0.txt" offered by user "Brian" + And user "Carol" from server "LOCAL" has shared "/Shares/textfile0.txt" with user "Alice" from server "REMOTE" + When user "Carol" updates the last share using the sharing API with + | expireDate | +10 days | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And the information of the last share of user "Carol" should include + | expiration | +7 days | + + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | diff --git a/tests/acceptance/features/coreApiMain/appManagement.feature b/tests/acceptance/features/coreApiMain/appManagement.feature new file mode 100644 index 00000000000..72bc31d8e19 --- /dev/null +++ b/tests/acceptance/features/coreApiMain/appManagement.feature @@ -0,0 +1,61 @@ +@api @skipOnLDAP @notToImplementOnOCIS +Feature: AppManagement + + Scenario: Update of patch version of an app + Given these apps' path has been configured additionally with following attributes: + | dir | is_writable | + | apps-custom | true | + And app "updatetest" with version "2.0.0" has been put in dir "apps" + And app "updatetest" has been enabled + And app "updatetest" has been disabled + When the administrator puts app "updatetest" with version "2.0.1" in dir "apps" + And the administrator enables app "updatetest" + Then the installed version of "updatetest" should be "2.0.1" + + + Scenario: Update of patch version of an app in apps-external, previous version in apps folder + Given these apps' path has been configured additionally with following attributes: + | dir | is_writable | + | apps-custom | true | + And app "updatetest" with version "2.0.0" has been put in dir "apps" + And app "updatetest" has been enabled + And app "updatetest" has been disabled + When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-external" + And the administrator enables app "updatetest" + Then the installed version of "updatetest" should be "2.0.1" + + + Scenario: Update of patch version of an app in apps-external + Given these apps' path has been configured additionally with following attributes: + | dir | is_writable | + | apps-custom | true | + And app "updatetest" with version "2.0.0" has been put in dir "apps-external" + And app "updatetest" has been enabled + And app "updatetest" has been disabled + When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-external" + And the administrator enables app "updatetest" + Then the installed version of "updatetest" should be "2.0.1" + + + Scenario: Update of patch version of an app but update is put in alternative folder + Given these apps' path has been configured additionally with following attributes: + | dir | is_writable | + | apps-custom | true | + And app "updatetest" with version "2.0.0" has been put in dir "apps" + And app "updatetest" has been enabled + And app "updatetest" has been disabled + When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-custom" + And the administrator enables app "updatetest" + Then the installed version of "updatetest" should be "2.0.1" + + + Scenario: Update of patch version of an app previously in apps-external but update is put in alternative folder + Given these apps' path has been configured additionally with following attributes: + | dir | is_writable | + | apps-custom | true | + And app "updatetest" with version "2.0.0" has been put in dir "apps-external" + And app "updatetest" has been enabled + And app "updatetest" has been disabled + When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-custom" + And the administrator enables app "updatetest" + Then the installed version of "updatetest" should be "2.0.1" diff --git a/tests/acceptance/features/coreApiMain/caldav.feature b/tests/acceptance/features/coreApiMain/caldav.feature new file mode 100644 index 00000000000..aabfd038b99 --- /dev/null +++ b/tests/acceptance/features/coreApiMain/caldav.feature @@ -0,0 +1,33 @@ +@api +Feature: caldav + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @caldav + Scenario: Accessing a nonexistent calendar of another user + When the administrator requests calendar "%username%/MyCalendar" of user "Alice" using the new WebDAV API + Then the CalDAV HTTP status code should be "404" + And the CalDAV exception should be "Sabre\DAV\Exception\NotFound" + And the CalDAV message should be "Node with name 'MyCalendar' could not be found" + + @caldav + Scenario: Accessing a not shared calendar of another user + Given the administrator has successfully created a calendar named "MyCalendar" + When user "Alice" requests calendar "%username%/MyCalendar" of user "admin" using the new WebDAV API + Then the CalDAV HTTP status code should be "404" + And the CalDAV exception should be "Sabre\DAV\Exception\NotFound" + And the CalDAV message should be "Node with name 'MyCalendar' could not be found" + + @caldav + Scenario: Accessing a nonexistent calendar of myself + When user "Alice" requests calendar "%username%/MyCalendar" of user "admin" using the new WebDAV API + Then the CalDAV HTTP status code should be "404" + And the CalDAV exception should be "Sabre\DAV\Exception\NotFound" + And the CalDAV message should be "Node with name 'MyCalendar' could not be found" + + @caldav @smokeTest + Scenario: Creating a new calendar + Given user "Alice" has successfully created a calendar named "MyCalendar" + When user "Alice" requests calendar "%username%/MyCalendar" of user "Alice" using the new WebDAV API + Then the CalDAV HTTP status code should be "200" diff --git a/tests/acceptance/features/coreApiMain/carddav.feature b/tests/acceptance/features/coreApiMain/carddav.feature new file mode 100644 index 00000000000..8765e3a10e1 --- /dev/null +++ b/tests/acceptance/features/coreApiMain/carddav.feature @@ -0,0 +1,33 @@ +@api +Feature: carddav + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @carddav + Scenario: Accessing a nonexistent addressbook of another user + When the administrator requests address book "%username%/MyAddressbook" of user "Alice" using the new WebDAV API + Then the CardDAV HTTP status code should be "404" + And the CardDAV exception should be "Sabre\DAV\Exception\NotFound" + And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found" + + @carddav + Scenario: Accessing a not shared addressbook of another user + Given the administrator has successfully created an address book named "MyAddressbook" + When user "Alice" requests address book "%username%/MyAddressbook" of user "admin" using the new WebDAV API + Then the CardDAV HTTP status code should be "404" + And the CardDAV exception should be "Sabre\DAV\Exception\NotFound" + And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found" + + @carddav + Scenario: Accessing a nonexistent addressbook of myself + When user "Alice" requests address book "%username%/MyAddressbook" of user "admin" using the new WebDAV API + Then the CardDAV HTTP status code should be "404" + And the CardDAV exception should be "Sabre\DAV\Exception\NotFound" + And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found" + + @carddav @smokeTest + Scenario: Creating a new addressbook + Given user "Alice" has successfully created an address book named "MyAddressbook" + When user "Alice" requests address book "%username%/MyAddressbook" of user "Alice" using the new WebDAV API + Then the CardDAV HTTP status code should be "200" diff --git a/tests/acceptance/features/coreApiMain/checksums-TestOc10Issue38835.feature b/tests/acceptance/features/coreApiMain/checksums-TestOc10Issue38835.feature new file mode 100644 index 00000000000..a09875b9fa7 --- /dev/null +++ b/tests/acceptance/features/coreApiMain/checksums-TestOc10Issue38835.feature @@ -0,0 +1,21 @@ +@api @notToImplementOnOCIS +Feature: checksums + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + # this is a bug demo scenario for https://github.com/owncloud/core/issues/38835 + # Once this scenario is fixed Delete this file and remove @skipOnOcV10 tag from tests/acceptance/features/apiMain/checksums.feature:132 + @files_sharing-app-required @skipOnStorage:ceph @skipOnStorage:scality + Scenario: Sharing and modifying a file should return correct checksum in the propfind using new DAV path + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using new DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + And user "Alice" has shared file "/myChecksumFile.txt" with user "Brian" + And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice" + And user "Brian" has uploaded file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/Shares/myChecksumFile.txt" + When user "Brian" requests the checksum of "/Shares/myChecksumFile.txt" via propfind + Then the HTTP status code should be "207" + And the webdav checksum should be empty diff --git a/tests/acceptance/features/coreApiMain/checksums.feature b/tests/acceptance/features/coreApiMain/checksums.feature new file mode 100644 index 00000000000..89fca532536 --- /dev/null +++ b/tests/acceptance/features/coreApiMain/checksums.feature @@ -0,0 +1,485 @@ +@api +Feature: checksums + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + Scenario Outline: Uploading a file with checksum should work + Given using DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API + Then the HTTP status code should be "201" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest @issue-ocis-reva-196 + Scenario Outline: Uploading a file with checksum should return the checksum in the propfind + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + When user "Alice" requests the checksum of "/myChecksumFile.txt" via propfind + Then the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest @issue-ocis-reva-98 + Scenario Outline: Uploading a file with checksum should return the checksum in the download header + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + When user "Alice" downloads file "/myChecksumFile.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the header checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-196 + Scenario Outline: Moving a file with checksum should return the checksum in the propfind + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + When user "Alice" moves file "/myChecksumFile.txt" to "/myMovedChecksumFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as user "Alice" the webdav checksum of "/myMovedChecksumFile.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-98 + Scenario Outline: Downloading a file with checksum should return the checksum in the download header + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + And user "Alice" has moved file "/myChecksumFile.txt" to "/myMovedChecksumFile.txt" + When user "Alice" downloads file "/myMovedChecksumFile.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the header checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-196 + Scenario Outline: Uploading a chunked file with checksum should return the checksum in the propfind + Given using DAV path + And user "Alice" has uploaded chunk file "1" of "3" with "AAAAA" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e" + And user "Alice" has uploaded chunk file "2" of "3" with "BBBBB" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e" + And user "Alice" has uploaded chunk file "3" of "3" with "CCCCC" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e" + When user "Alice" requests the checksum of "/myChecksumFile.txt" via propfind + Then the HTTP status code should be "207" + And the webdav checksum should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df" + Examples: + | dav_version | + | old | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-17 + Scenario Outline: Uploading a chunked file with checksum should return the checksum in the download header + Given using DAV path + And user "Alice" has uploaded chunk file "1" of "3" with "AAAAA" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e" + And user "Alice" has uploaded chunk file "2" of "3" with "BBBBB" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e" + And user "Alice" has uploaded chunk file "3" of "3" with "CCCCC" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e" + When user "Alice" downloads file "/myChecksumFile.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the header checksum should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8" + Examples: + | dav_version | + | old | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @local_storage @files_external-app-required @notToImplementOnOCIS + Scenario Outline: Downloading a file from local storage has correct checksum + Given using DAV path + # Create the file directly in local storage, bypassing ownCloud + And file "prueba_cksum.txt" with text "Test file for checksums" has been created in local storage on the server + # Do a first download, which will trigger ownCloud to calculate a checksum for the file + When user "Alice" downloads file "/local_storage/prueba_cksum.txt" using the WebDAV API + # Now do a download that is expected to have a checksum with it + And user "Alice" downloads file "/local_storage/prueba_cksum.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the header checksum should match "SHA1:a35b7605c8f586d735435535c337adc066c2ccb6" + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-reva-14 + Scenario Outline: Moving file with checksum should return the checksum in the download header + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + When user "Alice" moves file "/myChecksumFile.txt" to "/myMovedChecksumFile.txt" using the WebDAV API + And user "Alice" downloads file "/myMovedChecksumFile.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the header checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-196 + Scenario Outline: Copying a file with checksum should return the checksum in the propfind using new DAV path + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + When user "Alice" copies file "/myChecksumFile.txt" to "/myChecksumFileCopy.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as user "Alice" the webdav checksum of "/myChecksumFileCopy.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960" + Examples: + | dav_version | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-98 + Scenario Outline: Copying file with checksum should return the checksum in the download header using new DAV path + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + When user "Alice" copies file "/myChecksumFile.txt" to "/myChecksumFileCopy.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the header checksum when user "Alice" downloads file "/myChecksumFileCopy.txt" using the WebDAV API should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f" + Examples: + | dav_version | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @issue-ocis-reva-196 + Scenario Outline: Sharing a file with checksum should return the checksum in the propfind using new DAV path + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + And user "Alice" has shared file "/myChecksumFile.txt" with user "Brian" + And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice" + When user "Brian" requests the checksum of "/Shares/myChecksumFile.txt" via propfind + Then the HTTP status code should be "207" + And the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960" + Examples: + | dav_version | + | new | + + @files_sharing-app-required @issue-ocis-reva-196 @skipOnOcV10 + Scenario Outline: Modifying a shared file should return correct checksum in the propfind using new DAV path + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + And user "Alice" has shared file "/myChecksumFile.txt" with user "Brian" + And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice" + When user "Brian" uploads file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/Shares/myChecksumFile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Alice" the webdav checksum of "/myChecksumFile.txt" via propfind should match "" + Examples: + | dav_version | checksum | + | new | SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 MD5:56e57920c3c8c727bfe7a5288cdf61c4 ADLER32:1048035a | + + @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload new DAV chunked file where checksum matches + Given using new DAV path + And user "Alice" has created a new chunking upload with id "chunking-42" + When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + + @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload new DAV chunked file where checksum does not match + Given using new DAV path + And user "Alice" has created a new chunking upload with id "chunking-42" + When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 201, 400" respectively + And user "Alice" should not see the following elements + | /myChunkedFile.txt | + + @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload new DAV chunked file using async MOVE where checksum matches + Given using new DAV path + And the administrator has enabled async operations + And user "Alice" has created a new chunking upload with id "chunking-42" + When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 201, 202" respectively + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + And the content of file "/myChunkedFile.txt" for user "Alice" should be "BBBBBCCCCC" + + @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload new DAV chunked file using async MOVE where checksum does not match + Given using new DAV path + And the administrator has enabled async operations + And user "Alice" has created a new chunking upload with id "chunking-42" + When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 201, 202" respectively + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^error$/ | + | errorCode | /^400$/ | + | errorMessage | /^The computed checksum does not match the one received from the client.$/ | + And user "Alice" should not see the following elements + | /myChunkedFile.txt | + + @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload new DAV chunked file using async MOVE where checksum does not match - retry with correct checksum + Given using new DAV path + And the administrator has enabled async operations + And user "Alice" has created a new chunking upload with id "chunking-42" + When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 201, 202, 202" respectively + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + And the content of file "/myChunkedFile.txt" for user "Alice" should be "BBBBBCCCCC" + + @issue-ocis-reva-99 + Scenario Outline: Upload a file where checksum does not match + Given using DAV path + When user "Alice" uploads file with checksum "SHA1:f005ba11" and content "Some Text" to "/chksumtst.txt" using the WebDAV API + Then the HTTP status code should be "400" + And user "Alice" should not see the following elements + | /chksumtst.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Upload a file where checksum does match + Given using DAV path + When user "Alice" uploads file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/chksumtst.txt" using the WebDAV API + Then the HTTP status code should be "201" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-99 + Scenario Outline: Uploaded file should have the same checksum when downloaded + Given using DAV path + And user "Alice" has uploaded file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/chksumtst.txt" + When user "Alice" downloads file "/chksumtst.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | OC-Checksum | SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @local_storage @files_external-app-required @notToImplementOnOCIS @skipOnEncryptionType:user-keys @encryption-issue-42 + Scenario Outline: Uploaded file to external storage should have the same checksum when downloaded + Given using DAV path + And user "Alice" has uploaded file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/local_storage/chksumtst.txt" + When user "Alice" downloads file "/local_storage/chksumtst.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | OC-Checksum | SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 | + Examples: + | dav_version | + | old | + | new | + + ## Validation Plugin or Old Endpoint Specific + @issue-ocis-reva-17 + Scenario Outline: Uploading an old method chunked file with checksum should fail using new DAV path + Given using DAV path + When user "Alice" uploads chunk file "1" of "3" with "AAAAA" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e" using the WebDAV API + Then the HTTP status code should be "503" + And user "Alice" should not see the following elements + | /myChecksumFile.txt | + Examples: + | dav_version | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + ## upload overwriting + @issue-ocis-reva-196 + Scenario Outline: Uploading a file with MD5 checksum overwriting an existing file + Given using DAV path + And user "Alice" has uploaded file with content "some data" to "textfile0.txt" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile0.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Alice" the webdav checksum of "/textfile0.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960" + And the content of file "/textfile0.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-196 + Scenario Outline: Uploading a file with SHA1 checksum overwriting an existing file + Given using DAV path + And user "Alice" has uploaded file with content "some data" to "textfile0.txt" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile0.txt" with checksum "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Alice" the webdav checksum of "/textfile0.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960" + And the content of file "/textfile0.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-224 @issue-ocis-reva-196 + Scenario Outline: Uploading a file with invalid SHA1 checksum overwriting an existing file + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile0.txt" with checksum "SHA1:f005ba11f005ba11f005ba11f005ba11f005ba11" using the WebDAV API + Then the HTTP status code should be "400" + And as user "Alice" the webdav checksum of "/textfile0.txt" via propfind should match "SHA1:2052377dec0724bda0d57aeab67fa819278b7f74 MD5:096e350e9ff1339a997a14145f9fc4b9 ADLER32:7d5a0921" + And the content of file "/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload overwriting a file with new chunking and correct checksum + Given using new DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has created a new chunking upload with id "chunking-42" + When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "/textfile0.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 201, 204" respectively + And the content of file "/textfile0.txt" for user "Alice" should be "BBBBBCCCCC" + + @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-224 @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload overwriting a file with new chunking and invalid checksum + Given using new DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has created a new chunking upload with id "chunking-42" + When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "/textfile0.txt" with checksum "SHA1:f005ba11" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 201, 400" respectively + And the content of file "/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + + @issue-ocis-reva-214 + Scenario Outline: Uploading a file with checksum should work for file with special characters + Given using DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav_version | renamed_file | + | old | " oc?test=ab&cd " | + | old | "# %ab ab?=ed" | + | new | " oc?test=ab&cd " | + | new | "# %ab ab?=ed" | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | renamed_file | + | spaces | " oc?test=ab&cd " | + | spaces | "# %ab ab?=ed" | diff --git a/tests/acceptance/features/coreApiMain/external-storage.feature b/tests/acceptance/features/coreApiMain/external-storage.feature new file mode 100644 index 00000000000..4b1a7e05764 --- /dev/null +++ b/tests/acceptance/features/coreApiMain/external-storage.feature @@ -0,0 +1,114 @@ +@api @local_storage @files_external-app-required @notToImplementOnOCIS +Feature: external-storage + + Background: + Given using OCS API version "1" + And using old DAV path + + @public_link_share-feature-required @files_sharing-app-required + Scenario: Share by public link a file inside a local external storage + Given these users have been created with default attributes and small skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "/local_storage/foo" + And user "Alice" has moved file "/textfile0.txt" to "/local_storage/foo/textfile0.txt" + And user "Alice" has shared folder "/local_storage/foo" with user "Brian" + When user "Brian" creates a public link share using the sharing API with settings + | path | foo | + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" should include + | id | A_NUMBER | + | url | AN_URL | + | token | A_TOKEN | + | mimetype | httpd/unix-directory | + + + Scenario: Move a file into storage + Given these users have been created with default attributes and small skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "/local_storage/foo1" + When user "Alice" moves file "/textfile0.txt" to "/local_storage/foo1/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/local_storage/foo1/textfile0.txt" should exist + And as "Alice" file "/local_storage/foo1/textfile0.txt" should exist + + + Scenario: Move a file out of storage + Given these users have been created with default attributes and small skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "/local_storage/foo2" + And user "Alice" has moved file "/textfile0.txt" to "/local_storage/foo2/textfile0.txt" + When user "Brian" moves file "/local_storage/foo2/textfile0.txt" to "/local.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/local_storage/foo2/textfile0.txt" should not exist + And as "Alice" file "/local_storage/foo2/textfile0.txt" should not exist + And as "Brian" file "/local.txt" should exist + + @skipOnEncryptionType:user-keys + Scenario: Copy a file into storage + Given these users have been created with default attributes and small skeleton files: + | username | + | Alice | + And user "Alice" has created folder "/local_storage/foo1" + When user "Alice" copies file "/textfile0.txt" to "/local_storage/foo1/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/local_storage/foo1/textfile0.txt" should exist + And as "Alice" file "/textfile0.txt" should exist + + + Scenario: Copy a file out of storage + Given these users have been created with default attributes and small skeleton files: + | username | + | Alice | + And user "Alice" has created folder "/local_storage/foo1" + And user "Alice" has uploaded file with content "ownCloud test text file inside localstorage" to "/local_storage/foo1/fileInsideLocalStorage.txt" + When user "Alice" copies file "/local_storage/foo1/fileInsideLocalStorage.txt" to "/fileInsideLocalStorage.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/fileInsideLocalStorage.txt" should exist + And as "Alice" file "/local_storage/foo1/fileInsideLocalStorage.txt" should exist + + + Scenario: Download a file that exists in filecache but not storage fails with 404 + Given user "Alice" has been created with default attributes and small 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" + # 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 + + + Scenario: Upload a file to external storage while quota is set on home storage + Given user "Alice" has been created with default attributes and small skeleton files + And the quota of user "Alice" has been set to "1 B" + When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/local_storage/testquota.txt" with all mechanisms using the WebDAV API + Then the HTTP status code of all upload responses should be "201" + And as "Alice" the files uploaded to "/local_storage/testquota.txt" with all mechanisms should exist + + + Scenario Outline: query OCS endpoint for information about the mount + Given using OCS API version "" + And user "Alice" has been created with default attributes and small skeleton files + When user "Alice" sends HTTP method "GET" to OCS API endpoint "" + Then the OCS status code should be "" + And the HTTP status code should be "" + And the fields of the last response to user "Alice" should include + | id | A_NUMBER | + | name | local_storage | + | type | dir | + | backend | Local | + | scope | system | + | permissions | read | + | class | local | + Examples: + | ocs_api_version | endpoint | ocs-code | http-code | + | 1 | /apps/files_external/api/v1/mounts | 100 | 200 | + | 2 | /apps/files_external/api/v1/mounts | 200 | 200 | diff --git a/tests/acceptance/features/coreApiMain/main.feature b/tests/acceptance/features/coreApiMain/main.feature new file mode 100644 index 00000000000..47be8bbc0ff --- /dev/null +++ b/tests/acceptance/features/coreApiMain/main.feature @@ -0,0 +1,13 @@ +@api +Feature: Other tests related to api + + @issue-ocis-reva-100 + Scenario: robots.txt file should be accessible + When a user requests "/robots.txt" with "GET" and no authentication + Then the HTTP status code should be "200" + And the content in the response should match the following content: + """ + User-agent: * + Disallow: / + + """ diff --git a/tests/acceptance/features/coreApiMain/quota.feature b/tests/acceptance/features/coreApiMain/quota.feature new file mode 100644 index 00000000000..f77285b557a --- /dev/null +++ b/tests/acceptance/features/coreApiMain/quota.feature @@ -0,0 +1,393 @@ +@api @issue-ocis-reva-101 @skipOnGraph +Feature: quota + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + # Owner + + Scenario: Uploading a file as owner having enough quota (except new chunking) + Given the quota of user "Alice" has been set to "10 MB" + When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be "201" + + @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Uploading a file as owner having enough quota (new chunking) + Given the quota of user "Alice" has been set to "10 MB" + And using new DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "201" + + @smokeTest + Scenario: Uploading a file as owner having insufficient quota (except new chunking) + Given the quota of user "Alice" has been set to "10 B" + When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be "507" + And as "Alice" the files uploaded to "/testquota.txt" with all mechanisms except new chunking should not exist + + @smokeTest @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Uploading a file as owner having insufficient quota (new chunking) + Given the quota of user "Alice" has been set to "10 B" + And using new DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "507" + And as "Alice" file "/testquota.txt" should not exist + + + Scenario: Overwriting a file as owner having enough quota (except new chunking) + Given user "Alice" has uploaded file with content "test" to "/testquota.txt" + And the quota of user "Alice" has been set to "10 MB" + When user "Alice" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be between "201" and "204" + + @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Overwriting a file as owner having enough quota (new chunking) + Given user "Alice" has uploaded file with content "test" to "/testquota.txt" + And the quota of user "Alice" has been set to "10 MB" + And using new DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be between "201" and "204" + + + Scenario: Overwriting a file as owner having insufficient quota (except new chunking) + Given user "Alice" has uploaded file with content "test" to "/testquota.txt" + And the quota of user "Alice" has been set to "10 B" + When user "Alice" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be "507" + And the content of file "/testquota.txt" for user "Alice" should be "test" + + @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Overwriting a file as owner having insufficient quota (new chunking) + Given user "Alice" has uploaded file with content "test" to "/testquota.txt" + And the quota of user "Alice" has been set to "10 B" + And using new DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "507" + And the content of file "/testquota.txt" for user "Alice" should be "test" + + # Received shared folder + + @files_sharing-app-required + Scenario: Uploading a file in received folder having enough quota (except new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/testquota" + And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all" + And the quota of user "Brian" has been set to "10 B" + And the quota of user "Alice" has been set to "10 MB" + When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be "201" + + @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Uploading a file in received folder having enough quota (new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/testquota" + And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all" + And the quota of user "Brian" has been set to "10 B" + And the quota of user "Alice" has been set to "10 MB" + And using new DAV path + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "201" + + @files_sharing-app-required + Scenario: Uploading a file in received folder having insufficient quota (except new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/testquota" + And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all" + And the quota of user "Brian" has been set to "10 MB" + And the quota of user "Alice" has been set to "10 B" + When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be "507" + And as "Brian" the files uploaded to "/testquota/testquota.txt" with all mechanisms except new chunking should not exist + + @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Uploading a file in a received folder having insufficient quota (new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/testquota" + And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all" + And the quota of user "Brian" has been set to "10 MB" + And the quota of user "Alice" has been set to "10 B" + And using new DAV path + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "507" + And as "Brian" file "/testquota/testquota.txt" should not exist + + @files_sharing-app-required + Scenario: Overwriting a file in received folder having enough quota (except new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/testquota" + And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt" + And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all" + And the quota of user "Brian" has been set to "10 B" + And the quota of user "Alice" has been set to "10 MB" + When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be between "201" and "204" + + @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Overwriting a file in received folder having enough quota (new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/testquota" + And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt" + And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all" + And the quota of user "Brian" has been set to "10 B" + And the quota of user "Alice" has been set to "10 MB" + And using new DAV path + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be between "201" and "204" + + @files_sharing-app-required + Scenario: Overwriting a file in received folder having insufficient quota (except new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/testquota" + And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt" + And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all" + And the quota of user "Brian" has been set to "10 MB" + And the quota of user "Alice" has been set to "10 B" + When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be "507" + And the content of file "/testquota/testquota.txt" for user "Alice" should be "test" + + @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Overwriting a file in received folder having insufficient quota (new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/testquota" + And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt" + And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all" + And the quota of user "Brian" has been set to "10 MB" + And the quota of user "Alice" has been set to "10 B" + And using new DAV path + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "507" + And the content of file "/testquota/testquota.txt" for user "Alice" should be "test" + + # Received shared file + + @files_sharing-app-required + Scenario: Overwriting a received file having enough quota (except new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "test" to "/testquota.txt" + And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read" + And the quota of user "Brian" has been set to "10 B" + And the quota of user "Alice" has been set to "10 MB" + When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be between "201" and "204" + + @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Overwriting a received file having enough quota (new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "test" to "/testquota.txt" + And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read" + And the quota of user "Brian" has been set to "10 B" + And the quota of user "Alice" has been set to "10 MB" + And using new DAV path + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be between "201" and "204" + + @files_sharing-app-required + Scenario: Overwriting a received file having insufficient quota (except new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "test" to "/testquota.txt" + And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read" + And the quota of user "Brian" has been set to "10 MB" + And the quota of user "Alice" has been set to "10 B" + When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of all upload responses should be "507" + And the content of file "/testquota.txt" for user "Alice" should be "test" + + @files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Overwriting a received file having insufficient quota (new chunking) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "test" to "/testquota.txt" + And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read" + And the quota of user "Brian" has been set to "10 MB" + And the quota of user "Alice" has been set to "10 B" + And using new DAV path + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "507" + And the content of file "/testquota.txt" for user "Alice" should be "test" + + + Scenario: User with zero quota cannot upload a file + Given the quota of user "Alice" has been set to "0 B" + When user "Alice" uploads file with content "uploaded content" to "testquota.txt" using the WebDAV API + Then the HTTP status code should be "507" + And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage" + + + Scenario: User with zero quota can create a folder + Given the quota of user "Alice" has been set to "0 B" + When user "Alice" creates folder "testQuota" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" folder "testQuota" should exist + + @files_sharing-app-required + Scenario: user cannot create file on shared folder by a user with zero quota + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "0 B" + And the quota of user "Alice" has been set to "10 MB" + And user "Brian" has created folder "shareFolder" + And user "Brian" has shared file "/shareFolder" with user "Alice" + And user "Alice" has accepted share "/shareFolder" offered by user "Brian" + When user "Alice" uploads file with content "uploaded content" to "/Shares/shareFolder/newTextFile.txt" using the WebDAV API + Then the HTTP status code should be "507" + And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage" + And as "Brian" file "/shareFolder/newTextFile.txt" should not exist + + @files_sharing-app-required + Scenario: share receiver with 0 quota should not be able to move file from shared folder to home folder + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "0 B" + And the quota of user "Alice" has been set to "10 MB" + And user "Alice" has uploaded file with content "test" to "/testquota.txt" + And user "Alice" has shared file "/testquota.txt" with user "Brian" + And user "Brian" has accepted share "/testquota.txt" offered by user "Alice" + When user "Brian" moves file "/Shares/testquota.txt" to "/testquota.txt" using the WebDAV API + Then the HTTP status code should be "507" + And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage" + + @files_sharing-app-required + Scenario: sharer should be able to upload to a folder shared with user having zero quota + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "0 B" + And the quota of user "Alice" has been set to "10 MB" + And user "Alice" has created folder "shareFolder" + And user "Alice" has uploaded file with content "test" to "/shareFolder/testquota.txt" + And user "Alice" has shared file "/shareFolder" with user "Brian" + And user "Brian" has accepted share "/shareFolder" offered by user "Alice" + When user "Alice" moves file "/shareFolder/testquota.txt" to "/testquota.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testquota.txt" for user "Alice" should be "test" + And as "Brian" file "/Shares/testquota" should not exist + + @files_sharing-app-required + Scenario: share receiver with 0 quota should be able to upload on shared folder + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "0 B" + And the quota of user "Alice" has been set to "10 MB" + And user "Alice" has created folder "shareFolder" + And user "Alice" has shared file "/shareFolder" with user "Brian" + And user "Brian" has accepted share "/shareFolder" offered by user "Alice" + When user "Brian" uploads file with content "uploaded content" to "/Shares/shareFolder/newTextFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/shareFolder/newTextFile.txt" for user "Alice" should be "uploaded content" + + + Scenario: User should retain their old files even if their quota is set to 0 + Given user "Alice" has uploaded file with content "test" to "/testquota.txt" + And the quota of user "Alice" has been set to "0 B" + Then the content of file "/testquota.txt" for user "Alice" should be "test" + + + Scenario: User should be able to restore their deleted file when their quota is set to zero + Given user "Alice" has uploaded file with content "test" to "/testquota.txt" + And user "Alice" has deleted file "/testquota.txt" + And the quota of user "Alice" has been set to "0 B" + When user "Alice" restores the file with original path "/testquota.txt" to "/testquota.txt" using the trashbin API + Then the HTTP status code should be "201" + And the content of file "/testquota.txt" for user "Alice" should be "test" + + @files_sharing-app-required @skipOnOcV10.10 + Scenario: share receiver with 0 quota can copy empty file from shared folder to home folder + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "0 B" + And the quota of user "Alice" has been set to "10 MB" + And user "Alice" has created folder "shareFolder" + And user "Alice" has uploaded file with content "" to "/shareFolder/testquota.txt" + And user "Alice" has shared folder "/shareFolder" with user "Brian" + And user "Brian" has accepted share "/shareFolder" offered by user "Alice" + When user "Brian" copies file "/Shares/shareFolder/testquota.txt" to "/testquota.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "testquota.txt" should exist + + + Scenario: User with zero quota can upload an empty file + Given the quota of user "Alice" has been set to "0 B" + When user "Alice" uploads file with content "" to "testquota.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "testquota.txt" should exist + + @files_sharing-app-required @skipOnOcV10.10 + Scenario Outline: share receiver with insufficient quota should not be able to copy received shared file to home folder + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "" + And the quota of user "Alice" has been set to "10 MB" + And user "Alice" has uploaded file with content "" to "/testquota.txt" + And user "Alice" has shared file "/testquota.txt" with user "Brian" + And user "Brian" has accepted share "/testquota.txt" offered by user "Alice" + When user "Brian" copies file "/Shares/testquota.txt" to "/testquota.txt" using the WebDAV API + Then the HTTP status code should be "507" + And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage" + And as "Brian" file "/testquota.txt" should not exist + Examples: + | quota | file-content | + | 0 B | four | + | 10 B | test-content-15 | + + @files_sharing-app-required @skipOnOcV10.10 + Scenario Outline: share receiver with insufficient quota should not be able to copy file from shared folder to home folder + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "" + And the quota of user "Alice" has been set to "10 MB" + And user "Alice" has created folder "shareFolder" + And user "Alice" has uploaded file with content "" to "/shareFolder/testquota.txt" + And user "Alice" has shared folder "/shareFolder" with user "Brian" + And user "Brian" has accepted share "/shareFolder" offered by user "Alice" + When user "Brian" copies file "/Shares/shareFolder/testquota.txt" to "/testquota.txt" using the WebDAV API + Then the HTTP status code should be "507" + And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage" + And as "Brian" file "/testquota.txt" should not exist + Examples: + | quota | file-content | + | 0 B | four | + | 10 B | test-content-15 | + + @files_sharing-app-required @skipOnOcV10.10 @skipOnEncryption @issue-encryption-357 + Scenario: share receiver of a share with insufficient quota should not be able to copy from home folder to the received shared file + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "10 MB" + And the quota of user "Alice" has been set to "10 B" + And user "Alice" has uploaded file with content "short" to "/testquota.txt" + And user "Brian" has uploaded file with content "longer line of text" to "/testquota.txt" + And user "Alice" has shared file "/testquota.txt" with user "Brian" + And user "Brian" has accepted share "/testquota.txt" offered by user "Alice" + When user "Brian" copies file "/testquota.txt" to "/Shares/testquota.txt" using the WebDAV API + Then the HTTP status code should be "507" + And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage" + And as "Brian" file "/Shares/testquota.txt" should exist + And as "Alice" file "/testquota.txt" should exist + # The copy should have failed, so Alice should still see the original content + And the content of file "/testquota.txt" for user "Alice" should be "short" + + @files_sharing-app-required @skipOnOcV10.10 + Scenario: share receiver of a share with insufficient quota should not be able to copy file from home folder to the received shared folder + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "10 MB" + And the quota of user "Alice" has been set to "10 B" + And user "Alice" has created folder "shareFolder" + And user "Alice" has shared folder "/shareFolder" with user "Brian" + And user "Brian" has accepted share "/shareFolder" offered by user "Alice" + And user "Brian" has uploaded file with content "test-content-15" to "/testquota.txt" + When user "Brian" copies file "/testquota.txt" to "/Shares/shareFolder/testquota.txt" using the WebDAV API + Then the HTTP status code should be "507" + And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage" + And as "Brian" file "/testquota.txt" should exist + # The copy should have failed, so Alice should not see the file + And as "Alice" file "/shareFolder/testquota.txt" should not exist diff --git a/tests/acceptance/features/coreApiMain/status.feature b/tests/acceptance/features/coreApiMain/status.feature new file mode 100644 index 00000000000..f24c8b9761c --- /dev/null +++ b/tests/acceptance/features/coreApiMain/status.feature @@ -0,0 +1,10 @@ +@api +Feature: Status + + @smokeTest + Scenario: Status.php is correct + When the administrator requests status.php + Then the status.php response should include + """ + {"installed":true,"maintenance":false,"needsDbUpgrade":false,"version":"$CURRENT_VERSION","versionstring":"$CURRENT_VERSION_STRING","edition":"$EDITION","productname":"$PRODUCTNAME","product":"$PRODUCT"} + """ diff --git a/tests/acceptance/features/coreApiMain/userSync.feature b/tests/acceptance/features/coreApiMain/userSync.feature new file mode 100644 index 00000000000..01a787b8ed9 --- /dev/null +++ b/tests/acceptance/features/coreApiMain/userSync.feature @@ -0,0 +1,68 @@ +@api @notToImplementOnOCIS @issue-ocis-1241 +Feature: Users sync + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: Trying to sync a user when there is no external user backend + Given using OCS API version "" + When the administrator tries to sync user "Alice" using the OCS API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the OCS status message should be "" + Examples: + | ocs-api-version | ocs-status-code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Trying to sync a user which does not exist + Given using OCS API version "" + When the administrator tries to sync user "nonexistentuser" using the OCS API + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "User is not known in any user backend: nonexistentuser" + Examples: + | ocs-api-version | http-status-code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: Trying to sync a user as another user which does not exist + Given using OCS API version "" + When user "nonexistentuser" tries to sync user "Brian" using the OCS API + Then the HTTP status code should be "401" + And the OCS status code should be "997" + And the OCS status message should be "Unauthorised" + Examples: + | ocs-api-version | + | 1 | + | 2 | + + @smokeTest + Scenario Outline: Trying to sync a user by non admin user + Given using OCS API version "" + When user "Alice" tries to sync user "Brian" using the OCS API + Then the HTTP status code should be "" + And the OCS status code should be "" + And the OCS status message should be "Logged in user must be an admin" + Examples: + | ocs-api-version | ocs-status-code | http-status-code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | + + + Scenario Outline: Trying to sync a user by admin using an incorrect password + Given using OCS API version "" + When the administrator tries to sync user "Brian" using password "invalid" and the OCS API + Then the HTTP status code should be "401" + And the OCS status code should be "997" + And the OCS status message should be "Unauthorised" + Examples: + | ocs-api-version | + | 1 | + | 2 | diff --git a/tests/acceptance/features/coreApiProvisioning-v1/addUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/addUser.feature new file mode 100644 index 00000000000..be2f77df6a8 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/addUser.feature @@ -0,0 +1,224 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: add user + As an admin + I want to be able to add users + So that I can give people controlled individual access to resources on the ownCloud server + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin creates a user + Given user "brand-new-user" has been deleted + When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should exist + And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + + + Scenario: admin creates a user with special characters in the username + Given the following users have been deleted + | username | + | a@-+_.b | + | a space | + When the administrator sends a user creation request for the following users with password using the provisioning API + | username | password | + | a@-+_.b | %alt1% | + | a space | %alt1% | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should exist + | username | + | a@-+_.b | + | a space | + And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + | username | + | a@-+_.b | + | a space | + + + Scenario: admin tries to create an existing user + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API + Then the OCS status code should be "102" + And the HTTP status code should be "200" + And the API should not return any data + + + Scenario: admin tries to create an existing disabled user + Given user "brand-new-user" has been created with default attributes and without skeleton files + And user "brand-new-user" has been disabled + When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API + Then the OCS status code should be "102" + And the HTTP status code should be "200" + And the API should not return any data + + @notToImplementOnOCIS + Scenario: Admin creates a new user and adds him directly to a group + Given group "brand-new-group" has been created + When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" group "brand-new-group" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should belong to group "brand-new-group" + And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + + + Scenario: admin creates a user and specifies a password with special characters + When the administrator sends a user creation request for the following users with password using the provisioning API + | username | password | comment | + | brand-new-user1 | !@#$%^&*()-_+=[]{}:;,.<>?~/\ | special characters | + | brand-new-user2 | España§àôœ€ | special European and other characters | + | brand-new-user3 | नेपाली | Unicode | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should exist + | username | + | brand-new-user1 | + | brand-new-user2 | + | brand-new-user3 | + And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + | username | + | brand-new-user1 | + | brand-new-user2 | + | brand-new-user3 | + + + Scenario: admin creates a user and specifies an invalid password, containing just space + Given user "brand-new-user" has been deleted + When the administrator sends a user creation request for user "brand-new-user" password " " using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + + + Scenario: admin creates a user and specifies a password containing spaces + Given user "brand-new-user" has been deleted + When the administrator sends a user creation request for user "brand-new-user" password "spaces in my password" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should exist + And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + + + Scenario Outline: admin creates a user with username that contains capital letters + When the administrator sends a user creation request for user "" password "%alt1%" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Brand-New-User" should exist + And user "BRAND-NEW-USER" should exist + And user "brand-new-user" should exist + And user "brand-NEW-user" should exist + And user "BrAnD-nEw-UsEr" should exist + And the display name of user "brand-new-user" should be "" + Examples: + | display-name | + | Brand-New-User | + | BRAND-NEW-USER | + | brand-new-user | + | brand-NEW-user | + | BrAnD-nEw-UsEr | + + + Scenario: admin tries to create an existing user but with username containing capital letters + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator sends a user creation request for user "BRAND-NEW-USER" password "%alt1%" using the provisioning API + Then the OCS status code should be "102" + And the HTTP status code should be "200" + And the API should not return any data + + + Scenario: admin creates a user with unusual username + Given the following users have been deleted + | username | + | user-1 | + | null | + | nil | + | 123 | + | -123 | + | 0.0 | + When the administrator sends a user creation request for the following users with password using the provisioning API + | username | password | + | user-1 | %alt1% | + | null | %alt1% | + | nil | %alt1% | + | 123 | %alt1% | + | -123 | %alt1% | + | 0.0 | %alt1% | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should exist + | username | + | user-1 | + | null | + | nil | + | 123 | + | -123 | + | 0.0 | + And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + | username | + | user-1 | + | null | + | nil | + | 123 | + | -123 | + | 0.0 | + + @notToImplementOnOCIS + Scenario: subadmin should not be able to create a new user + Given user "brand-new-user" has been deleted + And user "subadmin" has been created with default attributes and without skeleton files + And group "group101" has been created + And user "subadmin" has been added to group "group101" + And user "subadmin" has been made a subadmin of group "group101" + When unauthorized user "subadmin" tries to create new user "brand-new-user" with password "%alt1%" using the provisioning API + Then the OCS status code should be "106" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + + + Scenario: normal user should not be able to create another user + Given user "brand-new-user" has been deleted + And user "Alice" has been created with default attributes and without skeleton files + When unauthorized user "Alice" tries to create new user "brand-new-user" with password "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "brand-new-user" should not exist + + @notToImplementOnOCIS + Scenario: subadmin should be able to create a new user into their group + Given user "brand-new-user" has been deleted + And user "subadmin" has been created with default attributes and without skeleton files + And group "group101" has been created + And user "subadmin" has been added to group "group101" + And user "subadmin" has been made a subadmin of group "group101" + When the groupadmin "subadmin" sends a user creation request for user "brand-new-user" password "%alt1%" group "group101" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should exist + + @notToImplementOnOCIS + Scenario: subadmin should not be able to create a new user into other group + Given user "brand-new-user" has been deleted + And user "subadmin" has been created with default attributes and without skeleton files + And group "group101" has been created + And group "group102" has been created + And user "subadmin" has been added to group "group101" + And user "subadmin" has been made a subadmin of group "group101" + When the groupadmin "subadmin" tries to create new user "brand-new-user" password "%alt1%" in other group "group102" using the provisioning API + Then the OCS status code should be "105" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + + @sqliteDB + Scenario: admin tries to create user with brackets in the username + When the administrator sends a user creation request for the following users with password using the provisioning API + | username | password | + | [user1] | %alt1% | + | [ user2 ] | %alt1% | + Then the OCS status code of responses on all endpoints should be "101" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not exist + | username | + | [user1] | + | [ user2 ] | diff --git a/tests/acceptance/features/coreApiProvisioning-v1/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/coreApiProvisioning-v1/apiProvisioningUsingAppPassword.feature new file mode 100644 index 00000000000..95e059d42bd --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/apiProvisioningUsingAppPassword.feature @@ -0,0 +1,79 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: access user provisioning API using app password + As an ownCloud user + I want to be able to use the provisioning API with an app password + So that I can make a client app or script for provisioning users/groups that can use an app password instead of my real password. + + Background: + Given using OCS API version "1" + + @smokeTest @notToImplementOnOCIS + Scenario: admin deletes the user + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And a new client token for the administrator has been generated + And a new browser session for the administrator has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v1.php/cloud/users/brand-new-user" with "DELETE" using the generated app password + Then the HTTP status code should be "200" + And user "brand-new-user" should not exist + + @notToImplementOnOCIS + Scenario: subadmin gets users in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "another-new-user" has been added to group "brand-new-group" + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + And a new client token for "brand-new-user" has been generated + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v1.php/cloud/users" with "GET" using the generated app password + Then the HTTP status code should be "200" + And the users returned by the API should be + | another-new-user | + + @smokeTest + Scenario: normal user gets their own information using the app password + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | New User | + And a new client token for "brand-new-user" has been generated + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v1.php/cloud/users/brand-new-user" with "GET" using the generated app password + Then the HTTP status code should be "200" + And the display name returned by the API should be "New User" + + @notToImplementOnOCIS + Scenario: subadmin tries to get users of other group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And group "another-new-group" has been created + And user "another-new-user" has been added to group "another-new-group" + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + And a new client token for "brand-new-user" has been generated + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v1.php/cloud/users" with "GET" using the generated app password + Then the HTTP status code should be "200" + And the users returned by the API should not include "another-new-user" + + + Scenario: normal user tries to get other user information using the app password + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And a new client token for "brand-new-user" has been generated + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v1.php/cloud/users/another-new-user" with "GET" using the generated app password + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioning-v1/createSubAdmin.feature b/tests/acceptance/features/coreApiProvisioning-v1/createSubAdmin.feature new file mode 100644 index 00000000000..a6935a77b0a --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/createSubAdmin.feature @@ -0,0 +1,61 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: create a subadmin + 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 + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin creates a subadmin + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + When the administrator makes user "brand-new-user" a subadmin of group "brand-new-group" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should be a subadmin of group "brand-new-group" + + + Scenario: admin tries to create a subadmin using a user which does not exist + Given user "nonexistentuser" has been deleted + And group "brand-new-group" has been created + When the administrator makes user "nonexistentuser" a subadmin of group "brand-new-group" using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" + And user "nonexistentuser" should not be a subadmin of group "brand-new-group" + + + Scenario: admin tries to create a subadmin using a group which does not exist + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "not-group" has been deleted + When the administrator makes user "brand-new-user" a subadmin of group "not-group" using the provisioning API + Then the OCS status code should be "102" + And the HTTP status code should be "200" + And the API should not return any data + + + Scenario: subadmin of a group tries to make another user subadmin of their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "brand-new-group" has been created + 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 HTTP status code should be "401" + And user "brand-new-user" should not be a subadmin of group "brand-new-group" + + + Scenario: normal user should not be able to make another user a subadmin + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "group101" has been created + When user "Alice" makes user "Brian" a subadmin of group "group101" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "Brian" should not be a subadmin of group "group101" diff --git a/tests/acceptance/features/coreApiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/deleteUser.feature new file mode 100644 index 00000000000..3d6ee38b668 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/deleteUser.feature @@ -0,0 +1,134 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: delete users + As an admin + I want to be able to delete users + So that I can remove user from ownCloud + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: Delete a user + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator deletes user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + + + Scenario: Delete a user with special characters in the username + Given these users have been created without skeleton files: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + When the administrator deletes the following users using the provisioning API + | username | + | a@-+_.b | + | a space | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not exist + | username | + | a@-+_.b | + | a space | + + + Scenario: Delete a user, and specify the user name in different case + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator deletes user "Brand-New-User" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + + @smokeTest @notToImplementOnOCIS + Scenario: subadmin deletes a user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "new-group" has been created + And user "brand-new-user" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + + + Scenario: normal user tries to delete a user + Given these users have been created with default attributes and without 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 HTTP status code should be "401" + And user "Brian" should exist + + + Scenario: administrator deletes another admin user + Given these users have been created with default attributes and without skeleton files: + | username | + | another-admin | + And user "another-admin" has been added to group "admin" + When the administrator deletes user "another-admin" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "another-admin" should not exist + + @notToImplementOnOCIS + Scenario: subadmin deletes a user with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group" has been created + And user "another-subadmin" has been added to group "new-group" + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "another-subadmin" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "another-subadmin" should not exist + + @notToImplementOnOCIS + Scenario: subadmin should not be able to delete another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group" has been created + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "another-subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-subadmin" should exist + + @notToImplementOnOCIS + Scenario: subadmin should not be able to delete a user with admin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-admin | + And user "another-admin" has been added to group "admin" + And group "new-group" has been created + And user "another-admin" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "another-admin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-admin" should exist + + @notToImplementOnOCIS + Scenario: subadmin should not be able to delete a user not in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "new-group" has been created + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "brand-new-user" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "brand-new-user" should exist diff --git a/tests/acceptance/features/coreApiProvisioning-v1/disableApp.feature b/tests/acceptance/features/coreApiProvisioning-v1/disableApp.feature new file mode 100644 index 00000000000..3051238bfa9 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/disableApp.feature @@ -0,0 +1,36 @@ +@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: disable an app + As an admin + I want to be able to disable an enabled app + So that I can stop the app features being used + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: Admin disables an app + Given app "comments" has been enabled + When the administrator disables app "comments" + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And app "comments" should be disabled + + + Scenario: subadmin tries to disable an app + Given user "subadmin" has been created with default attributes and without 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 HTTP status code should be "401" + And app "comments" should be enabled + + + Scenario: normal user tries to disable an app + Given user "brand-new-user" has been created with default attributes and without 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 HTTP status code should be "401" + And app "comments" should be enabled diff --git a/tests/acceptance/features/coreApiProvisioning-v1/disableUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/disableUser.feature new file mode 100644 index 00000000000..4fdf7987b4a --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/disableUser.feature @@ -0,0 +1,311 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: disable user + 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 + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin disables an user + Given user "Alice" has been created with default attributes and without skeleton files + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be disabled + + + Scenario: admin disables an user with special characters in the username + Given these users have been created without skeleton files: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + When the administrator disables the following users using the provisioning API + | username | + | a@-+_.b | + | a space | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should be disabled + | username | + | a@-+_.b | + | a space | + + @smokeTest @notToImplementOnOCIS + Scenario: Subadmin should be able to disable an user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And user "subadmin" has been added to group "brand-new-group" + And user "Alice" 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 "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be disabled + + @notToImplementOnOCIS + Scenario: Subadmin should not be able to disable an user not in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And group "another-group" has been created + And user "subadmin" has been added to group "brand-new-group" + 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 HTTP status code should be "401" + And user "Alice" should be enabled + + @notToImplementOnOCIS + Scenario: Subadmins should not be able to disable users that have admin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-admin | + And group "brand-new-group" has been created + And user "another-admin" has been added to group "admin" + And user "subadmin" has been added to group "brand-new-group" + 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 HTTP status code should be "401" + And user "another-admin" should be enabled + + + Scenario: Admin can disable another admin user + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When the administrator disables user "another-admin" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "another-admin" should be disabled + + @notToImplementOnOCIS + Scenario: Admin can disable subadmins in the same group + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been added to group "brand-new-group" + And the administrator has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When the administrator disables user "subadmin" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "subadmin" should be disabled + + + Scenario: Admin user cannot disable himself + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When user "another-admin" disables user "another-admin" using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" + And user "another-admin" should be enabled + + + Scenario: disable an user with a regular user + Given these users have been created with default attributes and small 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 HTTP status code should be "401" + And user "Brian" should be enabled + + @notToImplementOnOCIS + Scenario: Subadmin should not be able to disable himself + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" 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 "subadmin" using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" + And user "subadmin" should be enabled + + @smokeTest + Scenario: Making a web request with a disabled user + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" sends HTTP method "GET" to URL "/index.php/apps/files" + Then the HTTP status code should be "403" + + + Scenario: Disabled user tries to download file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" downloads file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to upload file + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" uploads file with content "uploaded content" to "newTextFile.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to rename file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" moves file "/textfile0.txt" to "/renamedTextfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to move file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" moves file "/textfile0.txt" to "/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to delete file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" deletes file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to share a file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to share a folder + Given user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + Then the HTTP status code should be "401" + + + Scenario: getting shares shared by disabled user (to shares folder) + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And as "Brian" file "/Shares/textfile0.txt" should exist + And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" plus end-of-line + + @notToImplementOnOCIS + Scenario: getting shares shared by disabled user (to root) + Given user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And as "Brian" file "/textfile0.txt" should exist + And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" plus end-of-line + + + Scenario: getting shares shared by disabled user in a group (to shares folder) + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And group "group0" has been created + And user "Brian" has been added to group "group0" + And user "Alice" has shared folder "/PARENT" with group "group0" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And as "Brian" folder "/Shares/PARENT" should exist + And the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" plus end-of-line + + @notToImplementOnOCIS + Scenario: getting shares shared by disabled user in a group (to root) + Given user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And group "group0" has been created + And user "Brian" has been added to group "group0" + And user "Alice" has shared folder "/PARENT" with group "group0" + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And as "Brian" folder "/PARENT" should exist + And the content of file "/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" plus end-of-line + + + Scenario: Disabled user tries to create public link share + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" creates a public link share using the sharing API with settings + | path | textfile0.txt | + Then the HTTP status code should be "401" + + + Scenario Outline: getting public link share shared by disabled user using the new public WebDAV API + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has created a public link share with settings + | path | /textfile0.txt | + | permissions | read | + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And the public should be able to download the last publicly shared file using the public WebDAV API without a password and the content should be "ownCloud test text file 0" plus end-of-line + Examples: + | dav_version | + | old | + | new | + + @notToImplementOnOCIS + Scenario: Subadmin should be able to disable user with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + And user "another-subadmin" has been added to group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" disables user "another-subadmin" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "another-subadmin" should be disabled + + @notToImplementOnOCIS + Scenario: Subadmin should not be able to disable another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" disables user "another-subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-subadmin" should be enabled + + + Scenario: normal user cannot disable himself + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + When user "Alice" disables user "Alice" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "Alice" should be enabled diff --git a/tests/acceptance/features/coreApiProvisioning-v1/editUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/editUser.feature new file mode 100644 index 00000000000..a10d9b0c455 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/editUser.feature @@ -0,0 +1,369 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: edit users + As an admin, subadmin or as myself + I want to be able to edit user information + So that I can keep the user information up-to-date + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: the administrator can edit a user email + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + + + Scenario Outline: the administrator can edit a user email of an user with special characters in the username + Given these users have been created without skeleton files: + | username | email | + | | | + When the administrator changes the email of user "" to "a-different-email@example.com" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And the email address of user "" should be "a-different-email@example.com" + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + + @smokeTest + Scenario: the administrator can edit a user display (the API allows editing the "display name" by using the key word "display") + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator changes the display of user "brand-new-user" to "A New User" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And the display name of user "brand-new-user" should be "A New User" + + + Scenario: the administrator can edit a user display name + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator changes the display name of user "brand-new-user" to "A New User" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And the display name of user "brand-new-user" should be "A New User" + + + Scenario: the administrator can clear a user display name and then it defaults to the username + Given user "brand-new-user" has been created with default attributes and without skeleton files + And the administrator has changed the display name of user "brand-new-user" to "A New User" + When the administrator changes the display name of user "brand-new-user" to "" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And the display name of user "brand-new-user" should be "brand-new-user" + + @smokeTest + Scenario: the administrator can edit a user quota + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator changes the quota of user "brand-new-user" to "12MB" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And the quota definition of user "brand-new-user" should be "12 MB" + + + Scenario: the administrator can override an existing user email + Given user "brand-new-user" has been created with default attributes and without skeleton files + And the administrator has changed the email of user "brand-new-user" to "brand-new-user@gmail.com" + When the administrator changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + + + Scenario: the administrator can clear an existing user email + Given user "brand-new-user" has been created with default attributes and without skeleton files + And the administrator has changed the email of user "brand-new-user" to "brand-new-user@gmail.com" + When the administrator changes the email of user "brand-new-user" to "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the email address of user "brand-new-user" should be "" + + @smokeTest @notToImplementOnOCIS + Scenario: a subadmin should be able to edit the user information in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "new-group" has been created + And user "brand-new-user" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" changes the quota of user "brand-new-user" to "12MB" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the quota definition of user "brand-new-user" should be "12 MB" + When user "subadmin" changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + When user "subadmin" changes the display of user "brand-new-user" to "Anne Brown" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name of user "brand-new-user" should be "Anne Brown" + + + Scenario: a normal user should be able to change their email address + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the attributes of user "brand-new-user" returned by the API should include + | email | brand-new-user@example.com | + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + + + Scenario Outline: a normal user should be able to change their display name + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" changes the display name of user "brand-new-user" to "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the attributes of user "brand-new-user" returned by the API should include + | displayname | | + And the display name of user "brand-new-user" should be "" + Examples: + | display-name | + | Alan Border | + | Phil Cyclist 🚴 | + + + Scenario: a normal user should not be able to change their quota + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" changes the quota of user "brand-new-user" to "12MB" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "brand-new-user" returned by the API should include + | quota definition | default | + And the quota definition of user "brand-new-user" should be "default" + + @notToImplementOnOCIS + Scenario: the administrator can edit user information with admin permissions + Given these users have been created with default attributes and without skeleton files: + | username | + | another-admin | + And user "another-admin" has been added to group "admin" + When user "another-admin" changes the quota of user "another-admin" to "12MB" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the quota definition of user "another-admin" should be "12 MB" + When user "another-admin" changes the email of user "another-admin" to "another-admin@example.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the email address of user "another-admin" should be "another-admin@example.com" + When user "another-admin" changes the display of user "another-admin" to "Anne Brown" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name of user "another-admin" should be "Anne Brown" + + @notToImplementOnOCIS + Scenario: a subadmin should be able to edit user information with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group" has been created + And user "another-subadmin" has been added to group "new-group" + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" changes the quota of user "another-subadmin" to "12MB" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the quota definition of user "another-subadmin" should be "12 MB" + When user "subadmin" changes the email of user "another-subadmin" to "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the email address of user "another-subadmin" should be "brand-new-user@example.com" + When user "subadmin" changes the display of user "another-subadmin" to "Anne Brown" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name of user "another-subadmin" should be "Anne Brown" + + @notToImplementOnOCIS + Scenario: a subadmin should not be able to edit user information of another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group" has been created + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" changes the quota of user "another-subadmin" to "12MB" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the quota definition of user "another-subadmin" should be "default" + When user "subadmin" changes the email of user "another-subadmin" to "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the email address of user "another-subadmin" should be "another-subadmin@owncloud.com" + When user "subadmin" changes the display of user "another-subadmin" to "Anne Brown" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the display name of user "another-subadmin" should be "Regular User" + + + Scenario: a normal user should not be able to edit another user's information + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + When user "Alice" tries to change the display name of user "Brian" to "New Brian" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the display name of user "Brian" should not have changed + When user "Alice" tries to change the email of user "Brian" to "brian-new-email@example.com" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the email address of user "Brian" should not have changed + + + Scenario: Admin gives access to users to change their email address + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_mail_address" with value "true" and type "boolean" + When user "Alice" changes the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | email | alice@gmail.com | + And the email address of user "Alice" should be "alice@gmail.com" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" + When user "Alice" tries to change the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "Alice" returned by the API should include + | email | alice@example.org | + And the email address of user "Alice" should not have changed + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address, admin can still change the email address + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" + When the administrator changes the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | email | alice@gmail.com | + And the email address of user "Alice" should be "alice@gmail.com" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address, admin can still change their own email address + Given the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" + When the administrator changes the email of user "admin" to "something@example.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the attributes of user "admin" returned by the API should include + | email | something@example.com | + And the email address of user "admin" should be "something@example.com" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address, subadmin can still change the email address of a user they are subadmin of + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | Alice | + And group "new-group" has been created + And user "Alice" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + And the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" + When user "subadmin" changes the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | email | alice@gmail.com | + And the email address of user "Alice" should be "alice@gmail.com" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address, subadmin cannot change the email address of a user they are not subadmin of + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | Alice | + And group "new-group" has been created + And user "subadmin" has been made a subadmin of group "new-group" + # Note: Alice is not a member of new-group, so subadmin does not a priv to change the email address of Alice + And the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" + When user "subadmin" tries to change the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "Alice" returned by the API should include + | email | alice@example.org | + And the email address of user "Alice" should not have changed + + + Scenario: Admin gives access to users to change their display name + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_display_name" with value "true" and type "boolean" + When user "Alice" changes the display of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | displayname | Alice Wonderland | + And the display name of user "Alice" should be "Alice Wonderland" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean" + When user "Alice" tries to change the display name of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "Alice" returned by the API should include + | displayname | Alice Hansen | + And the display name of user "Alice" should not have changed + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name, admin can still change display name + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean" + When the administrator changes the display name of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | displayname | Alice Wonderland | + And the display name of user "Alice" should be "Alice Wonderland" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name, admin can still change their own display name + Given the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean" + When the administrator changes the display name of user "admin" to "The Administrator" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the attributes of user "admin" returned by the API should include + | displayname | The Administrator | + And the display name of user "admin" should be "The Administrator" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name, subadmin can still change the display name of a user they are subadmin of + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | Alice | + And group "new-group" has been created + And user "Alice" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + And the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean" + When user "subadmin" changes the display name of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + | displayname | Alice Wonderland | + And the display name of user "Alice" should be "Alice Wonderland" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name, subadmin cannot change the display name of a user they are not subadmin of + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | Alice | + And group "new-group" has been created + And user "subadmin" has been made a subadmin of group "new-group" + # Note: Alice is not a member of new-group, so subadmin does not a priv to change the email address of Alice + And the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean" + When user "subadmin" tries to change the display name of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "Alice" returned by the API should include + | displayname | Alice Hansen | + And the display name of user "Alice" should not have changed diff --git a/tests/acceptance/features/coreApiProvisioning-v1/enableApp.feature b/tests/acceptance/features/coreApiProvisioning-v1/enableApp.feature new file mode 100644 index 00000000000..a1dbc7a7bc4 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/enableApp.feature @@ -0,0 +1,37 @@ +@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: enable an app + As an admin + I want to be able to enable a disabled app + So that I can use the app features again + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: Admin enables an app + Given app "comments" has been disabled + When the administrator enables app "comments" + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And app "comments" should be enabled + And the information for app "comments" should have a valid version + + + Scenario: subadmin tries to enable an app + Given user "subadmin" has been created with default attributes and without 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 HTTP status code should be "401" + And app "comments" should be disabled + + + Scenario: normal user tries to enable an app + Given user "brand-new-user" has been created with default attributes and without 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 HTTP status code should be "401" + And app "comments" should be disabled diff --git a/tests/acceptance/features/coreApiProvisioning-v1/enableUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/enableUser.feature new file mode 100644 index 00000000000..df17e2eb8d3 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/enableUser.feature @@ -0,0 +1,172 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: enable user + 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 + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin enables an user + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When the administrator enables user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be enabled + + + Scenario: admin enables an user with special characters in the username + Given these users have been created without skeleton files: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + And the following users have been disabled + | username | + | a@-+_.b | + | a space | + When the administrator enables the following users using the provisioning API + | username | + | a@-+_.b | + | a space | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should be enabled + | username | + | a@-+_.b | + | a space | + + + Scenario: admin enables another admin user + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + And user "another-admin" has been disabled + When the administrator enables user "another-admin" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "another-admin" should be enabled + + @notToImplementOnOCIS + Scenario: admin enables subadmins in the same group + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been added to group "brand-new-group" + And the administrator has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been disabled + When the administrator enables user "subadmin" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "subadmin" should be enabled + + + Scenario: admin tries to enable himself + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + And user "another-admin" has been disabled + When user "another-admin" tries to enable user "another-admin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-admin" should be disabled + + + Scenario: normal user tries to enable other user + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | 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 HTTP status code should be "401" + And user "Brian" should be disabled + + @notToImplementOnOCIS + Scenario: subadmin tries to enable himself + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been disabled + When user "subadmin" tries to enable user "subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "subadmin" should be disabled + + @notToImplementOnOCIS + Scenario: Making a web request with an enabled user + Given user "Alice" has been created with default attributes and without skeleton files + When user "Alice" sends HTTP method "GET" to URL "/index.php/apps/files" + Then the HTTP status code should be "200" + + + Scenario: normal user should not be able to enable himself + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + And user "Alice" has been disabled + When user "Alice" tries to enable user "Alice" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "Alice" should be disabled + + + Scenario: subadmin should be able to enable user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And user "Alice" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "Alice" has been disabled + When user "subadmin" tries to enable user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be enabled + + + Scenario: subadmin should not be able to enable user not in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "Alice" has been disabled + When user "subadmin" tries to enable user "Alice" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "Alice" should be disabled + + + Scenario: subadmin should be able to enable user with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And user "Alice" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "Alice" has been made a subadmin of group "brand-new-group" + And user "Alice" has been disabled + When user "subadmin" tries to enable user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Alice" should be enabled + + + Scenario: subadmin should not be able to enable another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + 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" + And user "another-subadmin" has been disabled + When user "subadmin" tries to enable user "another-subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-subadmin" should be disabled diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getAppInfo.feature b/tests/acceptance/features/coreApiProvisioning-v1/getAppInfo.feature new file mode 100644 index 00000000000..9e31e2b1d43 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/getAppInfo.feature @@ -0,0 +1,19 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get app info + As an admin + I want to be able to get app info + So that I can get the information of a specific application + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin gets app info + When the administrator gets the info of app "files" + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the XML "data" "id" value should be "files" + And the XML "data" "name" value should be "Files" + And the XML "data" "types" "element" value should be "filesystem" + And the XML "data" "dependencies" "owncloud" "min-version" attribute value should be a valid version string + And the XML "data" "dependencies" "owncloud" "max-version" attribute value should be a valid version string diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getApps.feature b/tests/acceptance/features/coreApiProvisioning-v1/getApps.feature new file mode 100644 index 00000000000..df2280d800f --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/getApps.feature @@ -0,0 +1,87 @@ +@api @provisioning_api-app-required @files_sharing-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get apps + As an admin + I want to be able to get the list of apps on my ownCloud + So that I can manage apps + + Background: + Given using OCS API version "1" + + @smokeTest @comments-app-required @files_trashbin-app-required @files_versions-app-required @systemtags-app-required + Scenario: admin gets enabled apps + When the administrator gets all enabled apps using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the apps returned by the API should include + | comments | + | dav | + | federatedfilesharing | + | federation | + | files | + | files_sharing | + | files_trashbin | + | files_versions | + | provisioning_api | + | systemtags | + | updatenotification | + + + Scenario: admin gets enabled apps - check for the minimal list of apps + When the administrator gets all enabled apps using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the apps returned by the API should include + | dav | + | federatedfilesharing | + | federation | + | files | + | files_sharing | + | updatenotification | + + @comments-app-required + Scenario: admin gets enabled apps when some app is disabled + Given app "comments" has been disabled + When the administrator gets all enabled apps using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the apps returned by the API should include + | dav | + | federatedfilesharing | + | federation | + | files | + | files_sharing | + | updatenotification | + And the apps returned by the API should not include + | comments | + + @comments-app-required + Scenario: admin gets disabled apps + Given app "comments" has been disabled + When the administrator gets all disabled apps using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the apps returned by the API should include + | comments | + And the apps returned by the API should not include + | dav | + | federatedfilesharing | + | federation | + | files | + | files_sharing | + | updatenotification | + + @comments-app-required + Scenario: admin gets all apps + Given app "comments" has been disabled + When the administrator gets all apps using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the apps returned by the API should include + | comments | + | dav | + | federatedfilesharing | + | federation | + | files | + | files_external | + | files_sharing | + | updatenotification | diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getSubAdmins.feature b/tests/acceptance/features/coreApiProvisioning-v1/getSubAdmins.feature new file mode 100644 index 00000000000..ad91ebc2b14 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/getSubAdmins.feature @@ -0,0 +1,55 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get subadmins + 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 + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin gets subadmin users of a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + When the administrator gets all the subadmins of group "brand-new-group" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the subadmin users returned by the API should be + | brand-new-user | + + + Scenario: admin tries to get subadmin users of a group which does not exist + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "nonexistentgroup" has been deleted + When the administrator gets all the subadmins of group "nonexistentgroup" using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" + And the API should not return any data + + + Scenario: subadmin tries to get other subadmins of the same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + 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 HTTP status code should be "401" + And the API should not return any data + + + Scenario: normal user tries to get the subadmins of the group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + 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 HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getUser.feature b/tests/acceptance/features/coreApiProvisioning-v1/getUser.feature new file mode 100644 index 00000000000..211e478bdff --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/getUser.feature @@ -0,0 +1,193 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: get user + 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 "1" + + @smokeTest + Scenario: admin gets an existing user + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | Brand New User | + When the administrator retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "Brand New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + + Scenario Outline: admin gets an existing user with special characters in the username + Given these users have been created without skeleton files: + | username | displayname | email | + | | | | + When the administrator retrieves the information of user "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "" + And the email address returned by the API should be "" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + Examples: + | username | displayname | email | + | a@-+_.b | A weird b | a.b@example.com | + | a space | A Space Name | a.space@example.com | + + + Scenario: admin gets an existing user, providing uppercase username in the URL + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | Brand New User | + When the administrator retrieves the information of user "BRAND-NEW-USER" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "Brand New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + + Scenario: admin tries to get a nonexistent user + When the administrator retrieves the information of user "not-a-user" using the provisioning API + Then the OCS status code should be "998" + And the HTTP status code should be "200" + And the API should not return any data + + @smokeTest @notToImplementOnOCIS + Scenario: a subadmin gets information of a user in their group + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | subadmin | Sub Admin | + | brand-new-user | New User | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + @notToImplementOnOCIS + Scenario: a subadmin tries to get information of a user not in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data + + + Scenario: a normal user tries to get information of another user + Given these users have been created with default attributes and without 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 HTTP status code should be "401" + And the API should not return any data + + @smokeTest + Scenario: a normal user gets their own information + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | New User | + When user "brand-new-user" retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + + Scenario Outline: a normal user gets their own information, providing uppercase username as authentication and in the URL + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | New User | + When user "" retrieves the information of user "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + Examples: + | username1 | username2 | + | BRAND-NEW-USER | brand-new-user | + | brand-new-user | BRAND-NEW-USER | + + + Scenario Outline: a mixed-case normal user gets their own information, providing lowercase and mixed-case username in the URL + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | Brand-New-User | New User | + When user "" retrieves the information of user "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + Examples: + | username1 | username2 | + | Brand-New-User | brand-new-user | + | brand-new-user | Brand-New-User | + + + Scenario: admin gets information of a user with admin permissions + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | Alice | Admin Alice | + And user "Alice" has been added to group "admin" + When the administrator retrieves the information of user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "Admin Alice" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + @notToImplementOnOCIS + Scenario: a subadmin should be able to get information of a user with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + And user "another-subadmin" has been added to group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" retrieves the information of user "another-subadmin" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the display name returned by the API should be "Regular User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + @notToImplementOnOCIS + Scenario: a subadmin should not be able to get information of another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" retrieves the information of user "another-subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioning-v1/getUsers.feature b/tests/acceptance/features/coreApiProvisioning-v1/getUsers.feature new file mode 100644 index 00000000000..35f83722a4d --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/getUsers.feature @@ -0,0 +1,53 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: get users + As an admin + I want to be able to list the users that exist + So that I can see who has access to ownCloud + + Background: + Given using OCS API version "1" + + @smokeTest @notToImplementOnOCIS + Scenario: admin gets all users and checks for all the users including the admin user + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator gets the list of all users using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the users returned by the API should be + | brand-new-user | + | admin | + + + Scenario: admin gets all users + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator gets the list of all users using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the users returned by the API should include + | brand-new-user | + + @smokeTest @notToImplementOnOCIS + Scenario: subadmin gets the users in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + When user "brand-new-user" gets the list of all users using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the users returned by the API should be + | brand-new-user | + + + Scenario: normal user tries to get other users + Given these users have been created with default attributes and without 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 HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioning-v1/removeSubAdmin.feature b/tests/acceptance/features/coreApiProvisioning-v1/removeSubAdmin.feature new file mode 100644 index 00000000000..7c938189603 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/removeSubAdmin.feature @@ -0,0 +1,61 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: remove subadmin + 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 + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin removes subadmin from a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + When the administrator removes user "brand-new-user" from being a subadmin of group "brand-new-group" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not be a subadmin of group "brand-new-group" + + + Scenario: subadmin tries to remove other subadmin in the group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + 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 HTTP status code should be "401" + And user "another-subadmin" should be a subadmin of group "brand-new-group" + + + Scenario: normal user tries to remove subadmin in the group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "brand-new-group" has been created + 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 HTTP status code should be "401" + And user "subadmin" should be a subadmin of group "brand-new-group" + + + Scenario: subadmin should not be able to remove subadmin of another group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group-1" has been created + And group "new-group-2" has been created + And user "subadmin" has been made a subadmin of group "new-group-1" + And user "another-subadmin" has been made a subadmin of group "new-group-2" + When user "subadmin" removes user "another-subadmin" from being a subadmin of group "new-group-2" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-subadmin" should be a subadmin of group "new-group-2" diff --git a/tests/acceptance/features/coreApiProvisioning-v1/resetUserPassword.feature b/tests/acceptance/features/coreApiProvisioning-v1/resetUserPassword.feature new file mode 100644 index 00000000000..4ccf8fe40c1 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v1/resetUserPassword.feature @@ -0,0 +1,164 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: reset user password + As an admin + I want to be able to reset a user's password + So that I can secure individual access to resources on the ownCloud server + + Background: + Given using OCS API version "1" + + @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57 + Scenario: reset user password + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + When the administrator resets the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + + @issue-37992 @notToImplementOnOCIS + Scenario: admin tries to reset the password of a user that does not exist + When the administrator resets the password of user "nonexistentuser" to "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + + @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS + Scenario: subadmin should be able to reset the password of a user in their group + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + | subadmin | %subadmin% | Sub Admin | sub.admin@oc.com.np | + And group "new-group" has been created + And user "brand-new-user" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + + @notToImplementOnOCIS + Scenario: subadmin should not be able to reset the password of a user not in their group + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + | subadmin | %subadmin% | Sub Admin | sub.admin@oc.com.np | + And group "new-group" has been created + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%alt1%" should not be able to download file "textfile0.txt" + + + Scenario: a user should not be able to reset the password of another user + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + | another-new-user | %altadmin% | Wanna Be Admin | wanna.be.admin@oc.com.np | + When user "another-new-user" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%alt1%" should not be able to download file "textfile0.txt" + + + Scenario: a user should be able to reset their own password + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + When user "brand-new-user" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + + @skipOnEncryptionType:user-keys @encryption-issue-57 + Scenario Outline: reset user password including emoji + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + When the administrator resets the password of user "brand-new-user" to "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + Examples: + | password | comment | + | 😛 😜 | smileys | + | 🐶🐱 🐭 | Animals | + | ⌚️ 📱 📲 💻 | objects | + | 🚴🏿‍♀️ 🚴‍♂️ | cycling | + + @skipOnOcV10 @issue-37992 + Scenario: admin tries to reset the password of a user that does not exist on ocis + When the administrator resets the password of user "nonexistentuser" to "%alt1%" using the provisioning API + Then the OCS status code should be "998" + And the HTTP status code should be "200" + + @skipOnEncryptionType:user-keys @encryption-issue-57 + Scenario: admin resets password of user with admin permissions + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | Alice | %regular% | New user | alice@oc.com.np | + And user "Alice" has been added to group "admin" + When the administrator resets the password of user "Alice" to "%alt1%" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "Alice" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "Alice" using password "%regular%" should not be able to download file "textfile0.txt" + + @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS + Scenario: subadmin should be able to reset the password of a user with subadmin permissions in their group + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + | subadmin | %subadmin% | Sub Admin | sub.admin@oc.com.np | + And group "new-group" has been created + And user "brand-new-user" has been added to group "new-group" + And user "brand-new-user" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + + @notToImplementOnOCIS + Scenario: subadmin should not be able to reset the password of another subadmin of same group + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | another-subadmin | %regular% | New user | another.subadmin@oc.com.np | + | subadmin | %subadmin% | Sub Admin | sub.admin@oc.com.np | + And group "new-group" has been created + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" tries to reset the password of user "another-subadmin" to "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the content of file "textfile0.txt" for user "another-subadmin" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line + But user "another-subadmin" using password "%alt1%" should not be able to download file "textfile0.txt" + + @notToImplementOnOCIS + Scenario: apps password is preserved when resetting login password + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user "brand-new-user" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password about user "brand-new-user" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + Then the HTTP status code of responses on all endpoints should be "207" + When user "brand-new-user" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + When the user "brand-new-user" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password about user "brand-new-user" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + Then the HTTP status code of responses on all endpoints should be "207" + diff --git a/tests/acceptance/features/coreApiProvisioning-v2/addUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/addUser.feature new file mode 100644 index 00000000000..c9d22d7318b --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/addUser.feature @@ -0,0 +1,224 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: add user + As an admin + I want to be able to add users + So that I can give people controlled individual access to resources on the ownCloud server + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin creates a user + Given user "brand-new-user" has been deleted + When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should exist + And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + + + Scenario: admin creates a user with special characters in the username + Given the following users have been deleted + | username | + | a@-+_.b | + | a space | + When the administrator sends a user creation request for the following users with password using the provisioning API + | username | password | + | a@-+_.b | %alt1% | + | a space | %alt1% | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should exist + | username | + | a@-+_.b | + | a space | + And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + | username | + | a@-+_.b | + | a space | + + + Scenario: admin tries to create an existing user + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And the API should not return any data + + + Scenario: admin tries to create an existing disabled user + Given user "brand-new-user" has been created with default attributes and without skeleton files + And user "brand-new-user" has been disabled + When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And the API should not return any data + + @notToImplementOnOCIS + Scenario: Admin creates a new user and adds him directly to a group + Given group "brand-new-group" has been created + When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" group "brand-new-group" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should belong to group "brand-new-group" + And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + + + Scenario: admin creates a user and specifies a password with special characters + When the administrator sends a user creation request for the following users with password using the provisioning API + | username | password | comment | + | brand-new-user1 | !@#$%^&*()-_+=[]{}:;,.<>?~/\ | special characters | + | brand-new-user2 | España§àôœ€ | special European and other characters | + | brand-new-user3 | नेपाली | Unicode | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should exist + | username | + | brand-new-user1 | + | brand-new-user2 | + | brand-new-user3 | + And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + | username | + | brand-new-user1 | + | brand-new-user2 | + | brand-new-user3 | + + + Scenario: admin creates a user and specifies an invalid password, containing just space + Given user "brand-new-user" has been deleted + When the administrator sends a user creation request for user "brand-new-user" password " " using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And user "brand-new-user" should not exist + + + Scenario: admin creates a user and specifies a password containing spaces + Given user "brand-new-user" has been deleted + When the administrator sends a user creation request for user "brand-new-user" password "spaces in my password" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should exist + And user "brand-new-user" should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + + + Scenario Outline: admin creates a user with username that contains capital letters + When the administrator sends a user creation request for user "" password "%alt1%" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Brand-New-User" should exist + And user "BRAND-NEW-USER" should exist + And user "brand-new-user" should exist + And user "brand-NEW-user" should exist + And user "BrAnD-nEw-UsEr" should exist + And the display name of user "brand-new-user" should be "" + Examples: + | display-name | + | Brand-New-User | + | BRAND-NEW-USER | + | brand-new-user | + | brand-NEW-user | + | BrAnD-nEw-UsEr | + + + Scenario: admin tries to create an existing user but with username containing capital letters + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator sends a user creation request for user "BRAND-NEW-USER" password "%alt1%" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And the API should not return any data + + + Scenario: admin creates a user with unusual username + Given the following users have been deleted + | username | + | user-1 | + | null | + | nil | + | 123 | + | -123 | + | 0.0 | + When the administrator sends a user creation request for the following users with password using the provisioning API + | username | password | + | user-1 | %alt1% | + | null | %alt1% | + | nil | %alt1% | + | 123 | %alt1% | + | -123 | %alt1% | + | 0.0 | %alt1% | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should exist + | username | + | user-1 | + | null | + | nil | + | 123 | + | -123 | + | 0.0 | + And the following users should be able to upload file "filesForUpload/textfile.txt" to "/textfile.txt" + | username | + | user-1 | + | null | + | nil | + | 123 | + | -123 | + | 0.0 | + + @notToImplementOnOCIS + Scenario: subadmin should not be able to create a user + Given user "brand-new-user" has been deleted + And user "subadmin" has been created with default attributes and without skeleton files + And group "group101" has been created + And user "subadmin" has been added to group "group101" + And user "subadmin" has been made a subadmin of group "group101" + When unauthorized user "subadmin" tries to create new user "brand-new-user" with password "%alt1%" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And user "brand-new-user" should not exist + + + Scenario: normal user should not be able to create another user + Given user "brand-new-user" has been deleted + And user "Alice" has been created with default attributes and without skeleton files + When unauthorized user "Alice" tries to create new user "brand-new-user" with password "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "brand-new-user" should not exist + + @notToImplementOnOCIS + Scenario: subadmin should be able to create a new user into their group + Given user "brand-new-user" has been deleted + And user "subadmin" has been created with default attributes and without skeleton files + And group "group101" has been created + And user "subadmin" has been added to group "group101" + And user "subadmin" has been made a subadmin of group "group101" + When the groupadmin "subadmin" sends a user creation request for user "brand-new-user" password "%alt1%" group "group101" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should exist + + @notToImplementOnOCIS + Scenario: subadmin should not be able to create a new user into other group + Given user "brand-new-user" has been deleted + And user "subadmin" has been created with default attributes and without skeleton files + And group "group101" has been created + And group "group102" has been created + And user "subadmin" has been added to group "group101" + And user "subadmin" has been made a subadmin of group "group101" + When the groupadmin "subadmin" tries to create new user "brand-new-user" password "%alt1%" in other group "group102" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And user "brand-new-user" should not exist + + @sqliteDB + Scenario: admin tries to create user with brackets in the username + When the administrator sends a user creation request for the following users with password using the provisioning API + | username | password | + | [user1] | %alt1% | + | [ user2 ] | %alt1% | + Then the OCS status code of responses on all endpoints should be "400" + And the HTTP status code of responses on all endpoints should be "400" + And the following users should not exist + | username | + | [user1] | + | [ user2 ] | diff --git a/tests/acceptance/features/coreApiProvisioning-v2/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/coreApiProvisioning-v2/apiProvisioningUsingAppPassword.feature new file mode 100644 index 00000000000..8fa3094c9b5 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/apiProvisioningUsingAppPassword.feature @@ -0,0 +1,90 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: access user provisioning API using app password + As an ownCloud user + I want to be able to use the provisioning API with an app password + So that I can make a client app or script for provisioning users/groups that can use an app password instead of my real password. + + Background: + Given using OCS API version "2" + + @smokeTest @notToImplementOnOCIS + Scenario: admin deletes the user + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And a new client token for the administrator has been generated + And a new browser session for the administrator has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v2.php/cloud/users/brand-new-user" with "DELETE" using the generated app password + Then the HTTP status code should be "200" + And user "brand-new-user" should not exist + + @notToImplementOnOCIS + Scenario: subadmin gets users in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "another-new-user" has been added to group "brand-new-group" + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + And a new client token for "brand-new-user" has been generated + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v2.php/cloud/users" with "GET" using the generated app password + Then the users returned by the API should be + | another-new-user | + And the HTTP status code should be "200" + + @smokeTest + Scenario: normal user gets their own information using the app password + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | New User | + And a new client token for "brand-new-user" has been generated + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v2.php/cloud/users/brand-new-user" with "GET" using the generated app password + Then the HTTP status code should be "200" + And the display name returned by the API should be "New User" + + @notToImplementOnOCIS + Scenario: subadmin tries to get users of other group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And group "another-new-group" has been created + And user "another-new-user" has been added to group "another-new-group" + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + And a new client token for "brand-new-user" has been generated + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v2.php/cloud/users" with "GET" using the generated app password + Then the users returned by the API should not include "another-new-user" + And the HTTP status code should be "200" + + + Scenario: normal user tries to get other user information using the app password + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And a new client token for "brand-new-user" has been generated + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user requests "/ocs/v2.php/cloud/users/another-new-user" with "GET" using the generated app password + Then the HTTP status code should be "401" + And the API should not return any data + + @notToImplementOnOCIS + Scenario: normal user gets his own resources using the app password + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + When the user "brand-new-user" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password about user "brand-new-user" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + Then the HTTP status code should be "207" diff --git a/tests/acceptance/features/coreApiProvisioning-v2/createSubAdmin.feature b/tests/acceptance/features/coreApiProvisioning-v2/createSubAdmin.feature new file mode 100644 index 00000000000..5665306bfc3 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/createSubAdmin.feature @@ -0,0 +1,60 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: create a subadmin + 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 + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin creates a subadmin + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + When the administrator makes user "brand-new-user" a subadmin of group "brand-new-group" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should be a subadmin of group "brand-new-group" + + + Scenario: admin tries to create a subadmin using a user which does not exist + Given user "nonexistentuser" has been deleted + And group "brand-new-group" has been created + When the administrator makes user "nonexistentuser" a subadmin of group "brand-new-group" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And user "nonexistentuser" should not be a subadmin of group "brand-new-group" + + + Scenario: admin tries to create a subadmin using a group which does not exist + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "not-group" has been deleted + When the administrator makes user "brand-new-user" a subadmin of group "not-group" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + + @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 without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "brand-new-group" has been created + 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" + And the HTTP status code should be "401" + And user "brand-new-user" should not be a subadmin of group "brand-new-group" + + + Scenario: normal user should not be able to make another user a subadmin + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "group101" has been created + When user "Alice" makes user "Brian" a subadmin of group "group101" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "Brian" should not be a subadmin of group "group101" diff --git a/tests/acceptance/features/coreApiProvisioning-v2/createSubAdminOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/createSubAdminOc10Issue31276.feature new file mode 100644 index 00000000000..d3574ad83c9 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/createSubAdminOc10Issue31276.feature @@ -0,0 +1,21 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + + @issue-31276 + Scenario: subadmin of a group tries to make another user subadmin of their group + Given using OCS API version "2" + And these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "brand-new-group" has been created + 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" + #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/coreApiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/deleteUser.feature new file mode 100644 index 00000000000..a7ccff614ce --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/deleteUser.feature @@ -0,0 +1,134 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: delete users + As an admin + I want to be able to delete users + So that I can remove user from ownCloud + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: Delete a user + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator deletes user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + + + Scenario: Delete a user with special characters in the username + Given these users have been created without skeleton files: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + When the administrator deletes the following users using the provisioning API + | username | + | a@-+_.b | + | a space | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not exist + | username | + | a@-+_.b | + | a space | + + + Scenario: Delete a user, and specify the user name in different case + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator deletes user "Brand-New-User" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + + @smokeTest @notToImplementOnOCIS + Scenario: subadmin deletes a user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "new-group" has been created + And user "brand-new-user" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to delete a user + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + When user "Alice" deletes user "Brian" using the provisioning API + Then the OCS status code should be "401" + And the HTTP status code should be "401" + And user "Brian" should exist + + @notToImplementOnOCIS + Scenario: administrator deletes another admin user + Given these users have been created with default attributes and without skeleton files: + | username | + | another-admin | + And user "another-admin" has been added to group "admin" + When the administrator deletes user "another-admin" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "another-admin" should not exist + + @notToImplementOnOCIS + Scenario: subadmin deletes a user with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group" has been created + And user "another-subadmin" has been added to group "new-group" + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "another-subadmin" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "another-subadmin" should not exist + + @notToImplementOnOCIS + Scenario: subadmin should not be able to delete another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group" has been created + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "another-subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-subadmin" should exist + + @notToImplementOnOCIS + Scenario: subadmin should not be able to delete a user with admin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-admin | + And user "another-admin" has been added to group "admin" + And group "new-group" has been created + And user "another-admin" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "another-admin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-admin" should exist + + @notToImplementOnOCIS + Scenario: subadmin should not be able to delete a user not in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "new-group" has been created + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" deletes user "brand-new-user" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "brand-new-user" should exist diff --git a/tests/acceptance/features/coreApiProvisioning-v2/deleteUserOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/deleteUserOc10Issue31276.feature new file mode 100644 index 00000000000..15fd81372e5 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/deleteUserOc10Issue31276.feature @@ -0,0 +1,18 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + + @issue-31276 + Scenario: normal user tries to delete a user + Given using OCS API version "2" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + When user "Alice" deletes user "Brian" 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 user "Brian" should exist diff --git a/tests/acceptance/features/coreApiProvisioning-v2/disableApp.feature b/tests/acceptance/features/coreApiProvisioning-v2/disableApp.feature new file mode 100644 index 00000000000..3094b5313ee --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/disableApp.feature @@ -0,0 +1,36 @@ +@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: disable an app + As an admin + I want to be able to disable an enabled app + So that I can stop the app features being used + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: Admin disables an app + Given app "comments" has been enabled + When the administrator disables app "comments" + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And app "comments" should be disabled + + @issue-31276 @skipOnOcV10 + Scenario: subadmin tries to disable an app + Given user "subadmin" has been created with default attributes and without 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 "401" + And the HTTP status code should be "401" + And app "comments" should be enabled + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to disable an app + Given user "brand-new-user" has been created with default attributes and without skeleton files + And app "comments" has been enabled + When user "brand-new-user" disables app "comments" + 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/coreApiProvisioning-v2/disableAppOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/disableAppOc10Issue31276.feature new file mode 100644 index 00000000000..079523c9727 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/disableAppOc10Issue31276.feature @@ -0,0 +1,30 @@ +@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: subadmin tries to disable an app + Given user "subadmin" has been created with default attributes and without 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" + #Then the OCS status code should be "401" + And the HTTP status code should be "401" + And app "comments" should be enabled + + @issue-31276 + Scenario: normal user tries to disable an app + Given user "brand-new-user" has been created with default attributes and without skeleton files + And app "comments" has been enabled + When user "brand-new-user" disables app "comments" + 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/coreApiProvisioning-v2/disableUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/disableUser.feature new file mode 100644 index 00000000000..88548da02aa --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/disableUser.feature @@ -0,0 +1,311 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: disable user + 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 + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin disables an user + Given user "Alice" has been created with default attributes and without skeleton files + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be disabled + + + Scenario: admin disables an user with special characters in the username + Given these users have been created without skeleton files: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + When the administrator disables the following users using the provisioning API + | username | + | a@-+_.b | + | a space | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should be disabled + | username | + | a@-+_.b | + | a space | + + @smokeTest @notToImplementOnOCIS + Scenario: Subadmin should be able to disable an user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And user "subadmin" has been added to group "brand-new-group" + And user "Alice" 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 "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be disabled + + @issue-31276 @skipOnOcV10 @notToImplementOnOCIS + Scenario: Subadmin should not be able to disable an user not in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And group "another-group" has been created + And user "subadmin" has been added to group "brand-new-group" + 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" + And the HTTP status code should be "401" + And user "Alice" should be enabled + + @issue-31276 @skipOnOcV10 @notToImplementOnOCIS + Scenario: Subadmins should not be able to disable users that have admin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-admin | + And group "brand-new-group" has been created + And user "another-admin" has been added to group "admin" + And user "subadmin" has been added to group "brand-new-group" + 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" + And the HTTP status code should be "401" + And user "another-admin" should be enabled + + + Scenario: Admin can disable another admin user + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When the administrator disables user "another-admin" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "another-admin" should be disabled + + @notToImplementOnOCIS + Scenario: Admin can disable subadmins in the same group + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been added to group "brand-new-group" + And the administrator has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When the administrator disables user "subadmin" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "subadmin" should be disabled + + + Scenario: Admin user cannot disable himself + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + When user "another-admin" disables user "another-admin" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And user "another-admin" should be enabled + + @issue-31276 @skipOnOcV10 + Scenario: disable an user with a regular user + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + When user "Alice" disables user "Brian" using the provisioning API + Then the OCS status code should be "401" + And the HTTP status code should be "401" + And user "Brian" should be enabled + + @notToImplementOnOCIS + Scenario: Subadmin should not be able to disable himself + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" 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 "subadmin" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And user "subadmin" should be enabled + + @smokeTest + Scenario: Making a web request with a disabled user + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" sends HTTP method "GET" to URL "/index.php/apps/files" + And the HTTP status code should be "403" + + + Scenario: Disabled user tries to download file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" downloads file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to upload file + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" uploads file with content "uploaded content" to "newTextFile.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to rename file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" moves file "/textfile0.txt" to "/renamedTextfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to move file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" moves file "/textfile0.txt" to "/PARENT/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to delete file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" deletes file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to share a file + Given user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the HTTP status code should be "401" + + + Scenario: Disabled user tries to share a folder + Given user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + Then the HTTP status code should be "401" + + + Scenario: getting shares shared by disabled user (to shares folder) + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And as "Brian" file "/Shares/textfile0.txt" should exist + And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" plus end-of-line + + @notToImplementOnOCIS + Scenario: getting shares shared by disabled user (to root) + Given user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And as "Brian" file "/textfile0.txt" should exist + And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" plus end-of-line + + + Scenario: getting shares shared by disabled user in a group (to shares folder) + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And group "group0" has been created + And user "Brian" has been added to group "group0" + And user "Alice" has shared folder "/PARENT" with group "group0" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And as "Brian" folder "/Shares/PARENT" should exist + And the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" plus end-of-line + + @notToImplementOnOCIS + Scenario: getting shares shared by disabled user in a group (to root) + Given user "Alice" has been created with default attributes and small skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And group "group0" has been created + And user "Brian" has been added to group "group0" + And user "Alice" has shared folder "/PARENT" with group "group0" + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And as "Brian" folder "/PARENT" should exist + And the content of file "/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" plus end-of-line + + + Scenario: Disabled user tries to create public link share + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has been disabled + When user "Alice" creates a public link share using the sharing API with settings + | path | textfile0.txt | + Then the HTTP status code should be "401" + + + Scenario Outline: getting public link share shared by disabled user using the new public WebDAV API + Given user "Alice" has been created with default attributes and small skeleton files + And user "Alice" has created a public link share with settings + | path | /textfile0.txt | + | permissions | read | + When the administrator disables user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be disabled + And the public should be able to download the last publicly shared file using the public WebDAV API without a password and the content should be "ownCloud test text file 0" plus end-of-line + Examples: + | dav_version | + | old | + | new | + + @notToImplementOnOCIS + Scenario: Subadmin should be able to disable user with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + And user "another-subadmin" has been added to group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" disables user "another-subadmin" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "another-subadmin" should be disabled + + @notToImplementOnOCIS + Scenario: Subadmin should not be able to disable another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" disables user "another-subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-subadmin" should be enabled + + + Scenario: normal user cannot disable himself + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + When user "Alice" disables user "Alice" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "Alice" should be enabled diff --git a/tests/acceptance/features/coreApiProvisioning-v2/disableUserOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/disableUserOc10Issue31276.feature new file mode 100644 index 00000000000..e5c89b61b3a --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/disableUserOc10Issue31276.feature @@ -0,0 +1,54 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: Subadmin should not be able to disable an user not in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And group "another-group" has been created + And user "subadmin" has been added to group "brand-new-group" + 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" + #Then the OCS status code should be "401" + And the HTTP status code should be "401" + And user "Alice" should be enabled + + @issue-31276 + Scenario: Subadmins should not be able to disable users that have admin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-admin | + And group "brand-new-group" has been created + And user "another-admin" has been added to group "admin" + And user "subadmin" has been added to group "brand-new-group" + 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" + #Then the OCS status code should be "401" + And the HTTP status code should be "401" + And user "another-admin" should be enabled + + @issue-31276 + Scenario: disable an user with a regular user + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + When user "Alice" disables user "Brian" 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 user "Brian" should be enabled diff --git a/tests/acceptance/features/coreApiProvisioning-v2/editUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/editUser.feature new file mode 100644 index 00000000000..957726ae4e0 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/editUser.feature @@ -0,0 +1,355 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: edit users + As an admin, subadmin or as myself + I want to be able to edit user information + So that I can keep the user information up-to-date + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: the administrator can edit a user email + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + + + Scenario Outline: the administrator can edit a user email of an user with special characters in the username + Given these users have been created without skeleton files: + | username | email | + | | | + When the administrator changes the email of user "" to "a-different-email@example.com" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the email address of user "" should be "a-different-email@example.com" + Examples: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + + @smokeTest + Scenario: the administrator can edit a user display (the API allows editing the "display name" by using the key word "display") + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator changes the display of user "brand-new-user" to "A New User" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the display name of user "brand-new-user" should be "A New User" + + + Scenario: the administrator can edit a user display name + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator changes the display name of user "brand-new-user" to "A New User" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the display name of user "brand-new-user" should be "A New User" + + + Scenario: the administrator can clear a user display name and then it defaults to the username + Given user "brand-new-user" has been created with default attributes and without skeleton files + And the administrator has changed the display name of user "brand-new-user" to "A New User" + When the administrator changes the display name of user "brand-new-user" to "" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the display name of user "brand-new-user" should be "brand-new-user" + + @smokeTest + Scenario: the administrator can edit a user quota + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator changes the quota of user "brand-new-user" to "12MB" using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the quota definition of user "brand-new-user" should be "12 MB" + + + Scenario: the administrator can override existing user email + Given user "brand-new-user" has been created with default attributes and without skeleton files + And the administrator has changed the email of user "brand-new-user" to "brand-new-user@gmail.com" + And the OCS status code should be "200" + And the HTTP status code should be "200" + When the administrator changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + + + Scenario: the administrator can clear an existing user email + Given user "brand-new-user" has been created with default attributes and without skeleton files + And the administrator has changed the email of user "brand-new-user" to "brand-new-user@gmail.com" + And the OCS status code should be "200" + And the HTTP status code should be "200" + When the administrator changes the email of user "brand-new-user" to "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the email address of user "brand-new-user" should be "" + + @smokeTest @notToImplementOnOCIS + Scenario: a subadmin should be able to edit the user information in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "new-group" has been created + And user "brand-new-user" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" changes the quota of user "brand-new-user" to "12MB" using the provisioning API + And user "subadmin" changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API + And user "subadmin" changes the display of user "brand-new-user" to "Anne Brown" using the provisioning API + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the display name of user "brand-new-user" should be "Anne Brown" + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + And the quota definition of user "brand-new-user" should be "12 MB" + + + Scenario: a normal user should be able to change their email address + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" changes the email of user "brand-new-user" to "brand-new-user@example.com" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the attributes of user "brand-new-user" returned by the API should include + | email | brand-new-user@example.com | + And the email address of user "brand-new-user" should be "brand-new-user@example.com" + + + Scenario Outline: a normal user should be able to change their display name + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" changes the display name of user "brand-new-user" to "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the attributes of user "brand-new-user" returned by the API should include + | displayname | | + And the display name of user "brand-new-user" should be "" + Examples: + | display-name | + | Alan Border | + | Phil Cyclist 🚴 | + + + Scenario: a normal user should not be able to change their quota + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" changes the quota of user "brand-new-user" to "12MB" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "brand-new-user" returned by the API should include + | quota definition | default | + And the quota definition of user "brand-new-user" should be "default" + + @notToImplementOnOCIS + Scenario: the administrator can edit user information with admin permissions + Given these users have been created with default attributes and without skeleton files: + | username | + | another-admin | + And user "another-admin" has been added to group "admin" + When user "another-admin" changes the quota of user "another-admin" to "12MB" using the provisioning API + And user "another-admin" changes the email of user "another-admin" to "another-admin@example.com" using the provisioning API + And user "another-admin" changes the display of user "another-admin" to "Anne Brown" using the provisioning API + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the display name of user "another-admin" should be "Anne Brown" + And the email address of user "another-admin" should be "another-admin@example.com" + And the quota definition of user "another-admin" should be "12 MB" + + @notToImplementOnOCIS + Scenario: a subadmin should be able to edit user information with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group" has been created + And user "another-subadmin" has been added to group "new-group" + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" changes the quota of user "another-subadmin" to "12MB" using the provisioning API + And user "subadmin" changes the email of user "another-subadmin" to "brand-new-user@example.com" using the provisioning API + And user "subadmin" changes the display of user "another-subadmin" to "Anne Brown" using the provisioning API + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the display name of user "another-subadmin" should be "Anne Brown" + And the email address of user "another-subadmin" should be "brand-new-user@example.com" + And the quota definition of user "another-subadmin" should be "12 MB" + + @notToImplementOnOCIS + Scenario: a subadmin should not be able to edit user information of another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group" has been created + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" changes the quota of user "another-subadmin" to "12MB" using the provisioning API + And user "subadmin" changes the email of user "another-subadmin" to "brand-new-user@example.com" using the provisioning API + And user "subadmin" changes the display of user "another-subadmin" to "Anne Brown" using the provisioning API + Then the OCS status code of responses on all endpoints should be "997" + And the HTTP status code of responses on all endpoints should be "401" + And the display name of user "another-subadmin" should be "Regular User" + And the email address of user "another-subadmin" should be "another-subadmin@owncloud.com" + And the quota definition of user "another-subadmin" should be "default" + + + Scenario: a normal user should not be able to edit another user's information + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + When user "Alice" tries to change the display name of user "Brian" to "New Brian" using the provisioning API + And user "Alice" tries to change the email of user "Brian" to "brian-new-email@example.com" using the provisioning API + Then the OCS status code of responses on all endpoints should be "997" + And the HTTP status code of responses on all endpoints should be "401" + And the display name of user "Brian" should not have changed + And the email address of user "Brian" should not have changed + + + Scenario: Admin gives access to users to change their email address + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_mail_address" with value "true" and type "boolean" + When user "Alice" changes the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | email | alice@gmail.com | + And the email address of user "Alice" should be "alice@gmail.com" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" + When user "Alice" tries to change the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "Alice" returned by the API should include + | email | alice@example.org | + And the email address of user "Alice" should not have changed + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address, admin can still change the email address + Given user "Alice" has been created with default attributes and without skeleton files + When the administrator updates system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" using the occ command + And the administrator changes the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | email | alice@gmail.com | + And the email address of user "Alice" should be "alice@gmail.com" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address, admin can still change their own email address + When the administrator updates system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" using the occ command + And the administrator changes the email of user "admin" to "something@example.com" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the attributes of user "admin" returned by the API should include + | email | something@example.com | + And the email address of user "admin" should be "something@example.com" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address, subadmin can still change the email address of a user they are subadmin of + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | Alice | + And group "new-group" has been created + And user "Alice" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When the administrator updates system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" using the occ command + And user "subadmin" changes the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | email | alice@gmail.com | + And the email address of user "Alice" should be "alice@gmail.com" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their email address, subadmin cannot change the email address of a user they are not subadmin of + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | Alice | + And group "new-group" has been created + And user "subadmin" has been made a subadmin of group "new-group" + # Note: Alice is not a member of new-group, so subadmin does not a priv to change the email address of Alice + When the administrator updates system config key "allow_user_to_change_mail_address" with value "false" and type "boolean" using the occ command + And user "subadmin" tries to change the email of user "Alice" to "alice@gmail.com" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "Alice" returned by the API should include + | email | alice@example.org | + And the email address of user "Alice" should not have changed + + + Scenario: Admin gives access to users to change their display name + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_display_name" with value "true" and type "boolean" + When user "Alice" changes the display of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | displayname | Alice Wonderland | + And the display name of user "Alice" should be "Alice Wonderland" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has updated system config key "allow_user_to_change_display_name" with value "false" and type "boolean" + When user "Alice" tries to change the display name of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "Alice" returned by the API should include + | displayname | Alice Hansen | + And the display name of user "Alice" should not have changed + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name, admin can still change display name + Given user "Alice" has been created with default attributes and without skeleton files + When the administrator updates system config key "allow_user_to_change_display_name" with value "false" and type "boolean" using the occ command + And the administrator changes the display name of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the attributes of user "Alice" returned by the API should include + | displayname | Alice Wonderland | + And the display name of user "Alice" should be "Alice Wonderland" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name, admin can still change their own display name + When the administrator updates system config key "allow_user_to_change_display_name" with value "false" and type "boolean" using the occ command + And the administrator changes the display name of user "admin" to "The Administrator" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the attributes of user "admin" returned by the API should include + | displayname | The Administrator | + And the display name of user "admin" should be "The Administrator" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name, subadmin can still change the display name of a user they are subadmin of + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | Alice | + And group "new-group" has been created + And user "Alice" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When the administrator updates system config key "allow_user_to_change_display_name" with value "false" and type "boolean" using the occ command + And user "subadmin" changes the display name of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + | displayname | Alice Wonderland | + And the display name of user "Alice" should be "Alice Wonderland" + + @notToImplementOnOCIS + Scenario: Admin does not give access to users to change their display name, subadmin cannot change the display name of a user they are not subadmin of + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | Alice | + And group "new-group" has been created + And user "subadmin" has been made a subadmin of group "new-group" + # Note: Alice is not a member of new-group, so subadmin does not a priv to change the email address of Alice + When the administrator updates system config key "allow_user_to_change_display_name" with value "false" and type "boolean" using the occ command + And user "subadmin" tries to change the display name of user "Alice" to "Alice Wonderland" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the attributes of user "Alice" returned by the API should include + | displayname | Alice Hansen | + And the display name of user "Alice" should not have changed diff --git a/tests/acceptance/features/coreApiProvisioning-v2/enableApp.feature b/tests/acceptance/features/coreApiProvisioning-v2/enableApp.feature new file mode 100644 index 00000000000..00294a4857d --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/enableApp.feature @@ -0,0 +1,36 @@ +@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: enable an app + As an admin + I want to be able to enable a disabled app + So that I can use the app features again + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: Admin enables an app + Given app "comments" has been disabled + When the administrator enables app "comments" + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And app "comments" should be enabled + + @issue-31276 @skipOnOcV10 + Scenario: subadmin tries to enable an app + Given user "subadmin" has been created with default attributes and without 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 "401" + And the HTTP status code should be "401" + And app "comments" should be disabled + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to enable an app + Given user "brand-new-user" has been created with default attributes and without skeleton files + And app "comments" has been disabled + When user "brand-new-user" enables app "comments" + 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/coreApiProvisioning-v2/enableAppOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/enableAppOc10Issue31276.feature new file mode 100644 index 00000000000..2899caa61ff --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/enableAppOc10Issue31276.feature @@ -0,0 +1,30 @@ +@api @provisioning_api-app-required @comments-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: subadmin tries to enable an app + Given user "subadmin" has been created with default attributes and without 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" + #Then the OCS status code should be "401" + And the HTTP status code should be "401" + And app "comments" should be disabled + + @issue-31276 + Scenario: normal user tries to enable an app + Given user "brand-new-user" has been created with default attributes and without skeleton files + And app "comments" has been disabled + When user "brand-new-user" enables app "comments" + 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/coreApiProvisioning-v2/enableUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/enableUser.feature new file mode 100644 index 00000000000..7db56e2e345 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/enableUser.feature @@ -0,0 +1,172 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: enable user + 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 + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin enables an user + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When the administrator enables user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be enabled + + + Scenario: admin enables an user with special characters in the username + Given these users have been created without skeleton files: + | username | email | + | a@-+_.b | a.b@example.com | + | a space | a.space@example.com | + And the following users have been disabled + | username | + | a@-+_.b | + | a space | + When the administrator enables the following users using the provisioning API + | username | + | a@-+_.b | + | a space | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should be enabled + | username | + | a@-+_.b | + | a space | + + + Scenario: admin enables another admin user + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + And user "another-admin" has been disabled + When the administrator enables user "another-admin" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "another-admin" should be enabled + + @notToImplementOnOCIS + Scenario: admin enables subadmins in the same group + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been added to group "brand-new-group" + And the administrator has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been disabled + When the administrator enables user "subadmin" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "subadmin" should be enabled + + + Scenario: admin tries to enable himself + Given user "another-admin" has been created with default attributes and without skeleton files + And user "another-admin" has been added to group "admin" + And user "another-admin" has been disabled + When user "another-admin" tries to enable user "another-admin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + Then user "another-admin" should be disabled + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to enable other user + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | 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" + And the HTTP status code should be "401" + And user "Brian" should be disabled + + @notToImplementOnOCIS + Scenario: subadmin tries to enable himself + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been disabled + When user "subadmin" tries to enable user "subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "subadmin" should be disabled + + @notToImplementOnOCIS + Scenario: Making a web request with an enabled user + Given user "Alice" has been created with default attributes and without skeleton files + When user "Alice" sends HTTP method "GET" to URL "/index.php/apps/files" + Then the HTTP status code should be "200" + + @notToImplementOnOCIS + Scenario: normal user should not be able to enable himself + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + And user "Alice" has been disabled + When user "Alice" tries to enable user "Alice" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "Alice" should be disabled + + @notToImplementOnOCIS + Scenario: subadmin should be able to enable user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And user "Alice" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "Alice" has been disabled + When user "subadmin" tries to enable user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be enabled + + @notToImplementOnOCIS + Scenario: subadmin should not be able to enable user not in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "Alice" has been disabled + When user "subadmin" tries to enable user "Alice" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "Alice" should be disabled + + @notToImplementOnOCIS + Scenario: subadmin should be able to enable user with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | subadmin | + And group "brand-new-group" has been created + And user "Alice" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "Alice" has been made a subadmin of group "brand-new-group" + And user "Alice" has been disabled + When user "subadmin" tries to enable user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "Alice" should be enabled + + @notToImplementOnOCIS + Scenario: subadmin should not be able to enable another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + 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" + And user "another-subadmin" has been disabled + When user "subadmin" tries to enable user "another-subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-subadmin" should be disabled diff --git a/tests/acceptance/features/coreApiProvisioning-v2/enableUserOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/enableUserOc10Issue31276.feature new file mode 100644 index 00000000000..a0a23bdeeb7 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/enableUserOc10Issue31276.feature @@ -0,0 +1,19 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + + @issue-31276 + Scenario: normal user tries to enable other user + Given using OCS API version "2" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | 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" + #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/coreApiProvisioning-v2/getAppInfo.feature b/tests/acceptance/features/coreApiProvisioning-v2/getAppInfo.feature new file mode 100644 index 00000000000..9d50443ceab --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/getAppInfo.feature @@ -0,0 +1,19 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get app info + As an admin + I want to be able to get app info + So that I can get the information of a specific application + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin gets app info + When the administrator gets the info of app "files" + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the XML "data" "id" value should be "files" + And the XML "data" "name" value should be "Files" + And the XML "data" "types" "element" value should be "filesystem" + And the XML "data" "dependencies" "owncloud" "min-version" attribute value should be a valid version string + And the XML "data" "dependencies" "owncloud" "max-version" attribute value should be a valid version string diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getApps.feature b/tests/acceptance/features/coreApiProvisioning-v2/getApps.feature new file mode 100644 index 00000000000..2c35f17a51e --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/getApps.feature @@ -0,0 +1,87 @@ +@api @provisioning_api-app-required @files_sharing-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get apps + As an admin + I want to be able to get the list of apps on my ownCloud + So that I can manage apps + + Background: + Given using OCS API version "2" + + @smokeTest @comments-app-required @files_trashbin-app-required @files_versions-app-required @systemtags-app-required + Scenario: admin gets enabled apps + When the administrator gets all enabled apps using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the apps returned by the API should include + | comments | + | dav | + | federatedfilesharing | + | federation | + | files | + | files_sharing | + | files_trashbin | + | files_versions | + | provisioning_api | + | systemtags | + | updatenotification | + + + Scenario: admin gets enabled apps - check for the minimal list of apps + When the administrator gets all enabled apps using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the apps returned by the API should include + | dav | + | federatedfilesharing | + | federation | + | files | + | files_sharing | + | updatenotification | + + @comments-app-required + Scenario: admin gets enabled apps when some app is disabled + Given app "comments" has been disabled + When the administrator gets all enabled apps using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the apps returned by the API should include + | dav | + | federatedfilesharing | + | federation | + | files | + | files_sharing | + | updatenotification | + And the apps returned by the API should not include + | comments | + + @comments-app-required + Scenario: admin gets disabled apps + Given app "comments" has been disabled + When the administrator gets all disabled apps using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the apps returned by the API should include + | comments | + And the apps returned by the API should not include + | dav | + | federatedfilesharing | + | federation | + | files | + | files_sharing | + | updatenotification | + + @comments-app-required + Scenario: admin gets all apps + Given app "comments" has been disabled + When the administrator gets all apps using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the apps returned by the API should include + | comments | + | dav | + | federatedfilesharing | + | federation | + | files | + | files_external | + | files_sharing | + | updatenotification | diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getSubAdmins.feature b/tests/acceptance/features/coreApiProvisioning-v2/getSubAdmins.feature new file mode 100644 index 00000000000..f7cc37c16bd --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/getSubAdmins.feature @@ -0,0 +1,55 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get subadmins + 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 + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin gets subadmin users of a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + When the administrator gets all the subadmins of group "brand-new-group" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the subadmin users returned by the API should be + | brand-new-user | + + + Scenario: admin tries to get subadmin users of a group which does not exist + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "nonexistentgroup" has been deleted + When the administrator gets all the subadmins of group "nonexistentgroup" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And the API should not return any data + + @issue-31276 @skipOnOcV10 + Scenario: subadmin tries to get other subadmins of the same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + 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" + And the HTTP status code should be "401" + And the API should not return any data + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to get the subadmins of the group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + 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" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getSubAdminsOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/getSubAdminsOc10Issue31276.feature new file mode 100644 index 00000000000..469d8e03e90 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/getSubAdminsOc10Issue31276.feature @@ -0,0 +1,37 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: subadmin tries to get other subadmins of the same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + 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" + #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 the subadmins of the group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + 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" + #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/coreApiProvisioning-v2/getUser.feature b/tests/acceptance/features/coreApiProvisioning-v2/getUser.feature new file mode 100644 index 00000000000..e12ed60c397 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/getUser.feature @@ -0,0 +1,211 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: get user + 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" + + @smokeTest + Scenario: admin gets an existing user + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | Brand New User | + When the administrator retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "Brand New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + + Scenario Outline: admin gets an existing user with special characters in the username + Given these users have been created without skeleton files: + | username | displayname | email | + | | | | + When the administrator retrieves the information of user "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "" + And the email address returned by the API should be "" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + Examples: + | username | displayname | email | + | a@-+_.b | A weird b | a.b@example.com | + | a space | A Space Name | a.space@example.com | + + + Scenario: admin gets an existing user, providing uppercase username in the URL + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | Brand New User | + When the administrator retrieves the information of user "BRAND-NEW-USER" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "Brand New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + + Scenario: admin tries to get a nonexistent user + When the administrator retrieves the information of user "not-a-user" using the provisioning API + Then the OCS status code should be "404" + And the HTTP status code should be "404" + And the API should not return any data + + @smokeTest @notToImplementOnOCIS + Scenario: a subadmin gets information of a user in their group + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | subadmin | Sub Admin | + | brand-new-user | New User | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + @notToImplementOnOCIS + Scenario: a subadmin tries to get information of a user not in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data + + @issue-31276 @skipOnOcV10 + Scenario: a normal user tries to get information of another user + Given these users have been created with default attributes and without 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 "401" + And the HTTP status code should be "401" + And the API should not return any data + + @smokeTest + Scenario: a normal user gets their own information + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | New User | + When user "brand-new-user" retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + + Scenario: a normal user gets their own information, providing uppercase username as authentication + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | New User | + When user "BRAND-NEW-USER" retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + + Scenario: a normal user gets their own information, providing uppercase username in the URL + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | brand-new-user | New User | + When user "brand-new-user" retrieves the information of user "BRAND-NEW-USER" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + + Scenario: a mixed-case normal user gets their own information, providing lowercase username in the URL + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | Brand-New-User | New User | + When user "Brand-New-User" retrieves the information of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + + Scenario: a mixed-case normal user gets their own information, providing the mixed-case username in the URL + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | Brand-New-User | New User | + When user "brand-new-user" retrieves the information of user "Brand-New-User" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "New User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + @notToImplementOnOCIS + Scenario: admin gets information of a user with admin permissions + Given these users have been created with default attributes and without skeleton files: + | username | displayname | + | Alice | Admin Alice | + And user "Alice" has been added to group "admin" + When the administrator retrieves the information of user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "Admin Alice" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + @notToImplementOnOCIS + Scenario: a subadmin should be able to get information of a user with subadmin permissions in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + And user "another-subadmin" has been added to group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" retrieves the information of user "another-subadmin" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the display name returned by the API should be "Regular User" + And the quota definition returned by the API should be "default" + And the free, used, total and relative quota returned by the API should exist and be valid numbers + And the last login returned by the API should be a current Unix timestamp + + @notToImplementOnOCIS + Scenario: a subadmin should not be able to get information of another subadmin of same group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" retrieves the information of user "another-subadmin" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getUserOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/getUserOc10Issue31276.feature new file mode 100644 index 00000000000..37e9807dc39 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/getUserOc10Issue31276.feature @@ -0,0 +1,20 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: a normal user tries to get information of another user + Given these users have been created with default attributes and without 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" + #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/coreApiProvisioning-v2/getUsers.feature b/tests/acceptance/features/coreApiProvisioning-v2/getUsers.feature new file mode 100644 index 00000000000..62142a441e2 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/getUsers.feature @@ -0,0 +1,53 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: get users + As an admin + I want to be able to list the users that exist + So that I can see who has access to ownCloud + + Background: + Given using OCS API version "2" + + @smokeTest @notToImplementOnOCIS + Scenario: admin gets all users where default admin user exists + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator gets the list of all users using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the users returned by the API should be + | brand-new-user | + | admin | + + + Scenario: admin gets all users + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator gets the list of all users using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the users returned by the API should include + | brand-new-user | + + @smokeTest @notToImplementOnOCIS + Scenario: subadmin gets the users in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + When user "brand-new-user" gets the list of all users using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the users returned by the API should be + | brand-new-user | + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to get other users + Given these users have been created with default attributes and without 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" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioning-v2/getUsersOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/getUsersOc10Issue31276.feature new file mode 100644 index 00000000000..6785226cefe --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/getUsersOc10Issue31276.feature @@ -0,0 +1,20 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 without 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/coreApiProvisioning-v2/removeSubAdmin.feature b/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdmin.feature new file mode 100644 index 00000000000..c70d770f1ce --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdmin.feature @@ -0,0 +1,61 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: remove subadmin + 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 + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin removes subadmin from a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + When the administrator removes user "brand-new-user" from being a subadmin of group "brand-new-group" using the provisioning API + Then the OCS status code should be "200" + 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 @skipOnOcV10 + Scenario: subadmin tries to remove other subadmin in the group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + 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" + And the HTTP status code should be "401" + And user "another-subadmin" should be a subadmin of group "brand-new-group" + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to remove subadmin in the group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "brand-new-group" has been created + 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" + And the HTTP status code should be "401" + And user "subadmin" should be a subadmin of group "brand-new-group" + + + Scenario: subadmin should not be able to remove subadmin of another group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "new-group-1" has been created + And group "new-group-2" has been created + And user "subadmin" has been made a subadmin of group "new-group-1" + And user "another-subadmin" has been made a subadmin of group "new-group-2" + When user "subadmin" removes user "another-subadmin" from being a subadmin of group "new-group-2" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-subadmin" should be a subadmin of group "new-group-2" diff --git a/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdminOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdminOc10Issue31276.feature new file mode 100644 index 00000000000..4b4d99f1312 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/removeSubAdminOc10Issue31276.feature @@ -0,0 +1,38 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: subadmin tries to remove other subadmin in the group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | another-subadmin | + And group "brand-new-group" has been created + 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" + #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 + Scenario: normal user tries to remove subadmin in the group + Given these users have been created with default attributes and without skeleton files: + | username | + | subadmin | + | brand-new-user | + And group "brand-new-group" has been created + 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" + #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/coreApiProvisioning-v2/resetUserPassword.feature b/tests/acceptance/features/coreApiProvisioning-v2/resetUserPassword.feature new file mode 100644 index 00000000000..db4c8a5fd12 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioning-v2/resetUserPassword.feature @@ -0,0 +1,157 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: reset user password + As an admin + I want to be able to reset a user's password + So that I can secure individual access to resources on the ownCloud server + + Background: + Given using OCS API version "2" + + @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57 + Scenario: reset user password + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + When the administrator resets the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + + @notToImplementOnOCIS @issue-37992 + Scenario: admin tries to reset the password of a user that does not exist + When the administrator resets the password of user "nonexistentuser" to "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + + @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS + Scenario: subadmin should be able to reset the password of a user in their group + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + | subadmin | %subadmin% | Sub Admin | sub.admin@oc.com.np | + And group "new-group" has been created + And user "brand-new-user" has been added to group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + + @notToImplementOnOCIS + Scenario: subadmin should not be able to reset the password of a user not in their group + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + | subadmin | %subadmin% | Sub Admin | sub.admin@oc.com.np | + And group "new-group" has been created + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%alt1%" should not be able to download file "textfile0.txt" + + + Scenario: a user should not be able to reset the password of another user + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + | another-new-user | %altadmin% | Wanna Be Admin | wanna.be.admin@oc.com.np | + When user "another-new-user" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%alt1%" should not be able to download file "textfile0.txt" + + + Scenario: a user should be able to reset their own password + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + When user "brand-new-user" resets the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + + @skipOnEncryptionType:user-keys @encryption-issue-57 + Scenario Outline: reset user password including emoji + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + When the administrator resets the password of user "brand-new-user" to "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + Examples: + | password | comment | + | 😛 😜 | smileys | + | 🐶🐱 🐭 | Animals | + | ⌚️ 📱 📲 💻 | objects | + | 🚴🏿‍♀️ 🚴‍♂️ | cycling | + + @skipOnOcV10 @issue-37992 + Scenario: admin tries to reset the password of a user that does not exist on OCIS + When the administrator resets the password of user "nonexistentuser" to "%alt1%" using the provisioning API + Then the OCS status code should be "998" + And the HTTP status code should be "404" + + @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS + Scenario: admin resets password of user with admin permissions + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | Alice | %regular% | New user | alice@oc.com.np | + And user "Alice" has been added to group "admin" + When the administrator resets the password of user "Alice" to "%alt1%" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "Alice" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "Alice" using password "%regular%" should not be able to download file "textfile0.txt" + + @skipOnEncryptionType:user-keys @encryption-issue-57 @notToImplementOnOCIS + Scenario: subadmin should be able to reset the password of a user with subadmin permissions in their group + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + | subadmin | %subadmin% | Sub Admin | sub.admin@oc.com.np | + And group "new-group" has been created + And user "brand-new-user" has been added to group "new-group" + And user "brand-new-user" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" tries to reset the password of user "brand-new-user" to "%alt1%" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the content of file "textfile0.txt" for user "brand-new-user" using password "%alt1%" should be "ownCloud test text file 0" plus end-of-line + But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt" + + @notToImplementOnOCIS + Scenario: subadmin should not be able to reset the password of another subadmin of same group + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | another-subadmin | %regular% | New user | another.subadmin@oc.com.np | + | subadmin | %subadmin% | Sub Admin | sub.admin@oc.com.np | + And group "new-group" has been created + And user "another-subadmin" has been made a subadmin of group "new-group" + And user "subadmin" has been made a subadmin of group "new-group" + When user "subadmin" tries to reset the password of user "another-subadmin" to "%alt1%" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the content of file "textfile0.txt" for user "another-subadmin" using password "%regular%" should be "ownCloud test text file 0" plus end-of-line + But user "another-subadmin" using password "%alt1%" should not be able to download file "textfile0.txt" + + @notToImplementOnOCIS + Scenario: apps password is preserved when resetting login password + Given these users have been created with small skeleton files: + | username | password | displayname | email | + | brand-new-user | %regular% | New user | brand.new.user@oc.com.np | + And a new browser session for "brand-new-user" has been started + And the user has generated a new app password named "my-client" + And user "brand-new-user" has reset the password of user "brand-new-user" to "%alt1%" + When the user "brand-new-user" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password about user "brand-new-user" + | endpoint | + | /remote.php/dav/files/%username%/textfile0.txt | + Then the HTTP status code should be "207" + diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroup.feature new file mode 100644 index 00000000000..69f824f3a34 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroup.feature @@ -0,0 +1,187 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +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" + + @smokeTest + Scenario: admin creates a group + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | simplegroup | nothing special here | + | España§àôœ€ | special European and other characters | + | नेपाली | Unicode group name | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | simplegroup | + | España§àôœ€ | + | नेपाली | + + @sqliteDB + Scenario: admin creates a group with special characters + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | brand-new-group | dash | + | the.group | dot | + | left,right | comma | + | 0 | The "false" group | + | Finance (NP) | Space and brackets | + | Admin&Finance | Ampersand | + | admin:Pokhara@Nepal | Colon and @ | + | maint+eng | Plus sign | + | $x<=>[y*z^2]! | Maths symbols | + | Mgmt\Middle | Backslash | + | 😅 😆 | emoji | + | [group1] | brackets | + | group [ 2 ] | bracketsAndSpace | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | brand-new-group | + | the.group | + | left,right | + | 0 | + | Finance (NP) | + | Admin&Finance | + | admin:Pokhara@Nepal | + | maint+eng | + | $x<=>[y*z^2]! | + | Mgmt\Middle | + | 😅 😆 | + | [group1] | + | group [ 2 ] | + + @toImplementOnOCIS @issue-product-284 + Scenario: admin creates a group with % and # in name + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | maintenance#123 | Hash sign | + | 50%pass | Percent sign (special escaping happens) | + | 50%25=0 | %25 literal looks like an escaped "%" | + | 50%2Fix | %2F literal looks like an escaped slash | + | 50%2Eagle | %2E literal looks like an escaped "." | + | staff?group | Question mark | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | maintenance#123 | + | 50%pass | + | 50%25=0 | + | 50%2Fix | + | 50%2Eagle | + | staff?group | + + @toImplementOnOCIS + Scenario: group names are case-sensitive, multiple groups can exist with different upper and lower case names + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | + | Case-Sensitive-Group1 | + | case-sensitive-group1 | + | Case-Sensitive-Group2 | + | CASE-SENSITIVE-GROUP2 | + | case-sensitive-group3 | + | CASE-SENSITIVE-GROUP3 | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | Case-Sensitive-Group1 | + | case-sensitive-group1 | + | Case-Sensitive-Group2 | + | CASE-SENSITIVE-GROUP2 | + | case-sensitive-group3 | + | CASE-SENSITIVE-GROUP3 | + And these groups should not exist: + | groupname | + | CASE-SENSITIVE-GROUP1 | + | case-sensitive-group2 | + | Case-Sensitive-Group3 | + + @issue-31015 @skipOnOcV10 @toImplementOnOCIS @issue-product-284 + Scenario: admin creates a group with a forward-slash in the group name + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | var/../etc | using slash-dot-dot | + | priv/subadmins/1 | Subadmins mentioned not at the end | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + + # 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 @notToImplementOnOCIS + Scenario: admin tries to create a group with name ending in "/subadmins" + Given group "brand-new-group" has been created + When the administrator tries to send a group creation request for group "priv/subadmins" using the provisioning API + Then the OCS status code should be "102" + And the HTTP status code should be "200" + And group "priv/subadmins" should not exist + + + Scenario: admin tries to create a group that already exists + Given group "brand-new-group" has been created + When the administrator sends a group creation request for group "brand-new-group" using the provisioning API + Then the OCS status code should be "102" + And the HTTP status code should be "200" + And group "brand-new-group" should exist + + + Scenario: normal user tries to create a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" tries to send a group creation request for group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And group "brand-new-group" should not exist + + @notToImplementOnOCIS + Scenario: subadmin tries to create a group + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" tries to send a group creation request for group "another-new-group" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And group "another-new-group" should not exist + + + Scenario: admin tries to create a group that has white space at the end of the name + When the administrator sends a group creation request for group "white-space-at-end " using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" + And group "white-space-at-end " should not exist + And group "white-space-at-end" should not exist + + + Scenario: admin tries to create a group that has white space at the start of the name + When the administrator sends a group creation request for group " white-space-at-start" using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" + And group " white-space-at-start" should not exist + But group "white-space-at-start" should not exist + + + Scenario: admin tries to create a group that is a single space + When the administrator sends a group creation request for group " " using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" + And group " " should not exist + + + Scenario: admin tries to create a group that is the empty string + When the administrator tries to send a group creation request for group "" using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroupOc10Issue31015.feature new file mode 100644 index 00000000000..4dc0a0051cb --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/addGroupOc10Issue31015.feature @@ -0,0 +1,58 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 + # group-delete API does not work for groups with a slash in the name + @issue-31015 + Scenario: admin creates a group with a forward-slash in the group name + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | var/../etc | using slash-dot-dot | + | priv/subadmins/1 | Subadmins mentioned not at the end | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following groups should not exist + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + # And the following groups should exist + # | groupname | + # | Mgmt/Sydney | + # | Mgmt//NSW/Sydney | + # | var/../etc | + # | priv/subadmins/1 | + # + # 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 the following groups using the occ command + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + + # 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 "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/coreApiProvisioningGroups-v1/addToGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/addToGroup.feature new file mode 100644 index 00000000000..702631efe7a --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/addToGroup.feature @@ -0,0 +1,228 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: add users to group + As a admin + I want to be able to add users to a group + So that I can give a user access to the resources of the group + + Background: + Given using OCS API version "1" + + @smokeTest @skipOnLDAP + Scenario: adding a user to a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | + | simplegroup | + | España§àôœ€ | + | नेपाली | + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | comment | + | brand-new-user | simplegroup | nothing special here | + | brand-new-user | España§àôœ€ | special European and other characters | + | brand-new-user | नेपाली | Unicode group name | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + + @skipOnLDAP + Scenario: adding a user to a group with special character in its name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | brand-new-group | dash | + | the.group | dot | + | left,right | comma | + | 0 | The "false" group | + | Finance (NP) | Space and brackets | + | Admin&Finance | Ampersand | + | maint+eng | Plus sign | + | $x<=>[y*z^2]! | Maths symbols | + | 😁 😂 | emoji | + | admin:Pokhara@Nepal | Colon and @ | + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | the.group | + | brand-new-user | left,right | + | brand-new-user | 0 | + | brand-new-user | Finance (NP) | + | brand-new-user | Admin&Finance | + | brand-new-user | maint+eng | + | brand-new-user | $x<=>[y*z^2]! | + | brand-new-user | 😁 😂 | + | brand-new-user | admin:Pokhara@Nepal | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + + # once the issue is fixed merge with scenario above + @skipOnLDAP @toImplementOnOCIS @issue-product-284 + Scenario: adding a user to a group with % and # in its name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | maintenance#123 | Hash sign | + | 50%pass | Percent sign (special escaping happens) | + | 50%25=0 | %25 literal looks like an escaped "%" | + | 50%2Eagle | %2E literal looks like an escaped "." | + | 50%2Fix | %2F literal looks like an escaped slash | + | Mgmt\Middle | Backslash | + | staff?group | Question mark | + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | brand-new-user | maintenance#123 | + | brand-new-user | 50%pass | + | brand-new-user | 50%25=0 | + | brand-new-user | 50%2Eagle | + | brand-new-user | 50%2Fix | + | brand-new-user | Mgmt\Middle | + | brand-new-user | staff?group | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + + @issue-31015 @skipOnLDAP + Scenario: adding a user to a group that has a forward-slash in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + # After fixing issue-31015, change the following step to "has been created" + And the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | priv/subadmins/1 | Subadmins mentioned not at the end | + #And group "" has been created + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | priv/subadmins/1 | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + # 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 the following groups using the occ command + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | priv/subadmins/1 | + + @skipOnLDAP @toImplementOnOCIS + Scenario: adding a user to a group using mixes of upper and lower case in user and group names + Given user "mixed-case-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | + | Case-Sensitive-Group1 | + | case-sensitive-group1 | + | CASE-SENSITIVE-GROUP1 | + | Case-Sensitive-Group2 | + | case-sensitive-group2 | + | CASE-SENSITIVE-GROUP2 | + | Case-Sensitive-Group3 | + | case-sensitive-group3 | + | CASE-SENSITIVE-GROUP3 | + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | Mixed-Case-USER | Case-Sensitive-Group1 | + | mixed-case-user | case-sensitive-group2 | + | MIXED-CASE-USER | CASE-SENSITIVE-GROUP3 | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should belong to the following groups + | username | groupname | + | Mixed-Case-USER | Case-Sensitive-Group1 | + | Mixed-Case-User | case-sensitive-group2 | + | mixed-case-user | CASE-SENSITIVE-GROUP3 | + But the following users should not belong to the following groups + | username | groupname | + | Mixed-Case-USER | Case-Sensitive-Group2 | + | mixed-case-user | case-sensitive-group1 | + | MIXED-CASE-USER | CASE-SENSITIVE-GROUP1 | + | Mixed-Case-USER | Case-Sensitive-Group3 | + | mixed-case-user | case-sensitive-group3 | + | MIXED-CASE-USER | CASE-SENSITIVE-GROUP2 | + + @skipOnLDAP + Scenario: normal user tries to add himself to a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" tries to add himself to group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data + + @skipOnLDAP + Scenario: admin tries to add user to a group which does not exist + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "nonexistentgroup" has been deleted + When the administrator tries to add user "brand-new-user" to group "nonexistentgroup" using the provisioning API + Then the OCS status code should be "102" + And the HTTP status code should be "200" + And the API should not return any data + + @skipOnLDAP + Scenario: admin tries to add user to a group without sending the group + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator tries to add user "brand-new-user" to group "" using the provisioning API + Then the OCS status code should be "101" + And the HTTP status code should be "200" + And the API should not return any data + + @skipOnLDAP + Scenario: admin tries to add a user which does not exist to a group + Given user "nonexistentuser" has been deleted + And group "brand-new-group" has been created + When the administrator tries to add user "nonexistentuser" to group "brand-new-group" using the provisioning API + Then the OCS status code should be "103" + And the HTTP status code should be "200" + And the API should not return any data + + @skipOnLDAP @notToImplementOnOCIS + Scenario: a subadmin cannot add users to groups the subadmin is responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | subadmin | + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" tries to add user "brand-new-user" to group "brand-new-group" using the provisioning API + Then the OCS status code should be "104" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "brand-new-group" + + @skipOnLDAP @notToImplementOnOCIS + Scenario: a subadmin cannot add users to groups the subadmin is not responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-subadmin | + And group "brand-new-group" has been created + And group "another-new-group" has been created + And user "another-subadmin" has been made a subadmin of group "another-new-group" + When user "another-subadmin" tries to add user "brand-new-user" to group "brand-new-group" using the provisioning API + Then the OCS status code should be "104" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "brand-new-group" + + @skipOnLDAP @notToImplementOnOCIS + Scenario: a subadmin can add users to other groups the subadmin is responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-subadmin | + And group "brand-new-group" has been created + And group "another-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "another-new-group" + When user "another-subadmin" tries to add user "brand-new-user" to group "another-new-group" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should belong to group "brand-new-group" + + # merge this with scenario on line 62 once the issue is fixed + @issue-31015 @skipOnLDAP @toImplementOnOCIS @issue-product-284 + Scenario Outline: adding a user to a group that has a forward-slash and dot in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And the administrator sends a group creation request for group "" using the provisioning API + When the administrator adds user "brand-new-user" to group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + Examples: + | group_id | comment | + | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroup.feature new file mode 100644 index 00000000000..86108481734 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroup.feature @@ -0,0 +1,119 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: delete groups + As an admin + I want to be able to delete groups + So that I can remove unnecessary groups + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario Outline: admin deletes a group + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | simplegroup | nothing special here | + | España§àôœ€ | special European and other characters | + | नेपाली | Unicode group name | + + + Scenario Outline: admin deletes a group + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | brand-new-group | dash | + | the.group | dot | + | left,right | comma | + | 0 | The "false" group | + | Finance (NP) | Space and brackets | + | Admin&Finance | Ampersand | + | admin:Pokhara@Nepal | Colon and @ | + | maint+eng | Plus sign | + | $x<=>[y*z^2]! | Maths symbols | + | Mgmt\Middle | Backslash | + | 😁 😂 | emoji | + + @toImplementOnOCIS + Scenario Outline: admin deletes a group + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | maintenance#123 | Hash sign | + | 50%pass | Percent sign (special escaping happens) | + | 50%25=0 | %25 literal looks like an escaped "%" | + | 50%2Eagle | %2E literal looks like an escaped "." | + | 50%2Fix | %2F literal looks like an escaped slash | + | staff?group | Question mark | + + @toImplementOnOCIS + Scenario Outline: group names are case-sensitive, the correct group is deleted + Given group "" has been created + And group "" has been created + And group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And group "" should not exist + But group "" should exist + And group "" should exist + Examples: + | group_id1 | group_id2 | group_id3 | + | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | + + @issue-31015 @skipOnOcV10 + Scenario Outline: admin deletes a group that has a forward-slash in the group name + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | priv/subadmins/1 | Subadmins mentioned not at the end | + + + Scenario: normal user tries to delete the group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + When user "brand-new-user" tries to delete group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And group "brand-new-group" should exist + + @notToImplementOnOCIS + Scenario: subadmin of the group tries to delete the group + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" tries to delete group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And group "brand-new-group" should exist + + @issue-31015 @skipOnOcV10 @toImplementOnOCIS + Scenario Outline: admin deletes a group that has a forward-slash in the group name + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroupOc10Issue31015.feature new file mode 100644 index 00000000000..7f8e6b9c11a --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/deleteGroupOc10Issue31015.feature @@ -0,0 +1,42 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: delete groups + As an admin + I want to be able to delete groups + So that I can remove unnecessary groups + + Background: + Given using OCS API version "1" + + @issue-31015 + Scenario: admin deletes a group that has a forward-slash in the group name + # After fixing issue-31015, change the following step to "has been created" + Given the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | var/../etc | using slash-dot-dot | + | priv/subadmins/1 | Subadmins mentioned not at the end | + When the administrator deletes the following groups using the provisioning API + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + # After fixing issue-31015, change the expected status to "100" + #Then the OCS status code should be "100" + Then the HTTP status code of responses on all endpoints should be "404" + #And the HTTP status code should be "200" + And the following groups should not exist + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + # 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 the following groups using the occ command + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroup.feature new file mode 100644 index 00000000000..ffda9e60e6a --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroup.feature @@ -0,0 +1,90 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: get group + As an admin + I want to be able to get group details + So that I can know which users are in a group + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin gets users in the group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | 123 | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "123" has been added to group "brand-new-group" + When the administrator gets all the members of group "brand-new-group" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the users returned by the API should be + | brand-new-user | + | 123 | + + + Scenario: admin tries to get users in the empty group + Given group "brand-new-group" has been created + When the administrator gets all the members of group "brand-new-group" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the list of users returned by the API should be empty + + + Scenario: admin tries to get users in a nonexistent group + Given group "brand-new-group" has been created + When the administrator gets all the members of group "nonexistentgroup" using the provisioning API + Then the OCS status code should be "998" + And the HTTP status code should be "200" + + @toImplementOnOCIS + Scenario Outline: admin tries to get users in a group but using wrong case of the group name + Given group "" has been created + When the administrator gets all the members of group "" using the provisioning API + Then the OCS status code should be "998" + And the HTTP status code should be "200" + Examples: + | group_id1 | group_id2 | + | case-sensitive-group | Case-Sensitive-Group | + | case-sensitive-group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | case-sensitive-group | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | CASE-SENSITIVE-GROUP | Case-Sensitive-Group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | + + @smokeTest @notToImplementOnOCIS + Scenario: subadmin gets users in a group they are responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | subadmin | + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "Alice" has been added to group "brand-new-group" + And user "Brian" has been added to group "brand-new-group" + When user "subadmin" gets all the members of group "brand-new-group" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the users returned by the API should be + | Alice | + | Brian | + + @notToImplementOnOCIS + Scenario: subadmin tries to get users in a group they are not responsible for + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "another-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" gets all the members of group "another-group" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + + + Scenario: normal user tries to get users in their group + Given user "newuser" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + When user "newuser" gets all the members of group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroups.feature new file mode 100644 index 00000000000..f5ece2823d9 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/getGroups.feature @@ -0,0 +1,56 @@ +@api @provisioning_api-app-required @rememberGroupsThatExist @skipOnLDAP @skipOnGraph +Feature: get groups + As an admin + I want to be able to get groups + So that I can see all the groups in my ownCloud + + Background: + Given using OCS API version "1" + + @smokeTest @skipOnLdap @issue-ldap-500 + Scenario: admin gets all the groups where admin group exists + Given group "0" has been created + And group "brand-new-group" has been created + And group "España" has been created + When the administrator gets all the groups using the provisioning API + Then the extra groups returned by the API should be + | España | + | brand-new-group | + | 0 | + + @skipOnLdap @issue-ldap-499 + Scenario: admin gets all the groups, including groups with mixed case + Given group "case-sensitive-group" has been created + And group "Case-Sensitive-Group" has been created + And group "CASE-SENSITIVE-GROUP" has been created + When the administrator gets all the groups using the provisioning API + Then the extra groups returned by the API should be + | case-sensitive-group | + | Case-Sensitive-Group | + | CASE-SENSITIVE-GROUP | + + @notToImplementOnOCIS + Scenario: subadmin gets all the groups + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "0" has been created + And group "España" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" gets all the groups using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the extra groups returned by the API should be + | España | + | brand-new-group | + | 0 | + + + Scenario: normal user cannot get a list of all the groups + Given user "Alice" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "0" has been created + And group "España" has been created + When user "Alice" gets all the groups using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getSubAdminGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getSubAdminGroups.feature new file mode 100644 index 00000000000..dcb80879a21 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/getSubAdminGroups.feature @@ -0,0 +1,75 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get subadmin groups + As an admin + I want to be able to get the groups in which the user is subadmin + So that I can know in which groups the user has administrative rights + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin gets subadmin groups of a user + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "😅 😆" has been created + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + And user "brand-new-user" has been made a subadmin of group "😅 😆" + When the administrator gets all the groups where user "brand-new-user" is subadmin using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the subadmin groups returned by the API should be + | brand-new-group | + | 😅 😆 | + + + Scenario: admin tries to get subadmin groups of a user which does not exist + Given user "nonexistentuser" has been deleted + And group "brand-new-group" has been created + When the administrator gets all the groups where user "nonexistentuser" is subadmin using the provisioning API + Then the OCS status code should be "998" + And the HTTP status code should be "200" + And the API should not return any data + + @issue-owncloud-sdk-658 + Scenario: subadmin gets groups where he/she is subadmin + Given user "Alice" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "😅 😆" has been created + And user "Alice" has been made a subadmin of group "brand-new-group" + And user "Alice" has been made a subadmin of group "😅 😆" + When user "Alice" gets all the groups where user "Alice" is subadmin using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the subadmin groups returned by the API should be + | brand-new-group | + | 😅 😆 | + + + Scenario: subadmin of a group should not be able to get subadmin groups of another subadmin user + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "brand-new-group" has been created + And group "😅 😆" has been created + And user "Alice" has been made a subadmin of group "brand-new-group" + And user "Brian" has been made a subadmin of group "😅 😆" + When user "Alice" tries to get all the groups where user "Brian" is subadmin using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data + + + Scenario: normal user should not be able to get subadmin groups of a subadmin user + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "brand-new-group" has been created + And group "😅 😆" has been created + And user "Alice" has been made a subadmin of group "brand-new-group" + And user "Alice" has been made a subadmin of group "😅 😆" + When user "Brian" tries to get all the groups where user "Alice" is subadmin using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroups.feature new file mode 100644 index 00000000000..c356fc18872 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroups.feature @@ -0,0 +1,163 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: get user groups + As an admin + I want to be able to get groups + So that I can manage group membership + + Background: + Given using OCS API version "1" + + @smokeTest @notToImplementOnOCIS + Scenario: admin gets groups of an user + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + And group "brand-new-group" has been created + And group "0" has been created + And group "Admin & Finance (NP)" has been created + And group "admin:Pokhara@Nepal" has been created + And group "नेपाली" has been created + And group "😅 😆" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "brand-new-user" has been added to group "0" + And user "brand-new-user" has been added to group "Admin & Finance (NP)" + And user "brand-new-user" has been added to group "admin:Pokhara@Nepal" + And user "brand-new-user" has been added to group "नेपाली" + And user "brand-new-user" has been added to group "😅 😆" + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the groups returned by the API should be + | brand-new-group | + | 0 | + | Admin & Finance (NP) | + | admin:Pokhara@Nepal | + | नेपाली | + | 😅 😆 | + + @issue-31015 @skipOnOcV10 + Scenario: admin gets groups of an user, including groups containing a slash + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + And group "Mgmt/Sydney" has been created + And group "var/../etc" has been created + And group "priv/subadmins/1" has been created + And user "brand-new-user" has been added to group "Mgmt/Sydney" + And user "brand-new-user" has been added to group "var/../etc" + And user "brand-new-user" has been added to group "priv/subadmins/1" + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the groups returned by the API should be + | Mgmt/Sydney | + | var/../etc | + | priv/subadmins/1 | + + @smokeTest @notToImplementOnOCIS + Scenario: subadmin tries to get other groups of a user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | subadmin | + And group "brand-new-group" has been created + And group "another-new-group" has been created + 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" + And user "brand-new-user" has been added to group "another-new-group" + When user "subadmin" gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the groups returned by the API should include "brand-new-group" + And the groups returned by the API should not include "another-new-group" + + + Scenario: normal user tries to get the groups of another user + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + When user "another-new-user" gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data + + @notToImplementOnOCIS + Scenario: admin gets groups of an user who is not in any groups + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the list of groups returned by the API should be empty + + @smokeTest @skipOnOcV10 + Scenario: admin gets groups of an user on ocis + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + And group "brand-new-group" has been created + And group "0" has been created + And group "Admin & Finance (NP)" has been created + And group "admin:Pokhara@Nepal" has been created + And group "नेपाली" has been created + And group "😅 😆" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "brand-new-user" has been added to group "0" + And user "brand-new-user" has been added to group "Admin & Finance (NP)" + And user "brand-new-user" has been added to group "admin:Pokhara@Nepal" + And user "brand-new-user" has been added to group "नेपाली" + And user "brand-new-user" has been added to group "😅 😆" + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the groups returned by the API should be + | brand-new-group | + | 0 | + | Admin & Finance (NP) | + | admin:Pokhara@Nepal | + | नेपाली | + | 😅 😆 | + | users | + + @skipOnOcV10 + Scenario: admin gets groups of an user who is not in any groups on ocis + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the groups returned by the API should be + | users | + + @notToImplementOnOCIS + Scenario: normal user gets his/her groups + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + And group "group1" has been created + And group "group2" has been created + And user "Alice" has been added to group "group1" + And user "Alice" has been added to group "group2" + When user "Alice" gets all the groups of user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the groups returned by the API should be + | group1 | + | group2 | + + @skipOnOcV10 + Scenario: normal user gets his/her groups in ocis + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + And group "group1" has been created + And group "group2" has been created + And user "Alice" has been added to group "group1" + And user "Alice" has been added to group "group2" + When user "Alice" gets all the groups of user "Alice" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the groups returned by the API should be + | group1 | + | group2 | + | users | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroupsOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroupsOc10Issue31015.feature new file mode 100644 index 00000000000..c37e0117a68 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/getUserGroupsOc10Issue31015.feature @@ -0,0 +1,35 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get user groups + As an admin + I want to be able to get groups + So that I can manage group membership + + Background: + Given using OCS API version "1" + + @issue-31015 + Scenario: admin gets groups of an user, including groups containing a slash + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + # After fixing issue-31015, change the following steps to "has been created" + And the administrator sends a group creation request for group "Mgmt/Sydney" using the provisioning API + And the administrator sends a group creation request for group "var/../etc" using the provisioning API + And the administrator sends a group creation request for group "priv/subadmins/1" using the provisioning API + #And group "Mgmt/Sydney" has been created + #And group "var/../etc" has been created + #And group "priv/subadmins/1" has been created + And user "brand-new-user" has been added to group "Mgmt/Sydney" + And user "brand-new-user" has been added to group "var/../etc" + And user "brand-new-user" has been added to group "priv/subadmins/1" + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the groups returned by the API should be + | Mgmt/Sydney | + | var/../etc | + | priv/subadmins/1 | + # The following steps are needed so that the groups do get cleaned up. + # After fixing issue-31015, remove the following steps: + And the administrator deletes group "Mgmt/Sydney" using the occ command + And the administrator deletes group "var/../etc" using the occ command + And the administrator deletes group "priv/subadmins/1" using the occ command diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroup.feature new file mode 100644 index 00000000000..e735b9a0d7c --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroup.feature @@ -0,0 +1,243 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: remove a user from a group + As an admin + I want to be able to remove a user from a group + So that I can manage user access to group resources + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario: admin removes a user from a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | brand-new-group | nothing special here | + | España§àôœ€ | special European and other characters | + | नेपाली | Unicode group name | + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | España§àôœ€ | + | brand-new-user | नेपाली | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | España§àôœ€ | + | brand-new-user | नेपाली | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | España§àôœ€ | + | brand-new-user | नेपाली | + + + Scenario: admin removes a user from a group with special characters + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | brand-new-group | dash | + | the.group | dot | + | left,right | comma | + | 0 | The "false" group | + | Finance (NP) | Space and brackets | + | Admin&Finance | Ampersand | + | admin:Pokhara@Nepal | Colon and @ | + | maint+eng | Plus sign | + | $x<=>[y*z^2]! | Maths symbols | + | Mgmt\Middle | Backslash | + | 😁 😂 | emoji | + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | the.group | + | brand-new-user | left,right | + | brand-new-user | 0 | + | brand-new-user | Finance (NP) | + | brand-new-user | Admin&Finance | + | brand-new-user | admin:Pokhara@Nepal | + | brand-new-user | maint+eng | + | brand-new-user | $x<=>[y*z^2]! | + | brand-new-user | Mgmt\Middle | + | brand-new-user | 😁 😂 | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | the.group | + | brand-new-user | left,right | + | brand-new-user | 0 | + | brand-new-user | Finance (NP) | + | brand-new-user | Admin&Finance | + | brand-new-user | admin:Pokhara@Nepal | + | brand-new-user | maint+eng | + | brand-new-user | $x<=>[y*z^2]! | + | brand-new-user | Mgmt\Middle | + | brand-new-user | 😁 😂 | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | the.group | + | brand-new-user | left,right | + | brand-new-user | 0 | + | brand-new-user | Finance (NP) | + | brand-new-user | Admin&Finance | + | brand-new-user | admin:Pokhara@Nepal | + | brand-new-user | maint+eng | + | brand-new-user | $x<=>[y*z^2]! | + | brand-new-user | Mgmt\Middle | + | brand-new-user | 😁 😂 | + + @toImplementOnOCIS + Scenario: admin removes a user from a group with % and # in their names + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | maintenance#123 | Hash sign | + | 50%pass | Percent sign (special escaping happens) | + | 50%25=0 | %25 literal looks like an escaped "%" | + | 50%2Eagle | %2E literal looks like an escaped "." | + | 50%2Fix | %2F literal looks like an escaped slash | + | staff?group | Question mark | + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | maintenance#123 | + | brand-new-user | 50%pass | + | brand-new-user | 50%25=0 | + | brand-new-user | 50%2Eagle | + | brand-new-user | 50%2Fix | + | brand-new-user | staff?group | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | maintenance#123 | + | brand-new-user | 50%pass | + | brand-new-user | 50%25=0 | + | brand-new-user | 50%2Eagle | + | brand-new-user | 50%2Fix | + | brand-new-user | staff?group | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | maintenance#123 | + | brand-new-user | 50%pass | + | brand-new-user | 50%25=0 | + | brand-new-user | 50%2Eagle | + | brand-new-user | 50%2Fix | + | brand-new-user | staff?group | + + @issue-31015 @skipOnOcV10 + Scenario: admin removes a user from a group that has a forward-slash in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | priv/subadmins/1 | Subadmins mentioned not at the end | + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | priv/subadmins/1 | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | priv/subadmins/1 | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | priv/subadmins/1 | + + @toImplementOnOCIS + Scenario Outline: remove a user from a group using mixes of upper and lower case in user and group names + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "" has been created + And group "" has been created + And group "" has been created + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + When the administrator removes user "" from group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "" + But user "brand-new-user" should belong to group "" + And user "brand-new-user" should belong to group "" + Examples: + | user_id | group_id1 | group_id2 | group_id3 | + | BRAND-NEW-USER | Mixed-Group | mixed-group | MIXED-GROUP | + | Brand-New-User | mixed-group | MIXED-GROUP | Mixed-Group | + | brand-new-user | MIXED-GROUP | Mixed-Group | mixed-group | + + + Scenario: admin tries to remove a user from a group which does not exist + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "nonexistentgroup" has been deleted + When the administrator removes user "brand-new-user" from group "nonexistentgroup" using the provisioning API + Then the OCS status code should be "102" + And the HTTP status code should be "200" + And the API should not return any data + + @smokeTest @notToImplementOnOCIS + Scenario: a subadmin can remove users from groups the subadmin is responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | subadmin | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" removes user "brand-new-user" from group "brand-new-group" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "brand-new-group" + + @notToImplementOnOCIS + Scenario: a subadmin cannot remove users from groups the subadmin is not responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-subadmin | + And group "brand-new-group" has been created + And group "another-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "another-new-group" + When user "another-subadmin" removes user "brand-new-user" from group "brand-new-group" using the provisioning API + Then the OCS status code should be "104" + And the HTTP status code should be "200" + And user "brand-new-user" should belong to group "brand-new-group" + + + Scenario: normal user tries to remove a user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "another-new-user" has been added to group "brand-new-group" + When user "brand-new-user" tries to remove user "another-new-user" from group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And user "another-new-user" should belong to group "brand-new-group" + + # merge this with scenario on line 62 once the issue is fixed + @issue-31015 @skipOnOcV10 @toImplementOnOCIS + Scenario Outline: admin removes a user from a group that has a forward-slash and dot in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "" has been created + And user "brand-new-user" has been added to group "" + When the administrator removes user "brand-new-user" from group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "" + Examples: + | group_id | comment | + | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroupOc10Issue31015.feature new file mode 100644 index 00000000000..3b9a86f7dc4 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v1/removeFromGroupOc10Issue31015.feature @@ -0,0 +1,48 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: remove a user from a group + As an admin + I want to be able to remove a user from a group + So that I can manage user access to group resources + + Background: + Given using OCS API version "1" + + @issue-31015 + Scenario: admin removes a user from a group that has a forward-slash in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + # After fixing issue-31015, change the following step to "has been created" + And the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | var/../etc | using slash-dot-dot | + | priv/subadmins/1 | Subadmins mentioned not at the end | + #And group "" has been created + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | var/../etc | + | brand-new-user | priv/subadmins/1 | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | var/../etc | + | brand-new-user | priv/subadmins/1 | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | var/../etc | + | brand-new-user | priv/subadmins/1 | + # 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 the following groups using the occ command + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroup.feature new file mode 100644 index 00000000000..df0109291c8 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroup.feature @@ -0,0 +1,183 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +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 "2" + + @smokeTest + Scenario: admin creates a group + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | simplegroup | nothing special here | + | España§àôœ€ | special European and other characters | + | नेपाली | Unicode group name | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | simplegroup | + | España§àôœ€ | + | नेपाली | + + + Scenario: admin creates a group with special characters + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | brand-new-group | dash | + | the.group | dot | + | left,right | comma | + | 0 | The "false" group | + | Finance (NP) | Space and brackets | + | Admin&Finance | Ampersand | + | admin:Pokhara@Nepal | Colon and @ | + | maint+eng | Plus sign | + | $x<=>[y*z^2]! | Maths symbols | + | Mgmt\Middle | Backslash | + | 😅 😆 | emoji | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | brand-new-group | + | the.group | + | left,right | + | 0 | + | Finance (NP) | + | Admin&Finance | + | admin:Pokhara@Nepal | + | maint+eng | + | $x<=>[y*z^2]! | + | Mgmt\Middle | + | 😅 😆 | + + @toImplementOnOCIS @issue-product-284 + Scenario: admin creates a group with % in name + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | maintenance#123 | Hash sign | + | 50%pass | Percent sign (special escaping happens) | + | 50%25=0 | %25 literal looks like an escaped "%" | + | 50%2Fix | %2F literal looks like an escaped slash | + | 50%2Eagle | %2E literal looks like an escaped "." | + | staff?group | Question mark | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | maintenance#123 | + | 50%pass | + | 50%25=0 | + | 50%2Fix | + | 50%2Eagle | + | staff?group | + + @toImplementOnOCIS + Scenario: group names are case-sensitive, multiple groups can exist with different upper and lower case names + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | + | Case-Sensitive-Group1 | + | case-sensitive-group1 | + | Case-Sensitive-Group2 | + | CASE-SENSITIVE-GROUP2 | + | case-sensitive-group3 | + | CASE-SENSITIVE-GROUP3 | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | Case-Sensitive-Group1 | + | case-sensitive-group1 | + | Case-Sensitive-Group2 | + | CASE-SENSITIVE-GROUP2 | + | case-sensitive-group3 | + | CASE-SENSITIVE-GROUP3 | + And these groups should not exist: + | groupname | + | CASE-SENSITIVE-GROUP1 | + | case-sensitive-group2 | + | Case-Sensitive-Group3 | + + @issue-31015 @skipOnOcV10 @toImplementOnOCIS + Scenario: admin creates a group with a forward-slash in the group name + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | var/../etc | using slash-dot-dot | + | priv/subadmins/1 | Subadmins mentioned not at the end | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And these groups should exist: + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + + # 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 @notToImplementOnOCIS + Scenario: admin tries to create a group with name ending in "/subadmins" + Given group "brand-new-group" has been created + When the administrator tries to send a group creation request for group "priv/subadmins" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And group "priv/subadmins" should not exist + + + Scenario: admin tries to create a group that already exists + Given group "brand-new-group" has been created + When the administrator sends a group creation request for group "brand-new-group" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And group "brand-new-group" should exist + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to create a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" tries to send a group creation request for group "brand-new-group" using the provisioning API + Then the OCS status code should be "401" + And the HTTP status code should be "401" + And group "brand-new-group" should not exist + + @notToImplementOnOCIS + Scenario: subadmin tries to create a group + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" tries to send a group creation request for group "another-new-group" using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And group "another-new-group" should not exist + + + Scenario: admin tries to create a group that has white space at the end of the name + When the administrator sends a group creation request for group "white-space-at-end " using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And group "white-space-at-end " should not exist + And group "white-space-at-end" should not exist + + + Scenario: admin tries to create a group that has white space at the start of the name + When the administrator sends a group creation request for group " white-space-at-start" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And group " white-space-at-start" should not exist + And group "white-space-at-start" should not exist + + + Scenario: admin tries to create a group that is a single space + When the administrator sends a group creation request for group " " using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And group " " should not exist + + + Scenario: admin tries to create a group that is the empty string + When the administrator tries to send a group creation request for group "" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31015.feature new file mode 100644 index 00000000000..81c4d867f5f --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31015.feature @@ -0,0 +1,56 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 "2" + + # 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 + # group-delete API does not work for groups with a slash in the name + @issue-31015 + Scenario: admin creates a group with a forward-slash in the group name + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | var/../etc | using slash-dot-dot | + | priv/subadmins/1 | Subadmins mentioned not at the end | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + # After fixing issue-31015, change the following step to "should exist" + And the following groups should not exist + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + #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 the following groups using the occ command + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + + # 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 + # After fixing issue-31015, change the expected status to "400" + Then the OCS status code should be "200" + #Then the OCS status code should be "400" + And the HTTP status code should be "200" + #And the HTTP status code should be "400" + 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 diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31276.feature new file mode 100644 index 00000000000..bc20a5f165e --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/addGroupOc10Issue31276.feature @@ -0,0 +1,17 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +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 "2" + + @issue-31276 + Scenario: normal user tries to create a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" tries to send a group creation request for group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + #And the OCS status code should be "401" + And the HTTP status code should be "401" + And group "brand-new-group" should not exist diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroup.feature new file mode 100644 index 00000000000..4d8426f0262 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroup.feature @@ -0,0 +1,219 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: add users to group + As a admin + I want to be able to add users to a group + So that I can give a user access to the resources of the group + + Background: + Given using OCS API version "2" + + @smokeTest @skipOnLDAP + Scenario: adding a user to a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | simplegroup | nothing special here | + | España§àôœ€ | special European and other characters | + | नेपाली | Unicode group name | + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | brand-new-user | simplegroup | + | brand-new-user | España§àôœ€ | + | brand-new-user | नेपाली | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + + @skipOnLDAP + Scenario: adding a user to a group with special character in its name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | brand-new-group | dash | + | the.group | dot | + | left,right | comma | + | 0 | The "false" group | + | Finance (NP) | Space and brackets | + | Admin&Finance | Ampersand | + | maint+eng | Plus sign | + | $x<=>[y*z^2]! | Maths symbols | + | 😁 😂 | emoji | + | admin:Pokhara@Nepal | Colon and @ | + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | the.group | + | brand-new-user | left,right | + | brand-new-user | 0 | + | brand-new-user | Finance (NP) | + | brand-new-user | Admin&Finance | + | brand-new-user | maint+eng | + | brand-new-user | $x<=>[y*z^2]! | + | brand-new-user | 😁 😂 | + | brand-new-user | admin:Pokhara@Nepal | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + + # once the issue is fixed merge with scenario above + @skipOnLDAP @toImplementOnOCIS @issue-product-284 + Scenario: adding a user to a group with % and # in its name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | maintenance#123 | Hash sign | + | 50%pass | Percent sign (special escaping happens) | + | 50%25=0 | %25 literal looks like an escaped "%" | + | 50%2Eagle | %2E literal looks like an escaped "." | + | 50%2Fix | %2F literal looks like an escaped slash | + | Mgmt\Middle | Backslash | + | staff?group | Question mark | + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | brand-new-user | maintenance#123 | + | brand-new-user | 50%pass | + | brand-new-user | 50%25=0 | + | brand-new-user | 50%2Eagle | + | brand-new-user | 50%2Fix | + | brand-new-user | Mgmt\Middle | + | brand-new-user | staff?group | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + + @issue-31015 @skipOnOcV10 + Scenario: adding a user to a group that has a forward-slash in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | priv/subadmins/1 | Subadmins mentioned not at the end | + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | priv/subadmins/1 | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + + @skipOnLDAP @toImplementOnOCIS @issue-product-283 + Scenario: adding a user to a group using mixes of upper and lower case in user and group names + Given user "mixed-case-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | + | Case-Sensitive-Group1 | + | case-sensitive-group1 | + | CASE-SENSITIVE-GROUP1 | + | Case-Sensitive-Group2 | + | case-sensitive-group2 | + | CASE-SENSITIVE-GROUP2 | + | Case-Sensitive-Group3 | + | case-sensitive-group3 | + | CASE-SENSITIVE-GROUP3 | + When the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | Mixed-Case-USER | Case-Sensitive-Group1 | + | mixed-case-user | case-sensitive-group2 | + | MIXED-CASE-USER | CASE-SENSITIVE-GROUP3 | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should belong to the following groups + | username | groupname | + | Mixed-Case-USER | Case-Sensitive-Group1 | + | Mixed-Case-User | case-sensitive-group2 | + | mixed-case-user | CASE-SENSITIVE-GROUP3 | + But the following users should not belong to the following groups + | username | groupname | + | Mixed-Case-USER | Case-Sensitive-Group2 | + | mixed-case-user | case-sensitive-group1 | + | MIXED-CASE-USER | CASE-SENSITIVE-GROUP1 | + | Mixed-Case-USER | Case-Sensitive-Group3 | + | mixed-case-user | case-sensitive-group3 | + | MIXED-CASE-USER | CASE-SENSITIVE-GROUP2 | + + @issue-31276 @skipOnLDAP @skipOnOcV10 + Scenario: normal user tries to add himself to a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" tries to add himself to group "brand-new-group" 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 + + @skipOnLDAP + Scenario: admin tries to add user to a group which does not exist + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "nonexistentgroup" has been deleted + When the administrator tries to add user "brand-new-user" to group "nonexistentgroup" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And the API should not return any data + + @skipOnLDAP + Scenario: admin tries to add user to a group without sending the group + Given user "brand-new-user" has been created with default attributes and without skeleton files + When the administrator tries to add user "brand-new-user" to group "" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And the API should not return any data + + @skipOnLDAP + Scenario: admin tries to add a user which does not exist to a group + Given user "nonexistentuser" has been deleted + And group "brand-new-group" has been created + When the administrator tries to add user "nonexistentuser" to group "brand-new-group" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And the API should not return any data + + @skipOnLDAP @notToImplementOnOCIS + Scenario: subadmin adds users to groups the subadmin is responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | subadmin | + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" tries to add user "brand-new-user" to group "brand-new-group" using the provisioning API + Then the OCS status code should be "403" + And the HTTP status code should be "403" + And user "brand-new-user" should not belong to group "brand-new-group" + + @skipOnLDAP @notToImplementOnOCIS + Scenario: subadmin tries to add user to groups the subadmin is not responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-subadmin | + And group "brand-new-group" has been created + And group "another-new-group" has been created + And user "another-subadmin" has been made a subadmin of group "another-new-group" + When user "another-subadmin" tries to add user "brand-new-user" to group "brand-new-group" using the provisioning API + Then the OCS status code should be "403" + And the HTTP status code should be "403" + And user "brand-new-user" should not belong to group "brand-new-group" + + @skipOnLDAP @notToImplementOnOCIS + Scenario: a subadmin can add users to other groups the subadmin is responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-subadmin | + And group "brand-new-group" has been created + And group "another-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "another-new-group" + When user "another-subadmin" tries to add user "brand-new-user" to group "another-new-group" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should belong to group "brand-new-group" + + # merge this with scenario on line 62 once the issue is fixed + @issue-31015 @skipOnLDAP @toImplementOnOCIS @issue-product-284 + Scenario Outline: adding a user to a group that has a forward-slash and dot in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And the administrator sends a group creation request for group "" using the provisioning API + When the administrator adds user "brand-new-user" to group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + Examples: + | group_id | comment | + | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31015.feature new file mode 100644 index 00000000000..9e2d0b6a62e --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31015.feature @@ -0,0 +1,36 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: add users to group + As a admin + I want to be able to add users to a group + So that I can give a user access to the resources of the group + + Background: + Given using OCS API version "2" + + @issue-31015 @skipOnLDAP + Scenario: adding a user to a group that has a forward-slash in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + # After fixing issue-31015, change the following step to "has been created" + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | var/../etc | using slash-dot-dot | + | priv/subadmins/1 | Subadmins mentioned not at the end | + #And group "" has been created + And the administrator adds the following users to the following groups using the provisioning API + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | var/../etc | + | brand-new-user | priv/subadmins/1 | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + # 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 the following groups using the occ command + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31276.feature new file mode 100644 index 00000000000..85c2201eda7 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/addToGroupOc10Issue31276.feature @@ -0,0 +1,17 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: add users to group + As a admin + I want to be able to add users to a group + So that I can give a user access to the resources of the group + + Background: + Given using OCS API version "2" + + @issue-31276 @skipOnLDAP + Scenario: normal user tries to add himself to a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + When user "brand-new-user" tries to add himself to group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + #And 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/coreApiProvisioningGroups-v2/deleteGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroup.feature new file mode 100644 index 00000000000..18082a0a35c --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroup.feature @@ -0,0 +1,119 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: delete groups + As an admin + I want to be able to delete groups + So that I can remove unnecessary groups + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario Outline: admin deletes a group + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | simplegroup | nothing special here | + | España§àôœ€ | special European and other characters | + | नेपाली | Unicode group name | + + + Scenario Outline: admin deletes a group + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | brand-new-group | dash | + | the.group | dot | + | left,right | comma | + | 0 | The "false" group | + | Finance (NP) | Space and brackets | + | Admin&Finance | Ampersand | + | admin:Pokhara@Nepal | Colon and @ | + | maint+eng | Plus sign | + | $x<=>[y*z^2]! | Maths symbols | + | Mgmt\Middle | Backslash | + | 😁 😂 | emoji | + + @toImplementOnOCIS + Scenario Outline: admin deletes a group + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | maintenance#123 | Hash sign | + | 50%pass | Percent sign (special escaping happens) | + | 50%25=0 | %25 literal looks like an escaped "%" | + | 50%2Eagle | %2E literal looks like an escaped "." | + | 50%2Fix | %2F literal looks like an escaped slash | + | staff?group | Question mark | + + @toImplementOnOCIS @issue-product-283 + Scenario Outline: group names are case-sensitive, the correct group is deleted + Given group "" has been created + And group "" has been created + And group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And group "" should not exist + But group "" should exist + And group "" should exist + Examples: + | group_id1 | group_id2 | group_id3 | + | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | + + @issue-31015 @skipOnOcV10 + Scenario Outline: admin deletes a group that has a forward-slash in the group name + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | priv/subadmins/1 | Subadmins mentioned not at the end | + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to delete the group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + When user "brand-new-user" tries to delete group "brand-new-group" using the provisioning API + Then the OCS status code should be "401" + And the HTTP status code should be "401" + And group "brand-new-group" should exist + + @issue-31276 @skipOnOcV10 @notToImplementOnOCIS + Scenario: subadmin of the group tries to delete the group + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" tries to delete group "brand-new-group" using the provisioning API + Then the OCS status code should be "401" + And the HTTP status code should be "401" + And group "brand-new-group" should exist + + @issue-31015 @skipOnOcV10 @toImplementOnOCIS @issue-product-284 + Scenario Outline: admin deletes a group that has a forward-slash in the group name + Given group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And group "" should not exist + Examples: + | group_id | comment | + | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31015.feature new file mode 100644 index 00000000000..b4ec5e4ce98 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31015.feature @@ -0,0 +1,43 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: delete groups + As an admin + I want to be able to delete groups + So that I can remove unnecessary groups + + Background: + Given using OCS API version "2" + + @issue-31015 + Scenario: admin deletes a group that has a forward-slash in the group name + # After fixing issue-31015, change the following step to "has been created" + When the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | var/../etc | using slash-dot-dot | + | priv/subadmins/1 | Subadmins mentioned not at the end | + #Given group "" has been created + And the administrator deletes the following groups using the provisioning API + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + # After fixing issue-31015, change the expected status to "200" + #Then the OCS status code should be "200" + Then the HTTP status code of responses on all endpoints should be "404" + #And the HTTP status code should be "200" + And the following groups should not exist + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | + # 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 the following groups using the occ command + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31276.feature new file mode 100644 index 00000000000..8d694b23da8 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/deleteGroupOc10Issue31276.feature @@ -0,0 +1,30 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: delete groups + As an admin + I want to be able to delete groups + So that I can remove unnecessary groups + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: normal user tries to delete the group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + When user "brand-new-user" tries to delete group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + #And the OCS status code should be "401" + And the HTTP status code should be "401" + And group "brand-new-group" should exist + + @issue-31276 + Scenario: subadmin of the group tries to delete the group + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" tries to delete group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + #And the OCS status code should be "401" + And the HTTP status code should be "401" + And group "brand-new-group" should exist diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroup.feature new file mode 100644 index 00000000000..c2fdffeb7bd --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroup.feature @@ -0,0 +1,90 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: get group + As an admin + I want to be able to get group details + So that I can know which users are in a group + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin gets users in the group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | 123 | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "123" has been added to group "brand-new-group" + When the administrator gets all the members of group "brand-new-group" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the users returned by the API should be + | brand-new-user | + | 123 | + + + Scenario: admin tries to get users in the empty group + Given group "brand-new-group" has been created + When the administrator gets all the members of group "brand-new-group" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the list of users returned by the API should be empty + + + Scenario: admin tries to get users in a nonexistent group + Given group "brand-new-group" has been created + When the administrator gets all the members of group "nonexistentgroup" using the provisioning API + Then the OCS status code should be "404" + And the HTTP status code should be "404" + + @toImplementOnOCIS @issue-product-283 + Scenario Outline: admin tries to get users in a group but using wrong case of the group name + Given group "" has been created + When the administrator gets all the members of group "" using the provisioning API + Then the OCS status code should be "404" + And the HTTP status code should be "404" + Examples: + | group_id1 | group_id2 | + | case-sensitive-group | Case-Sensitive-Group | + | case-sensitive-group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | case-sensitive-group | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | CASE-SENSITIVE-GROUP | Case-Sensitive-Group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | + + @smokeTest @notToImplementOnOCIS + Scenario: subadmin gets users in a group they are responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | subadmin | + And group "brand-new-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + And user "Alice" has been added to group "brand-new-group" + And user "Brian" has been added to group "brand-new-group" + When user "subadmin" gets all the members of group "brand-new-group" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the users returned by the API should be + | Alice | + | Brian | + + @issue-31276 @skipOnOcV10 @notToImplementOnOCIS + Scenario: subadmin tries to get users in a group they are not responsible for + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "another-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" gets all the members of group "another-group" using the provisioning API + Then the OCS status code should be "401" + And the HTTP status code should be "401" + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to get users in their group + Given user "newuser" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + When user "newuser" gets all the members of group "brand-new-group" using the provisioning API + Then the OCS status code should be "401" + And the HTTP status code should be "401" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroupOc10Issue31276.feature new file mode 100644 index 00000000000..357cd66f1ae --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroupOc10Issue31276.feature @@ -0,0 +1,28 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get group + As an admin + I want to be able to get group details + So that I can know which users are in a group + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: subadmin tries to get users in a group they are not responsible for + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "another-group" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" gets all the members of group "another-group" using the provisioning API + Then the OCS status code should be "997" + #And the OCS status code should be "401" + And the HTTP status code should be "401" + + @issue-31276 + Scenario: normal user tries to get users in their group + Given user "newuser" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + When user "newuser" gets all the members 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" + And the HTTP status code should be "401" diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroups.feature new file mode 100644 index 00000000000..01507e6db5a --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/getGroups.feature @@ -0,0 +1,60 @@ +@api @provisioning_api-app-required @rememberGroupsThatExist @skipOnLDAP @skipOnGraph +Feature: get groups + As an admin + I want to be able to get groups + So that I can see all the groups in my ownCloud + + Background: + Given using OCS API version "2" + + @smokeTest @skipOnLdap @issue-ldap-500 + Scenario: admin gets all the groups where admin group exists + Given group "0" has been created + And group "brand-new-group" has been created + And group "España" has been created + When the administrator gets all the groups using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the extra groups returned by the API should be + | España | + | brand-new-group | + | 0 | + + @skipOnLdap @issue-ldap-499 + Scenario: admin gets all the groups, including groups with mixed case + Given group "case-sensitive-group" has been created + And group "Case-Sensitive-Group" has been created + And group "CASE-SENSITIVE-GROUP" has been created + When the administrator gets all the groups using the provisioning API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the extra groups returned by the API should be + | case-sensitive-group | + | Case-Sensitive-Group | + | CASE-SENSITIVE-GROUP | + + @notToImplementOnOCIS + Scenario: subadmin gets all the groups + Given user "subadmin" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "0" has been created + And group "España" has been created + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" gets all the groups using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the extra groups returned by the API should be + | España | + | brand-new-group | + | 0 | + + + Scenario: normal user cannot get a list of all the groups + Given user "Alice" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "0" has been created + And group "España" has been created + When user "Alice" gets all the groups using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getSubAdminGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getSubAdminGroups.feature new file mode 100644 index 00000000000..1aaddf13024 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/getSubAdminGroups.feature @@ -0,0 +1,75 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get subadmin groups + As an admin + I want to be able to get the groups in which the user is subadmin + So that I can know in which groups the user has administrative rights + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin gets subadmin groups of a user + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "😅 😆" has been created + And user "brand-new-user" has been made a subadmin of group "brand-new-group" + And user "brand-new-user" has been made a subadmin of group "😅 😆" + When the administrator gets all the groups where user "brand-new-user" is subadmin using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the subadmin groups returned by the API should be + | brand-new-group | + | 😅 😆 | + + + Scenario: admin tries to get subadmin groups of a user which does not exist + Given user "nonexistentuser" has been deleted + And group "brand-new-group" has been created + When the administrator gets all the groups where user "nonexistentuser" is subadmin using the provisioning API + Then the OCS status code should be "404" + And the HTTP status code should be "404" + And the API should not return any data + + @issue-owncloud-sdk-658 + Scenario: subadmin gets groups where he/she is subadmin + Given user "Alice" has been created with default attributes and without skeleton files + And group "brand-new-group" has been created + And group "😅 😆" has been created + And user "Alice" has been made a subadmin of group "brand-new-group" + And user "Alice" has been made a subadmin of group "😅 😆" + When user "Alice" gets all the groups where user "Alice" is subadmin using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the subadmin groups returned by the API should be + | brand-new-group | + | 😅 😆 | + + + Scenario: subadmin of a group should not be able to get subadmin groups of another subadmin user + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "brand-new-group" has been created + And group "😅 😆" has been created + And user "Alice" has been made a subadmin of group "brand-new-group" + And user "Brian" has been made a subadmin of group "😅 😆" + When user "Alice" tries to get all the groups where user "Brian" is subadmin using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data + + + Scenario: normal user should not be able to get subadmin groups of a subadmin user + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "brand-new-group" has been created + And group "😅 😆" has been created + And user "Alice" has been made a subadmin of group "brand-new-group" + And user "Alice" has been made a subadmin of group "😅 😆" + When user "Brian" tries to get all the groups where user "Alice" is subadmin using the provisioning API + Then the OCS status code should be "997" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroups.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroups.feature new file mode 100644 index 00000000000..8b5153bb93f --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroups.feature @@ -0,0 +1,163 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: get user groups + As an admin + I want to be able to get groups + So that I can manage group membership + + Background: + Given using OCS API version "2" + + @smokeTest @notToImplementOnOCIS + Scenario: admin gets groups of an user + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + And group "brand-new-group" has been created + And group "0" has been created + And group "Admin & Finance (NP)" has been created + And group "admin:Pokhara@Nepal" has been created + And group "नेपाली" has been created + And group "😅 😆" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "brand-new-user" has been added to group "0" + And user "brand-new-user" has been added to group "Admin & Finance (NP)" + And user "brand-new-user" has been added to group "admin:Pokhara@Nepal" + And user "brand-new-user" has been added to group "नेपाली" + And user "brand-new-user" has been added to group "😅 😆" + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the groups returned by the API should be + | brand-new-group | + | 0 | + | Admin & Finance (NP) | + | admin:Pokhara@Nepal | + | नेपाली | + | 😅 😆 | + + @issue-31015 @skipOnOcV10 + Scenario: admin gets groups of an user, including groups containing a slash + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + And group "Mgmt/Sydney" has been created + And group "var/../etc" has been created + And group "priv/subadmins/1" has been created + And user "brand-new-user" has been added to group "Mgmt/Sydney" + And user "brand-new-user" has been added to group "var/../etc" + And user "brand-new-user" has been added to group "priv/subadmins/1" + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the groups returned by the API should be + | Mgmt/Sydney | + | var/../etc | + | priv/subadmins/1 | + And the OCS status code should be "200" + And the HTTP status code should be "200" + + @smokeTest @notToImplementOnOCIS + Scenario: subadmin tries to get other groups of a user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | subadmin | + And group "brand-new-group" has been created + And group "another-new-group" has been created + 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" + And user "brand-new-user" has been added to group "another-new-group" + When user "subadmin" gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the groups returned by the API should include "brand-new-group" + And the groups returned by the API should not include "another-new-group" + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to get the groups of another user + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + When user "another-new-user" gets all the groups 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 + + @notToImplementOnOCIS + Scenario: admin gets groups of an user who is not in any groups + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the list of groups returned by the API should be empty + + @smokeTest @skipOnOcV10 + Scenario: admin gets groups of an user on ocis + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + And group "brand-new-group" has been created + And group "0" has been created + And group "Admin & Finance (NP)" has been created + And group "admin:Pokhara@Nepal" has been created + And group "नेपाली" has been created + And group "😅 😆" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "brand-new-user" has been added to group "0" + And user "brand-new-user" has been added to group "Admin & Finance (NP)" + And user "brand-new-user" has been added to group "admin:Pokhara@Nepal" + And user "brand-new-user" has been added to group "नेपाली" + And user "brand-new-user" has been added to group "😅 😆" + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the groups returned by the API should be + | brand-new-group | + | 0 | + | Admin & Finance (NP) | + | admin:Pokhara@Nepal | + | नेपाली | + | 😅 😆 | + | users | + + @skipOnOcV10 + Scenario: admin gets groups of an user who is not in any groups on ocis + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the groups returned by the API should be + | users | + + @notToImplementOnOCIS + Scenario: normal user gets his/her groups + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + And group "group1" has been created + And group "group2" has been created + And user "Alice" has been added to group "group1" + And user "Alice" has been added to group "group2" + When user "Alice" gets all the groups of user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the groups returned by the API should be + | group1 | + | group2 | + + @skipOnOcV10 + Scenario: normal user gets his/her groups in ocis + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + And group "group1" has been created + And group "group2" has been created + And user "Alice" has been added to group "group1" + And user "Alice" has been added to group "group2" + When user "Alice" gets all the groups of user "Alice" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And the groups returned by the API should be + | group1 | + | group2 | + | users | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31015.feature new file mode 100644 index 00000000000..e29f0e04468 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31015.feature @@ -0,0 +1,35 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get user groups + As an admin + I want to be able to get groups + So that I can manage group membership + + Background: + Given using OCS API version "2" + + @issue-31015 + Scenario: admin gets groups of an user, including groups containing a slash + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "unused-group" has been created + # After fixing issue-31015, change the following steps to "has been created" + And the administrator sends a group creation request for group "Mgmt/Sydney" using the provisioning API + And the administrator sends a group creation request for group "var/../etc" using the provisioning API + And the administrator sends a group creation request for group "priv/subadmins/1" using the provisioning API + #And group "Mgmt/Sydney" has been created + #And group "var/../etc" has been created + #And group "priv/subadmins/1" has been created + And user "brand-new-user" has been added to group "Mgmt/Sydney" + And user "brand-new-user" has been added to group "var/../etc" + And user "brand-new-user" has been added to group "priv/subadmins/1" + When the administrator gets all the groups of user "brand-new-user" using the provisioning API + Then the groups returned by the API should be + | Mgmt/Sydney | + | var/../etc | + | priv/subadmins/1 | + And the OCS status code should be "200" + And the HTTP status code should be "200" + # The following steps are needed so that the groups do get cleaned up. + # After fixing issue-31015, remove the following steps: + And the administrator deletes group "Mgmt/Sydney" using the occ command + And the administrator deletes group "var/../etc" using the occ command + And the administrator deletes group "priv/subadmins/1" using the occ command diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31276.feature new file mode 100644 index 00000000000..43fe85f81f2 --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/getUserGroupsOc10Issue31276.feature @@ -0,0 +1,22 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: get user groups + As an admin + I want to be able to get groups + So that I can manage group membership + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: normal user tries to get the groups of another user + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + When user "another-new-user" gets all the groups 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" + And the HTTP status code should be "401" + And the API should not return any data diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroup.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroup.feature new file mode 100644 index 00000000000..d499f6e8faa --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroup.feature @@ -0,0 +1,243 @@ +@api @provisioning_api-app-required @skipOnLDAP @skipOnGraph +Feature: remove a user from a group + As an admin + I want to be able to remove a user from a group + So that I can manage user access to group resources + + Background: + Given using OCS API version "2" + + @smokeTest + Scenario: admin removes a user from a group + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | brand-new-group | nothing special here | + | España§àôœ€ | special European and other characters | + | नेपाली | Unicode group name | + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | España§àôœ€ | + | brand-new-user | नेपाली | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | España§àôœ€ | + | brand-new-user | नेपाली | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | España§àôœ€ | + | brand-new-user | नेपाली | + + + Scenario: admin removes a user from a group with special characters + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | brand-new-group | dash | + | the.group | dot | + | left,right | comma | + | 0 | The "false" group | + | Finance (NP) | Space and brackets | + | Admin&Finance | Ampersand | + | admin:Pokhara@Nepal | Colon and @ | + | maint+eng | Plus sign | + | $x<=>[y*z^2]! | Maths symbols | + | Mgmt\Middle | Backslash | + | 😁 😂 | emoji | + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | the.group | + | brand-new-user | left,right | + | brand-new-user | 0 | + | brand-new-user | Finance (NP) | + | brand-new-user | Admin&Finance | + | brand-new-user | admin:Pokhara@Nepal | + | brand-new-user | maint+eng | + | brand-new-user | $x<=>[y*z^2]! | + | brand-new-user | Mgmt\Middle | + | brand-new-user | 😁 😂 | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | the.group | + | brand-new-user | left,right | + | brand-new-user | 0 | + | brand-new-user | Finance (NP) | + | brand-new-user | Admin&Finance | + | brand-new-user | admin:Pokhara@Nepal | + | brand-new-user | maint+eng | + | brand-new-user | $x<=>[y*z^2]! | + | brand-new-user | Mgmt\Middle | + | brand-new-user | 😁 😂 | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | brand-new-group | + | brand-new-user | the.group | + | brand-new-user | left,right | + | brand-new-user | 0 | + | brand-new-user | Finance (NP) | + | brand-new-user | Admin&Finance | + | brand-new-user | admin:Pokhara@Nepal | + | brand-new-user | maint+eng | + | brand-new-user | $x<=>[y*z^2]! | + | brand-new-user | Mgmt\Middle | + | brand-new-user | 😁 😂 | + + @toImplementOnOCIS @issue-product-284 + Scenario: admin removes a user from a group with % and # in their names + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | maintenance#123 | Hash sign | + | 50%pass | Percent sign (special escaping happens) | + | 50%25=0 | %25 literal looks like an escaped "%" | + | 50%2Eagle | %2E literal looks like an escaped "." | + | 50%2Fix | %2F literal looks like an escaped slash | + | staff?group | Question mark | + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | maintenance#123 | + | brand-new-user | 50%pass | + | brand-new-user | 50%25=0 | + | brand-new-user | 50%2Eagle | + | brand-new-user | 50%2Fix | + | brand-new-user | staff?group | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | maintenance#123 | + | brand-new-user | 50%pass | + | brand-new-user | 50%25=0 | + | brand-new-user | 50%2Eagle | + | brand-new-user | 50%2Fix | + | brand-new-user | staff?group | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | maintenance#123 | + | brand-new-user | 50%pass | + | brand-new-user | 50%25=0 | + | brand-new-user | 50%2Eagle | + | brand-new-user | 50%2Fix | + | brand-new-user | staff?group | + + @issue-31015 @skipOnOcV10 + Scenario: admin removes a user from a group that has a forward-slash in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | priv/subadmins/1 | Subadmins mentioned not at the end | + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | priv/subadmins/1 | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | priv/subadmins/1 | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | priv/subadmins/1 | + + @toImplementOnOCIS @issue-product-283 + Scenario Outline: remove a user from a group using mixes of upper and lower case in user and group names + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "" has been created + And group "" has been created + And group "" has been created + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + When the administrator removes user "" from group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "" + But user "brand-new-user" should belong to group "" + And user "brand-new-user" should belong to group "" + Examples: + | user_id | group_id1 | group_id2 | group_id3 | + | BRAND-NEW-USER | Mixed-Group | mixed-group | MIXED-GROUP | + | Brand-New-User | mixed-group | MIXED-GROUP | Mixed-Group | + | brand-new-user | MIXED-GROUP | Mixed-Group | mixed-group | + + + Scenario: admin tries to remove a user from a group which does not exist + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "nonexistentgroup" has been deleted + When the administrator removes user "brand-new-user" from group "nonexistentgroup" using the provisioning API + Then the OCS status code should be "400" + And the HTTP status code should be "400" + And the API should not return any data + + @smokeTest @notToImplementOnOCIS + Scenario: a subadmin can remove users from groups the subadmin is responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | subadmin | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "subadmin" has been made a subadmin of group "brand-new-group" + When user "subadmin" removes user "brand-new-user" from group "brand-new-group" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "brand-new-group" + + @notToImplementOnOCIS + Scenario: a subadmin cannot remove users from groups the subadmin is not responsible for + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-subadmin | + And group "brand-new-group" has been created + And group "another-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "another-subadmin" has been made a subadmin of group "another-new-group" + When user "another-subadmin" removes user "brand-new-user" from group "brand-new-group" using the provisioning API + Then the OCS status code should be "403" + And the HTTP status code should be "403" + And user "brand-new-user" should belong to group "brand-new-group" + + @issue-31276 @skipOnOcV10 + Scenario: normal user tries to remove a user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "another-new-user" has been added to group "brand-new-group" + When user "brand-new-user" tries to remove user "another-new-user" from group "brand-new-group" using the provisioning API + Then the OCS status code should be "401" + And the HTTP status code should be "401" + And user "another-new-user" should belong to group "brand-new-group" + + # merge this with scenario on line 62 once the issue is fixed + @issue-31015 @skipOnOcV10 @toImplementOnOCIS @issue-product-284 + Scenario Outline: admin removes a user from a group that has a forward-slash and dot in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + And group "" has been created + And user "brand-new-user" has been added to group "" + When the administrator removes user "brand-new-user" from group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "" + Examples: + | group_id | comment | + | var/../etc | using slash-dot-dot | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31015.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31015.feature new file mode 100644 index 00000000000..dc5c83ce12b --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31015.feature @@ -0,0 +1,48 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: remove a user from a group + As an admin + I want to be able to remove a user from a group + So that I can manage user access to group resources + + Background: + Given using OCS API version "2" + + @issue-31015 + Scenario: admin removes a user from a group that has a forward-slash in the group name + Given user "brand-new-user" has been created with default attributes and without skeleton files + # After fixing issue-31015, change the following step to "has been created" + And the administrator sends a group creation request for the following groups using the provisioning API + | groupname | comment | + | Mgmt/Sydney | Slash (special escaping happens) | + | Mgmt//NSW/Sydney | Multiple slash | + | var/../etc | using slash-dot-dot | + | priv/subadmins/1 | Subadmins mentioned not at the end | + #And group "" has been created + And the following users have been added to the following groups + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | var/../etc | + | brand-new-user | priv/subadmins/1 | + When the administrator removes the following users from the following groups using the provisioning API + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | var/../etc | + | brand-new-user | priv/subadmins/1 | + Then the OCS status code of responses on all endpoints should be "200" + And the HTTP status code of responses on all endpoints should be "200" + And the following users should not belong to the following groups + | username | groupname | + | brand-new-user | Mgmt/Sydney | + | brand-new-user | Mgmt//NSW/Sydney | + | brand-new-user | var/../etc | + | brand-new-user | priv/subadmins/1 | + # 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 the following groups using the occ command + | groupname | + | Mgmt/Sydney | + | Mgmt//NSW/Sydney | + | var/../etc | + | priv/subadmins/1 | diff --git a/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31276.feature b/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31276.feature new file mode 100644 index 00000000000..9199f32115f --- /dev/null +++ b/tests/acceptance/features/coreApiProvisioningGroups-v2/removeFromGroupOc10Issue31276.feature @@ -0,0 +1,23 @@ +@api @provisioning_api-app-required @skipOnLDAP @notToImplementOnOCIS @skipOnGraph +Feature: remove a user from a group + As an admin + I want to be able to remove a user from a group + So that I can manage user access to group resources + + Background: + Given using OCS API version "2" + + @issue-31276 + Scenario: normal user tries to remove a user in their group + Given these users have been created with default attributes and without skeleton files: + | username | + | brand-new-user | + | another-new-user | + And group "brand-new-group" has been created + And user "brand-new-user" has been added to group "brand-new-group" + And user "another-new-user" has been added to group "brand-new-group" + When user "brand-new-user" tries to remove user "another-new-user" from group "brand-new-group" using the provisioning API + Then the OCS status code should be "997" + #And the OCS status code should be "401" + And the HTTP status code should be "401" + And user "another-new-user" should belong to group "brand-new-group" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareExpirationDate.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareExpirationDate.feature new file mode 100644 index 00000000000..281eaa95731 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareExpirationDate.feature @@ -0,0 +1,873 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: a default expiration date can be specified for shares with users or groups + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares without specifying expireDate + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +15 days | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_type | user | + | file_target | /FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | %username% | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date not enabled, user shares with expiration date set + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +15 days | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_type | user | + | file_target | /FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | %username% | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +15 days | + When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | %username% | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /FOLDER | + | uid_owner | %username% | + | share_with | %username% | + | expiration | +7 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +7 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares without specifying expireDate + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +15 days | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_type | group | + | file_target | /FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | grp1 | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date not enabled for groups, user shares with expiration date set + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +15 days | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_type | group | + | file_target | /FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | grp1 | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +15 days | + When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with group "grp1" should include + | share_type | group | + | file_target | /FOLDER | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +15 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +3 days | + When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with group "grp1" should include + | share_type | group | + | file_target | /FOLDER | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +3 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +3 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_type | user | + | file_target | /textfile0.txt | + | uid_owner | %username% | + | share_with | %username% | + | expiration | +7 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +7 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date more than the default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +10 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 7 days in the future" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_type | user | + | file_target | /textfile0.txt | + | uid_owner | %username% | + | share_with | %username% | + | expiration | +30 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +30 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date set, user shares with expiration date more than the max expire date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +40 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 30 days in the future" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares and changes the max expire date greater than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" with permissions "read,share" + When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "40" + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled for users/max expire date is set, user shares and changes max expire date less than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" with permissions "read,share" + When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "15" + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_type | group | + | file_target | /textfile0.txt | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +7 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +7 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date more than the default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +10 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 7 days in the future" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date is set, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_type | group | + | file_target | /textfile0.txt | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +30 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +30 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date set, user shares with expiration date more than the max expire date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +40 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 30 days in the future" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes the max expire date greater than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share" + When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "40" + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes max expire date less than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share" + When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "15" + Then the HTTP status code should be "200" + And the response when user "Alice" gets the info of the last share should include + | expiration | +30 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enforced for users, user shares to a group without setting an expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + When user "Alice" shares file "FOLDER" with group "grp1" with permissions "read,share" using the sharing API + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with group "grp1" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enforced for groups, user shares to another user + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + When user "Alice" shares file "/FOLDER" with user "Brian" with permissions "read,share" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enforced for users, user shares with invalid expiration date set + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | INVALID-DATE | + Then the HTTP status code should be "" + And the OCS status code should be "" + And the OCS status message should be "Invalid date, date format must be YYYY-MM-DD" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 404 | 200 | + | 2 | 404 | 404 | + + + Scenario Outline: sharing with default expiration date enforced for users, user shares with different time format + Given using OCS API version "2" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | | + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the fields of the last response to user "Alice" should include + | expiration | 2050-12-11 | + And the response when user "Brian" gets the info of the last share should include + | expiration | 2050-12-11 | + Examples: + | date | + | 2050-12-11 | + | 11-12-2050 | + | 12/11/2050 | + | 11.12.2050 | + | 11.12.2050 12:30:40 | + + + Scenario Outline: user shares with humanized expiration date format + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | expiration_date | default | enforce | ocs_status_code | + | 1 | today | yes | yes | 100 | + | 2 | today | yes | yes | 200 | + | 1 | tomorrow | yes | yes | 100 | + | 2 | tomorrow | yes | yes | 200 | + | 1 | today | yes | no | 100 | + | 2 | today | yes | no | 200 | + | 1 | tomorrow | yes | no | 100 | + | 2 | tomorrow | yes | no | 200 | + | 1 | today | no | no | 100 | + | 2 | today | no | no | 200 | + | 1 | tomorrow | no | no | 100 | + | 2 | tomorrow | no | no | 200 | + + + Scenario Outline: user shares with humanized expiration date format in past + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | yesterday | + Then the HTTP status code should be "" + And the OCS status code should be "" + And the OCS status message should be "Expiration date is in the past" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | ocs_status_code | http_status_code | default | enforce | + | 1 | 404 | 200 | yes | yes | + | 2 | 404 | 404 | yes | yes | + | 1 | 404 | 200 | yes | no | + | 2 | 404 | 404 | yes | no | + | 1 | 404 | 200 | no | no | + | 2 | 404 | 404 | no | no | + + + Scenario Outline: user shares with invalid humanized expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | 123 | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Invalid date, date format must be YYYY-MM-DD" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | default | enforce | + | 1 | 200 | yes | yes | + | 2 | 404 | yes | yes | + | 1 | 200 | yes | no | + | 2 | 404 | yes | no | + | 1 | 200 | no | no | + | 2 | 404 | no | no | + + + Scenario Outline: sharing with default expiration date enforced for users, user shares with past expiration date set + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | -10 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Expiration date is in the past" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @issue-36569 + Scenario Outline: sharing with default expiration date enforced for users, max expire date is 0, user shares without specifying expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "0" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include + | expiration | today | + And the response when user "Brian" gets the info of the last share should include + | expiration | today | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enforced for users, max expire date is 1, user shares without specifying expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "1" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include + | expiration | tomorrow | + And the response when user "Brian" gets the info of the last share should include + | expiration | tomorrow | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario: accessing a user share that is expired should not be possible + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | /textfile0.txt | + | shareType | user | + | shareWith | Brian | + | expireDate | +15 days | + And the administrator has expired the last created share using the testing API + When user "Alice" gets the info of the last share using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "200" + And user "Alice" should not see the share id of the last share + And user "Brian" should not see the share id of the last share + And as "Brian" file "/textfile0.txt" should not exist + And as "Alice" file "/textfile0.txt" should exist + + + Scenario: accessing a group share that is expired should not be possible + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + And group "brand-new-group" has been created + And user "Brian" has been added to group "brand-new-group" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | /textfile0.txt | + | shareType | group | + | shareWith | brand-new-group | + | expireDate | +15 days | + And the administrator has expired the last created share using the testing API + When user "Alice" gets the info of the last share using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "200" + And user "Alice" should not see the share id of the last share + And user "Brian" should not see the share id of the last share + And as "Brian" file "/textfile0.txt" should not exist + And as "Alice" file "/textfile0.txt" should exist + + + Scenario: accessing a link share that is expired should not be possible + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + And group "brand-new-group" has been created + And user "Brian" has been added to group "brand-new-group" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a public link share with settings + | path | /textfile0.txt | + | shareWith | brand-new-group | + | expireDate | +15 days | + And the administrator has expired the last created public link share using the testing API + When the public accesses the preview of file "textfile0.txt" from the last shared public link using the sharing API + Then the HTTP status code should be "404" + And as "Alice" file "/textfile0.txt" should exist + + + Scenario Outline: sharing file with edit permissions + Given using OCS API version "" + And auto-accept shares has been disabled + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "Random data" to "/file.txt" + When user "Alice" creates a share using the sharing API with settings + | path | file.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,update | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | item_type | file | + | mimetype | text/plain | + | share_type | user | + | file_target | /file.txt | + | uid_owner | %username% | + | share_with | %username% | + | permissions | read,update | + When user "Brian" accepts share "/file.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Brian" uploads the following files with content "new content" + | path | + | /file.txt | + Then the content of the following files for user "Brian" should be "new content" + | path | + | /file.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature new file mode 100644 index 00000000000..ada9235ab2f --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature @@ -0,0 +1,181 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: share resources where the sharee receives the share in multiple ways + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Creating a new share with user who already received a share through their group + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + When user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /textfile0.txt | + | path | /textfile0.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Share of folder and sub-folder to same user - core#20645 + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp4" has been created + And user "Brian" has been added to group "grp4" + And user "ALice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/CHILD/child.txt" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares folder "/PARENT/CHILD" with group "grp4" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /PARENT/ | + | /PARENT/parent.txt | + | /CHILD/ | + | /CHILD/child.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing subfolder when parent already shared + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with group "grp1" + When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" folder "/sub" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing subfolder when parent already shared with group of sharer + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp0" has been created + And user "Alice" has been added to group "grp0" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with group "grp0" + When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" folder "/sub" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: multiple users share a file with the same name but different permissions to a user + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Brian" has uploaded file with content "First data" to "/randomfile.txt" + And user "Carol" has uploaded file with content "Second data" to "/randomfile.txt" + When user "Brian" shares file "randomfile.txt" with user "Alice" with permissions "read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Alice" the info about the last share by user "Brian" with user "Alice" should include + | uid_owner | %username% | + | share_with | %username% | + | file_target | /randomfile.txt | + | item_type | file | + | permissions | read | + When user "Carol" shares file "randomfile.txt" with user "Alice" with permissions "read,update" using the sharing API + And as "Alice" the info about the last share by user "Carol" with user "Alice" should include + | uid_owner | %username% | + | share_with | %username% | + | file_target | /randomfile (2).txt | + | item_type | file | + | permissions | read,update | + And the content of file "randomfile.txt" for user "Alice" should be "First data" + And the content of file "randomfile (2).txt" for user "Alice" should be "Second data" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: multiple users share a folder with the same name to a user + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Brian" has created folder "/zzzfolder" + And user "Brian" has created folder "zzzfolder/Brian" + And user "Carol" has created folder "/zzzfolder" + And user "Carol" has created folder "zzzfolder/Carol" + When user "Brian" shares folder "zzzfolder" with user "Alice" with permissions "read,delete" using the sharing API + And as "Alice" the info about the last share by user "Brian" with user "Alice" should include + | uid_owner | %username% | + | share_with | %username% | + | file_target | /zzzfolder | + | item_type | folder | + | permissions | read,delete | + When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API + And as "Alice" the info about the last share by user "Carol" with user "Alice" should include + | uid_owner | %username% | + | share_with | %username% | + | file_target | /zzzfolder (2) | + | item_type | folder | + | permissions | read,share | + And as "Alice" folder "zzzfolder/Brian" should exist + And as "Alice" folder "zzzfolder (2)/Carol" should exist + Examples: + | ocs_api_version | + | 1 | + | 2 | + + @skipOnEncryptionType:user-keys @encryption-issue-132 @skipOnLDAP + Scenario Outline: share with a group and then add a user to that group that already has a file with the shared name + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And these groups have been created: + | groupname | + | grp1 | + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "Shared content" to "lorem.txt" + And user "Carol" has uploaded file with content "My content" to "lorem.txt" + When user "Alice" shares file "lorem.txt" with group "grp1" using the sharing API + And the administrator adds user "Carol" to group "grp1" using the provisioning API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the content of file "lorem.txt" for user "Brian" should be "Shared content" + And the content of file "lorem.txt" for user "Carol" should be "My content" + And the content of file "lorem (2).txt" for user "Carol" should be "Shared content" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature new file mode 100644 index 00000000000..8a61aab58e0 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature @@ -0,0 +1,289 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: Sharing resources with different case names with the sharee and checking the coexistence of resources on sharee/receivers side + + Background: + Given using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario: sharing file with an internal user that has existing files with different case names + Given user "Alice" has uploaded the following files with content "some data" + | path | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + And user "Brian" has uploaded the following files with content "some data" + | path | + | TEXTFILE.txt | + | TEXT_FILE.txt | + | 123TEXTFILE.txt | + | TEXTFILE.xyz.txt | + When user "Alice" shares the following files with user "Brian" using the sharing API + | path | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | + | TEXTFILE.txt | + | TEXT_FILE.txt | + | 123TEXTFILE.txt | + | TEXTFILE.xyz.txt | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + + + Scenario: sharing folder with an internal user that has existing folders with different case names + Given user "Alice" has created the following folders + | path | + | /FO/ | + | /F_O/ | + | /123FO/ | + | /FO.XYZ/ | + And user "Brian" has created the following folders + | path | + | /fo/ | + | /f_o/ | + | /123fo/ | + | /fo.xyz/ | + When user "Alice" shares the following folders with user "Brian" using the sharing API + | path | + | /FO/ | + | /F_O/ | + | /123FO/ | + | /FO.XYZ/ | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist + | path | + | /FO/ | + | /F_O/ | + | /123FO/ | + | /FO.XYZ/ | + | /fo/ | + | /f_o/ | + | /123fo/ | + | /fo.xyz/ | + + + Scenario: sharing file with an internal user that has existing folders with different case names + Given user "Alice" has uploaded the following files with content "some data" + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + And user "Brian" has created the following folders + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | + When user "Alice" shares the following files with user "Brian" using the sharing API + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | + And as "Brian" the following files should exist + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + + + Scenario: sharing folder with an internal user that has existing files with different case names + Given user "Alice" has created the following folders + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | + And user "Brian" has uploaded the following files with content "some data" + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + When user "Alice" shares the following folders with user "Brian" using the sharing API + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + And as "Brian" the following folders should exist + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | + + + Scenario: sharing file with group members that has existing files with different case names + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded the following files with content "some data" + | path | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + And user "Brian" has uploaded the following files with content "some data" + | path | + | TEXTFILE.txt | + | TEXT_FILE.txt | + | 123TEXTFILE.txt | + | TEXTFILE.xyz.txt | + When user "Alice" shares the following files with group "grp1" using the sharing API + | path | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | + | TEXTFILE.txt | + | TEXT_FILE.txt | + | 123TEXTFILE.txt | + | TEXTFILE.xyz.txt | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + + + Scenario: sharing folder with group members that has existing folders with different case names + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created the following folders + | path | + | /FO/ | + | /F_O/ | + | /123FO/ | + | /FO.XYZ/ | + And user "Brian" has created the following folders + | path | + | /fo/ | + | /f_o/ | + | /123fo/ | + | /fo.xyz/ | + When user "Alice" shares the following folders with group "grp1" using the sharing API + | path | + | /FO/ | + | /F_O/ | + | /123FO/ | + | /FO.XYZ/ | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist + | path | + | /fo/ | + | /f_o/ | + | /123fo/ | + | /fo.xyz/ | + | /FO/ | + | /F_O/ | + | /123FO/ | + | /FO.XYZ/ | + + + Scenario: sharing file with group members that has existing folders with different case names + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded the following files with content "some data" + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + And user "Brian" has created the following folders + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | + When user "Alice" shares the following files with group "grp1" using the sharing API + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | + And as "Brian" the following files should exist + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + + + Scenario: sharing folder with group members that has existing files with different case names + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created the following folders + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | + And user "Brian" has uploaded the following files with content "some data" + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + When user "Alice" shares the following folders with group "grp1" using the sharing API + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + And as "Brian" the following folders should exist + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature new file mode 100644 index 00000000000..8c85193eeb4 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature @@ -0,0 +1,22 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: resources shared with the same name are received with unique names + + Background: + Given using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + + @smokeTest + Scenario: unique target names for incoming shares + Given user "Alice" has created folder "/foo" + And user "Brian" has created folder "/foo" + When user "Alice" shares folder "/foo" with user "Carol" using the sharing API + And user "Brian" shares folder "/foo" with user "Carol" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Carol" should see the following elements + | /foo/ | + | /foo (2)/ | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareWhenExcludedFromSharing.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareWhenExcludedFromSharing.feature new file mode 100644 index 00000000000..7837ce77c6b --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot1/createShareWhenExcludedFromSharing.feature @@ -0,0 +1,83 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: cannot share resources when in a group that is excluded from sharing + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: user who is excluded from sharing tries to share a file with another user + Given using OCS API version "" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/fileToShare.txt" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' + When user "Brian" shares file "fileToShare.txt" with user "Alice" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And as "Alice" file "fileToShare.txt" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: user who is excluded from sharing tries to share a file with a group + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | + | grp1 | + | grp2 | + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp2" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/fileToShare.txt" + When user "Brian" shares file "fileToShare.txt" with group "grp2" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And as "Carol" file "fileToShare.txt" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: user who is excluded from sharing tries to share a folder with another user + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' + And user "Brian" has created folder "folderToShare" + When user "Brian" shares folder "folderToShare" with user "Alice" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And as "Alice" folder "folderToShare" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: user who is excluded from sharing tries to share a folder with a group + Given using OCS API version "" + And group "grp0" has been created + And group "grp1" has been created + And user "Alice" has been added to group "grp0" + And user "Brian" has been added to group "grp1" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp0"]' + And user "Alice" has created folder "folderToShare" + When user "Alice" shares folder "folderToShare" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And as "Brian" folder "folderToShare" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareDefaultFolderForReceivedShares.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareDefaultFolderForReceivedShares.feature new file mode 100644 index 00000000000..2ff8c3cffec --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareDefaultFolderForReceivedShares.feature @@ -0,0 +1,21 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: shares are received in the default folder for received shares + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Do not allow sharing of the entire share_folder + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has unshared folder "ReceivedShares/FOLDER" + When user "Brian" shares folder "/ReceivedShares" with user "Alice" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | share_folder | + | 1 | 200 | /ReceivedShares | + | 2 | 404 | /ReceivedShares | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupAndUserWithSameName.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupAndUserWithSameName.feature new file mode 100644 index 00000000000..6c7679911f3 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupAndUserWithSameName.feature @@ -0,0 +1,82 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing works when a username and group name are the same + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + + @skipOnLDAP + Scenario: creating a new share with user and a group having same name + Given these users have been created without skeleton files: + | username | + | Brian | + | Carol | + And group "Brian" has been created + And user "Carol" has been added to group "Brian" + And user "Alice" has shared file "randomfile.txt" with group "Brian" + When user "Alice" shares file "randomfile.txt" with user "Brian" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /randomfile.txt | + And user "Carol" should see the following elements + | /randomfile.txt | + And the content of file "randomfile.txt" for user "Brian" should be "Random data" + And the content of file "randomfile.txt" for user "Carol" should be "Random data" + + @skipOnLDAP + Scenario: creating a new share with group and a user having same name + Given these users have been created without skeleton files: + | username | + | Brian | + | Carol | + And group "Brian" has been created + And user "Carol" has been added to group "Brian" + And user "Alice" has shared file "randomfile.txt" with user "Brian" + When user "Alice" shares file "randomfile.txt" with group "Brian" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /randomfile.txt | + And user "Carol" should see the following elements + | /randomfile.txt | + And the content of file "randomfile.txt" for user "Brian" should be "Random data" + And the content of file "randomfile.txt" for user "Carol" should be "Random data" + + @skipOnLDAP + Scenario: creating a new share with user and a group having same name but different case + Given these users have been created without skeleton files: + | username | + | Brian | + | Carol | + And group "Brian" has been created + And user "Carol" has been added to group "Brian" + And user "Alice" has shared file "randomfile.txt" with group "Brian" + When user "Alice" shares file "randomfile.txt" with user "Brian" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /randomfile.txt | + And user "Carol" should see the following elements + | /randomfile.txt | + And the content of file "randomfile.txt" for user "Brian" should be "Random data" + And the content of file "randomfile.txt" for user "Carol" should be "Random data" + + @skipOnLDAP + Scenario: creating a new share with group and a user having same name but different case + Given these users have been created without skeleton files: + | username | + | Brian | + | Carol | + And group "Brian" has been created + And user "Carol" has been added to group "Brian" + And user "Alice" has shared file "randomfile.txt" with user "Brian" + When user "Alice" shares file "randomfile.txt" with group "Brian" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Carol" should see the following elements + | /randomfile.txt | + And user "Brian" should see the following elements + | /randomfile.txt | + And the content of file "randomfile.txt" for user "Carol" should be "Random data" + And the content of file "randomfile.txt" for user "Brian" should be "Random data" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupCaseSensitive.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupCaseSensitive.feature new file mode 100644 index 00000000000..8eece2fb633 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareGroupCaseSensitive.feature @@ -0,0 +1,72 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: share with groups, group names are case-sensitive + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 1" to "/textfile1.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 2" to "/textfile2.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 3" to "/textfile3.txt" + + @skipOnLDAP @issue-ldap-250 + Scenario Outline: group names are case-sensitive, sharing with groups with different upper and lower case names + Given using OCS API version "" + And group "" has been created + And group "" has been created + And group "" has been created + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + | David | + And user "Brian" has been added to group "" + And user "Carol" has been added to group "" + And user "David" has been added to group "" + When user "Alice" shares file "textfile1.txt" with group "" using the sharing API + And user "Alice" shares file "textfile2.txt" with group "" using the sharing API + And user "Alice" shares file "textfile3.txt" with group "" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the content of file "textfile1.txt" for user "Brian" should be "ownCloud test text file 1" + And the content of file "textfile2.txt" for user "Carol" should be "ownCloud test text file 2" + And the content of file "textfile3.txt" for user "David" should be "ownCloud test text file 3" + Examples: + | ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code | + | 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 | + | 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 | + | 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 | + | 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 | + | 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 | + | 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 | + + @skipOnLDAP @issue-ldap-250 + Scenario Outline: group names are case-sensitive, sharing with nonexistent groups with different upper and lower case names + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + And group "" has been created + And user "Brian" has been added to group "" + When user "Alice" shares file "textfile1.txt" with group "" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | share_with | | + | file_target | /textfile1.txt | + | path | /textfile1.txt | + | permissions | share,read,update | + | uid_owner | %username% | + And the content of file "textfile1.txt" for user "Brian" should be "ownCloud test text file 1" + When user "Alice" shares file "textfile2.txt" with group "" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + When user "Alice" shares file "textfile3.txt" with group "" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code | http_status_code | + | 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 | 200 | + | 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 | 200 | + | 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 | 200 | + | 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 | 404 | + | 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 | 404 | + | 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 | 404 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWhenShareWithOnlyMembershipGroups.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWhenShareWithOnlyMembershipGroups.feature new file mode 100644 index 00000000000..ef0a517f99d --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWhenShareWithOnlyMembershipGroups.feature @@ -0,0 +1,95 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: cannot share resources outside the group when share with membership groups is enabled + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And group "grp0" has been created + And user "Alice" has been added to group "grp0" + + + Scenario Outline: sharer should not be able to share a folder to a group which he/she is not member of when share with only member group is enabled + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" folder "/PARENT" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | + + + Scenario Outline: sharer should be able to share a folder to a user who is not member of sharer group when share with only member group is enabled + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" folder "/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: sharer should be able to share a folder to a group which he/she is member of when share with only member group is enabled + Given using OCS API version "" + And user "Brian" has been added to group "grp0" + And user "Alice" has created folder "PARENT" + When user "Alice" shares folder "/PARENT" with group "grp0" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" folder "/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: sharer should not be able to share a file to a group which he/she is not member of when share with only member group is enabled + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" file "/textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | + + + Scenario Outline: sharer should be able to share a file to a group which he/she is member of when share with only member group is enabled + Given using OCS API version "" + And user "Brian" has been added to group "grp0" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/textfile0.txt" with group "grp0" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" file "/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: sharer should be able to share a file to a user who is not a member of sharer group when share with only member group is enabled + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" file "/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature new file mode 100644 index 00000000000..eb096241010 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUser.feature @@ -0,0 +1,27 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: share resources with a disabled user + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + + + Scenario Outline: Creating a new share with a disabled user + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" shares file "fileToShare.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "401" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 997 | + + @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 "fileToShare.txt" with user "Brian" using the sharing API + Then the OCS status code should be "401" + And the HTTP status code should be "401" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUserOc10Issue32068.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUserOc10Issue32068.feature new file mode 100644 index 00000000000..99c6d479ee4 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithDisabledUserOc10Issue32068.feature @@ -0,0 +1,16 @@ +@api @files_sharing-app-required @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 without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + + @issue-32068 + 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 "fileToShare.txt" with user "Brian" 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" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithInvalidPermissions.feature b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithInvalidPermissions.feature new file mode 100644 index 00000000000..45a788e175f --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToRoot2/createShareWithInvalidPermissions.feature @@ -0,0 +1,122 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: cannot share resources with invalid permissions + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: Cannot create a share of a file with invalid permissions + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareWith | Brian | + | shareType | user | + | permissions | | + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" entry "/textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | permissions | + | 1 | 400 | 200 | 0 | + | 2 | 400 | 400 | 0 | + | 1 | 404 | 200 | 32 | + | 2 | 404 | 404 | 32 | + + + Scenario Outline: Cannot create a share of a folder with invalid permissions + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + When user "Alice" creates a share using the sharing API with settings + | path | PARENT | + | shareWith | Brian | + | shareType | user | + | permissions | | + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" entry "PARENT" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | permissions | + | 1 | 400 | 200 | 0 | + | 2 | 400 | 400 | 0 | + | 1 | 404 | 200 | 32 | + | 2 | 404 | 404 | 32 | + + + Scenario Outline: Cannot create a share of a file with a user with only create permission + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareWith | Brian | + | shareType | user | + | permissions | create | + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" entry "textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 400 | 200 | + | 2 | 400 | 400 | + + + Scenario Outline: Cannot create a share of a file with a user with only (create,delete) permission + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareWith | Brian | + | shareType | user | + | permissions | | + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" entry "textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | permissions | + | 1 | 400 | 200 | delete | + | 2 | 400 | 400 | delete | + | 1 | 400 | 200 | create,delete | + | 2 | 400 | 400 | create,delete | + + @issue-ocis-reva-34 + Scenario Outline: Cannot create a share of a file with a group with only create permission + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareWith | grp1 | + | shareType | group | + | permissions | create | + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" entry "textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 400 | 200 | + | 2 | 400 | 400 | + + @issue-ocis-reva-34 + Scenario Outline: Cannot create a share of a file with a group with only (create,delete) permission + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareWith | grp1 | + | shareType | group | + | permissions | | + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" entry "textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | permissions | + | 1 | 400 | 200 | delete | + | 2 | 400 | 400 | delete | + | 1 | 400 | 200 | create,delete | + | 2 | 400 | 400 | create,delete | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareExpirationDate.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareExpirationDate.feature new file mode 100644 index 00000000000..315d3280467 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareExpirationDate.feature @@ -0,0 +1,757 @@ +@api @files_sharing-app-required @issue-ocis-1328 @issue-ocis-1250 +Feature: a default expiration date can be specified for shares with users or groups + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares without specifying expireDate + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And user "Alice" has created folder "/FOLDER" + When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "" + And the fields of the last response to user "Alice" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +15 days | + When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /Shares/FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | %username% | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date not enabled, user shares with expiration date set + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +15 days | + When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /Shares/FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | %username% | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +15 days | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /Shares/FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | %username% | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /Shares/FOLDER | + | uid_owner | %username% | + | share_with | %username% | + | expiration | +7 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +7 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares without specifying expireDate + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with group "grp1" + When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And the fields of the last response to user "Alice" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +15 days | + When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | group | + | file_target | /Shares/FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | grp1 | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date not enabled for groups, user shares with expiration date set + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +15 days | + When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | group | + | file_target | /Shares/FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | grp1 | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +15 days | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | group | + | file_target | /Shares/FOLDER | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +15 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +15 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created a share with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +3 days | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | group | + | file_target | /Shares/FOLDER | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +3 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +3 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /Shares/textfile0.txt | + | uid_owner | %username% | + | share_with | %username% | + | expiration | +7 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +7 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date more than the default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +10 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 7 days in the future" + And the sharing API should report to user "Brian" that no shares are in the pending state + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /Shares/textfile0.txt | + | uid_owner | %username% | + | share_with | %username% | + | expiration | +30 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date set, user shares with expiration date more than the max expire date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +40 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 30 days in the future" + And the sharing API should report to user "Brian" that no shares are in the pending state + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares and changes the max expire date greater than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" with permissions "read,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "40" + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled for users/max expire date is set, user shares and changes max expire date less than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" with permissions "read,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "15" + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | group | + | file_target | /Shares/textfile0.txt | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +7 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +7 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date more than the default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +10 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 7 days in the future" + And the sharing API should report to user "Brian" that no shares are in the pending state + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date is set, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | group | + | file_target | /Shares/textfile0.txt | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +30 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date set, user shares with expiration date more than the max expire date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +40 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 30 days in the future" + And the sharing API should report to user "Brian" that no shares are in the pending state + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes the max expire date greater than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "40" + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes max expire date less than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "15" + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + And the response when user "Brian" gets the info of the last share should include + | expiration | +30 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enforced for users, user shares to a group without setting an expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + And user "Alice" has shared folder "FOLDER" with group "grp1" with permissions "read,share" + When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enforced for groups, user shares to another user + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Alice" has created folder "FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,share" + When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: sharing with default expiration date enforced for users, user shares with invalid expiration date set + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | INVALID-DATE | + Then the HTTP status code should be "" + And the OCS status code should be "" + And the OCS status message should be "Invalid date, date format must be YYYY-MM-DD" + And the sharing API should report to user "Brian" that no shares are in the pending state + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 404 | 200 | + | 2 | 404 | 404 | + + + Scenario Outline: sharing with default expiration date enforced for users, user shares with different time format + Given using OCS API version "2" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + And the fields of the last response to user "Alice" should include + | expiration | 2050-12-11 | + And the response when user "Brian" gets the info of the last share should include + | expiration | 2050-12-11 | + Examples: + | date | + | 2050-12-11 | + | 11-12-2050 | + | 12/11/2050 | + | 11.12.2050 | + | 11.12.2050 12:30:40 | + + + Scenario Outline: user shares with humanized expiration date format + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the fields of the last response to user "Alice" should include + | expiration | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | expiration_date | default | enforce | + | 1 | today | yes | yes | + | 2 | today | yes | yes | + | 1 | tomorrow | yes | yes | + | 2 | tomorrow | yes | yes | + | 1 | today | yes | no | + | 2 | today | yes | no | + | 1 | tomorrow | yes | no | + | 2 | tomorrow | yes | no | + | 1 | today | no | no | + | 2 | today | no | no | + | 1 | tomorrow | no | no | + | 2 | tomorrow | no | no | + + + Scenario Outline: user shares with humanized expiration date format in past + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | yesterday | + Then the HTTP status code should be "" + And the OCS status code should be "" + And the OCS status message should be "Expiration date is in the past" + And the sharing API should report to user "Brian" that no shares are in the pending state + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | ocs_status_code | http_status_code | default | enforce | + | 1 | 404 | 200 | yes | yes | + | 2 | 404 | 404 | yes | yes | + | 1 | 404 | 200 | yes | no | + | 2 | 404 | 404 | yes | no | + | 1 | 404 | 200 | no | no | + | 2 | 404 | 404 | no | no | + + + Scenario Outline: user shares with invalid humanized expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | 123 | + Then the HTTP status code should be "" + And the OCS status code should be "" + And the OCS status message should be "Invalid date, date format must be YYYY-MM-DD" + And the sharing API should report to user "Brian" that no shares are in the pending state + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | ocs_status_code | http_status_code | default | enforce | + | 1 | 404 | 200 | yes | yes | + | 2 | 404 | 404 | yes | yes | + | 1 | 404 | 200 | yes | no | + | 2 | 404 | 404 | yes | no | + | 1 | 404 | 200 | no | no | + | 2 | 404 | 404 | no | no | + + + Scenario Outline: sharing with default expiration date enforced for users, user shares with past expiration date set + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | -10 days | + Then the HTTP status code should be "" + And the OCS status code should be "" + And the OCS status message should be "Expiration date is in the past" + And the sharing API should report to user "Brian" that no shares are in the pending state + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 404 | 200 | + | 2 | 404 | 404 | + + @issue-36569 + Scenario Outline: sharing with default expiration date enforced for users, max expire date is 0, user shares without specifying expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "0" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include + | expiration | today | + And the response when user "Brian" gets the info of the last share should include + | expiration | today | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with default expiration date enforced for users, max expire date is 1, user shares without specifying expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include + | expiration | tomorrow | + And the response when user "Brian" gets the info of the last share should include + | expiration | tomorrow | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareResourceCaseSensitiveName.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareResourceCaseSensitiveName.feature new file mode 100644 index 00000000000..19963c6ecd7 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareResourceCaseSensitiveName.feature @@ -0,0 +1,298 @@ +@api @files_sharing-app-required +Feature: Sharing resources with different case names with the sharee and checking the coexistence of resources on sharee/receivers side + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario: sharing files with different case names with an internal user + Given user "Alice" has uploaded the following files with content "some data" + | path | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + | TEXTFILE.txt | + | TEXT_FILE.txt | + | 123TEXTFILE.txt | + | TEXTFILE.xyz.txt | + When user "Alice" shares the following files with user "Brian" using the sharing API + | path | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + | TEXTFILE.txt | + | TEXT_FILE.txt | + | 123TEXTFILE.txt | + | TEXTFILE.xyz.txt | + And user "Brian" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /textfile.txt | + | /text_file.txt | + | /123textfile.txt | + | /textfile.XYZ.txt | + | /TEXTFILE.txt | + | /TEXT_FILE.txt | + | /123TEXTFILE.txt | + | /TEXTFILE.xyz.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | + | /Shares/textfile.txt | + | /Shares/text_file.txt | + | /Shares/123textfile.txt | + | /Shares/textfile.XYZ.txt | + | /Shares/TEXTFILE.txt | + | /Shares/TEXT_FILE.txt | + | /Shares/123TEXTFILE.txt | + | /Shares/TEXTFILE.xyz.txt | + + + Scenario: sharing folders with different case names with an internal user + Given user "Alice" has created the following folders + | path | + | /FO | + | /F_O | + | /123FO | + | /FO.XYZ | + | /fo | + | /f_o | + | /123fo | + | /fo.xyz | + When user "Alice" shares the following folders with user "Brian" using the sharing API + | path | + | /FO | + | /F_O | + | /123FO | + | /FO.XYZ | + | /fo | + | /f_o | + | /123fo | + | /fo.xyz | + And user "Brian" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /FO | + | /F_O | + | /123FO | + | /FO.XYZ | + | /fo | + | /f_o | + | /123fo | + | /fo.xyz | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist + | path | + | /Shares/FO | + | /Shares/F_O | + | /Shares/123FO | + | /Shares/FO.XYZ | + | /Shares/fo | + | /Shares/f_o | + | /Shares/123fo | + | /Shares/fo.xyz | + + + Scenario: sharing files and folders with different case names with an internal user + Given user "Alice" has uploaded the following files with content "some data" + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + And user "Alice" has created the following folders + | path | + | /CASESENSITIVE | + | /CASE_SENSITIVE | + | /123case_sensitive | + | /CASESENSITIVE.xyz | + When user "Alice" shares the following files with user "Brian" using the sharing API + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + And user "Alice" shares the following folders with user "Brian" using the sharing API + | path | + | /CASESENSITIVE | + | /CASE_SENSITIVE | + | /123case_sensitive | + | /CASESENSITIVE.xyz | + And user "Brian" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /casesensitive.txt | + | /case_sensitive.txt | + | /123CASE_SENSITIVE.txt | + | /casesensitive.xyz.txt | + | /CASESENSITIVE | + | /CASE_SENSITIVE | + | /123case_sensitive | + | /CASESENSITIVE.xyz | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | + | /Shares/casesensitive.txt | + | /Shares/case_sensitive.txt | + | /Shares/123CASE_SENSITIVE.txt | + | /Shares/casesensitive.xyz.txt | + And as "Brian" the following folders should exist + | path | + | /Shares/CASESENSITIVE | + | /Shares/CASE_SENSITIVE | + | /Shares/123case_sensitive | + | /Shares/CASESENSITIVE.xyz | + + + Scenario: sharing files with different case names with group members + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded the following files with content "some data" + | path | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + | TEXTFILE.txt | + | TEXT_FILE.txt | + | 123TEXTFILE.txt | + | TEXTFILE.xyz.txt | + When user "Alice" shares the following files with group "grp1" using the sharing API + | path | + | textfile.txt | + | text_file.txt | + | 123textfile.txt | + | textfile.XYZ.txt | + | TEXTFILE.txt | + | TEXT_FILE.txt | + | 123TEXTFILE.txt | + | TEXTFILE.xyz.txt | + And user "Brian" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /textfile.txt | + | /text_file.txt | + | /123textfile.txt | + | /textfile.XYZ.txt | + | /TEXTFILE.txt | + | /TEXT_FILE.txt | + | /123TEXTFILE.txt | + | /TEXTFILE.xyz.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | + | /Shares/textfile.txt | + | /Shares/text_file.txt | + | /Shares/123textfile.txt | + | /Shares/textfile.XYZ.txt | + | /Shares/TEXTFILE.txt | + | /Shares/TEXT_FILE.txt | + | /Shares/123TEXTFILE.txt | + | /Shares/TEXTFILE.xyz.txt | + + + Scenario: sharing folders with different case names with group members + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created the following folders + | path | + | /FO | + | /F_O | + | /123FO | + | /FO.XYZ | + | /fo | + | /f_o | + | /123fo | + | /fo.xyz | + When user "Alice" shares the following folders with group "grp1" using the sharing API + | path | + | /FO | + | /F_O | + | /123FO | + | /FO.XYZ | + | /fo | + | /f_o | + | /123fo | + | /fo.xyz | + And user "Brian" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /FO | + | /F_O | + | /123FO | + | /FO.XYZ | + | /fo | + | /f_o | + | /123fo | + | /fo.xyz | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist + | path | + | /Shares/FO | + | /Shares/F_O | + | /Shares/123FO | + | /Shares/FO.XYZ | + | /Shares/fo | + | /Shares/f_o | + | /Shares/123fo | + | /Shares/fo.xyz | + + + Scenario: sharing files and folders with different case names with group members + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded the following files with content "some data" + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + And user "Alice" has created the following folders + | path | + | /CASESENSITIVE | + | /CASE_SENSITIVE | + | /123case_sensitive | + | /CASESENSITIVE.xyz | + When user "Alice" shares the following files with group "grp1" using the sharing API + | path | + | casesensitive.txt | + | case_sensitive.txt | + | 123CASE_SENSITIVE.txt | + | casesensitive.xyz.txt | + And user "Alice" shares the following folders with group "grp1" using the sharing API + | path | + | /CASESENSITIVE | + | /CASE_SENSITIVE | + | /123case_sensitive | + | /CASESENSITIVE.xyz | + And user "Brian" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /casesensitive.txt | + | /case_sensitive.txt | + | /123CASE_SENSITIVE.txt | + | /casesensitive.xyz.txt | + | /CASESENSITIVE | + | /CASE_SENSITIVE | + | /123case_sensitive | + | /CASESENSITIVE.xyz | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | + | /Shares/casesensitive.txt | + | /Shares/case_sensitive.txt | + | /Shares/123CASE_SENSITIVE.txt | + | /Shares/casesensitive.xyz.txt | + And as "Brian" the following folders should exist + | path | + | /Shares/CASESENSITIVE | + | /Shares/CASE_SENSITIVE | + | /Shares/123case_sensitive | + | /Shares/CASESENSITIVE.xyz | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareUniqueReceivedNames.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareUniqueReceivedNames.feature new file mode 100644 index 00000000000..15739b7042f --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareUniqueReceivedNames.feature @@ -0,0 +1,34 @@ +@api @files_sharing-app-required +Feature: resources shared with the same name are received with unique names + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + + @smokeTest @issue-ocis-2131 + Scenario Outline: unique target names for incoming shares + Given user "Alice" has created folder "/foo" + And user "Brian" has created folder "/foo" + When user "Alice" shares folder "/foo" with user "Carol" using the sharing API + And user "Carol" accepts share "/foo" offered by user "Alice" using the sharing API + And user "Brian" shares folder "/foo" with user "Carol" using the sharing API + And user "Carol" accepts share "/foo" offered by user "Brian" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Carol" should see the following elements + | Shares/foo/ | + | | + @skipOnOcis + Examples: + | share | + | /Shares/foo (2)/ | + @skipOnOcV10 + Examples: + | share | + | /Shares/foo (1)/ | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareWhenExcludedFromSharing.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareWhenExcludedFromSharing.feature new file mode 100644 index 00000000000..3b8da45500c --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareWhenExcludedFromSharing.feature @@ -0,0 +1,83 @@ +@api @files_sharing-app-required @issue-ocis-reva-41 @skipOnOcis +Feature: cannot share resources when in a group that is excluded from sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + + + Scenario Outline: user who is excluded from sharing tries to share a file with another user + Given using OCS API version "" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/fileToShare.txt" + When user "Brian" shares file "fileToShare.txt" with user "Alice" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the sharing API should report to user "Alice" that no shares are in the pending state + And as "Alice" file "Shares/fileToShare.txt" should not exist + And as "Alice" file "fileToShare.txt" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: user who is excluded from sharing tries to share a file with a group + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp2" has been created + And user "Carol" has been added to group "grp2" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/fileToShare.txt" + When user "Brian" shares file "fileToShare.txt" with group "grp2" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the sharing API should report to user "Carol" that no shares are in the pending state + And as "Carol" file "Shares/fileToShare.txt" should not exist + And as "Carol" file "fileToShare.txt" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: user who is excluded from sharing tries to share a folder with another user + Given using OCS API version "" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' + And user "Brian" has created folder "folderToShare" + When user "Brian" shares folder "folderToShare" with user "Alice" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the sharing API should report to user "Alice" that no shares are in the pending state + And as "Alice" folder "Shares/folderToShare" should not exist + And as "Alice" folder "folderToShare" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: user who is excluded from sharing tries to share a folder with a group + Given using OCS API version "" + And group "grp0" has been created + And user "Alice" has been added to group "grp0" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp0"]' + And user "Alice" has created folder "folderToShare" + When user "Alice" shares folder "folderToShare" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the sharing API should report to user "Brian" that no shares are in the pending state + And as "Brian" folder "Shares/folderToShare" should not exist + And as "Brian" folder "folderToShare" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareDefaultFolderForReceivedShares.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareDefaultFolderForReceivedShares.feature new file mode 100644 index 00000000000..6080180b09a --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareDefaultFolderForReceivedShares.feature @@ -0,0 +1,23 @@ +@api @files_sharing-app-required @issue-ocis-1327 +Feature: shares are received in the default folder for received shares + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Do not allow sharing of the entire share_folder + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + And user "Brian" unshares folder "Shares/FOLDER" using the WebDAV API + And user "Brian" shares folder "/Shares" with user "Alice" using the sharing API + Then the OCS status code of responses on each endpoint should be "" respectively + And the HTTP status code of responses on each endpoint should be "" respectively + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100, 100, 404 | 200, 200, 204, 200 | + | 2 | 200, 200, 404 | 200, 200, 204, 404 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupAndUserWithSameName.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupAndUserWithSameName.feature new file mode 100644 index 00000000000..60d20827b8d --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupAndUserWithSameName.feature @@ -0,0 +1,95 @@ +@api @files_sharing-app-required +Feature: sharing works when a username and group name are the same + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + + @skipOnLDAP + Scenario: creating a new share with user and a group having same name + Given these users have been created without skeleton files: + | username | + | Brian | + | Carol | + And group "Brian" has been created + And user "Carol" has been added to group "Brian" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + And user "Alice" has shared file "randomfile.txt" with group "Brian" + And user "Carol" has accepted share "/randomfile.txt" offered by user "Alice" + When user "Alice" shares file "randomfile.txt" with user "Brian" using the sharing API + And user "Brian" accepts share "/randomfile.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /Shares/randomfile.txt | + And user "Carol" should see the following elements + | /Shares/randomfile.txt | + And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data" + And the content of file "/Shares/randomfile.txt" for user "Carol" should be "Random data" + + @skipOnLDAP + Scenario: creating a new share with group and a user having same name + Given these users have been created without skeleton files: + | username | + | Brian | + | Carol | + And group "Brian" has been created + And user "Carol" has been added to group "Brian" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + And user "Alice" has shared file "randomfile.txt" with user "Brian" + And user "Brian" has accepted share "/randomfile.txt" offered by user "Alice" + When user "Alice" shares file "randomfile.txt" with group "Brian" using the sharing API + And user "Carol" accepts share "/randomfile.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /Shares/randomfile.txt | + And user "Carol" should see the following elements + | /Shares/randomfile.txt | + And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data" + And the content of file "/Shares/randomfile.txt" for user "Carol" should be "Random data" + + @skipOnLDAP + Scenario: creating a new share with user and a group having same name but different case + Given these users have been created without skeleton files: + | username | + | Brian | + | Carol | + And group "brian" has been created + And user "Carol" has been added to group "brian" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + And user "Alice" has shared file "randomfile.txt" with group "brian" + And user "Carol" has accepted share "/randomfile.txt" offered by user "Alice" + When user "Alice" shares file "randomfile.txt" with user "Brian" using the sharing API + And user "Brian" accepts share "/randomfile.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /Shares/randomfile.txt | + And user "Carol" should see the following elements + | /Shares/randomfile.txt | + And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data" + And the content of file "/Shares/randomfile.txt" for user "Carol" should be "Random data" + + @skipOnLDAP + Scenario: creating a new share with group and a user having same name but different case + Given these users have been created without skeleton files: + | username | + | Brian | + | Carol | + And group "brian" has been created + And user "Carol" has been added to group "brian" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + And user "Alice" has shared file "randomfile.txt" with user "Brian" + And user "Brian" has accepted share "/randomfile.txt" offered by user "Alice" + When user "Alice" shares file "randomfile.txt" with group "brian" using the sharing API + And user "Carol" accepts share "/randomfile.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Carol" should see the following elements + | /Shares/randomfile.txt | + And user "Brian" should see the following elements + | /Shares/randomfile.txt | + And the content of file "/Shares/randomfile.txt" for user "Carol" should be "Random data" + And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupCaseSensitive.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupCaseSensitive.feature new file mode 100644 index 00000000000..08ddb5a53ad --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupCaseSensitive.feature @@ -0,0 +1,90 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: share with groups, group names are case-sensitive + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 1" to "/textfile1.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 2" to "/textfile2.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 3" to "/textfile3.txt" + + @skipOnLDAP @issue-ldap-250 + Scenario Outline: group names are case-sensitive, sharing with groups with different upper and lower case names + Given using OCS API version "" + And group "" has been created + And group "" has been created + And group "" has been created + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + | David | + And user "Brian" has been added to group "" + And user "Carol" has been added to group "" + And user "David" has been added to group "" + When user "Alice" shares file "textfile1.txt" with group "" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Brian" accepts share "/textfile1.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "/Shares/textfile1.txt" for user "Brian" should be "ownCloud test text file 1" + When user "Alice" shares file "textfile2.txt" with group "" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Carol" accepts share "/textfile2.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "/Shares/textfile2.txt" for user "Carol" should be "ownCloud test text file 2" + When user "Alice" shares file "textfile3.txt" with group "" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "David" accepts share "/textfile3.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "/Shares/textfile3.txt" for user "David" should be "ownCloud test text file 3" + Examples: + | ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code | + | 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 | + | 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 | + | 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 | + | 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 | + | 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 | + | 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 | + + @skipOnLDAP @issue-ldap-250 + Scenario Outline: group names are case-sensitive, sharing with nonexistent groups with different upper and lower case names + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + And group "" has been created + And user "Brian" has been added to group "" + When user "Alice" shares file "textfile1.txt" with group "" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Brian" accepts share "/textfile1.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | share_with | | + | file_target | /Shares/textfile1.txt | + | path | /Shares/textfile1.txt | + | permissions | share,read,update | + | uid_owner | %username% | + And the content of file "/Shares/textfile1.txt" for user "Brian" should be "ownCloud test text file 1" + When user "Alice" shares file "textfile2.txt" with group "" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + When user "Alice" shares file "textfile3.txt" with group "" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code | http_status_code | + | 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 | 200 | + | 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 | 200 | + | 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 | 200 | + | 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 | 404 | + | 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 | 404 | + | 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 | 404 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature new file mode 100644 index 00000000000..0c98008bdfd --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature @@ -0,0 +1,624 @@ +@api @files_sharing-app-required +Feature: share resources where the sharee receives the share in multiple ways + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: creating and accepting a new share with user who already received a share through their group + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "/textfile0.txt" offered by user "Alice" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | | + | path | /Shares/textfile0 (2).txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + @skipOnOcis + Examples: + | ocs_api_version | ocs_status_code | file_target | + | 1 | 100 | /Shares/textfile0 (2).txt | + | 2 | 200 | /Shares/textfile0 (2).txt | + + @skipOnOcV10 @issue-2131 + Examples: + | ocs_api_version | ocs_status_code | file_target | + | 1 | 100 | /textfile0 (2).txt | + | 2 | 200 | /textfile0 (2).txt | + + @issue-ocis-1289 + Scenario Outline: Share of folder and sub-folder to same user + Given using OCS API version "" + And group "grp4" has been created + And user "Brian" has been added to group "grp4" + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/CHILD/child.txt" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares folder "/PARENT/CHILD" with group "grp4" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "/PARENT" offered by user "Alice" + And user "Brian" should be able to accept pending share "" offered by user "Alice" + And user "Brian" should see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /Shares/CHILD/ | + | /Shares/CHILD/child.txt | + Examples: + | ocs_api_version | ocs_status_code | pending_sub_share_path | + | 1 | 100 | /CHILD | + | 2 | 200 | /CHILD | + + @issue-ocis-2021 + Scenario Outline: sharing subfolder when parent already shared + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with group "grp1" + When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "" offered by user "Alice" + And as "Brian" folder "/Shares/sub" should exist + Examples: + | ocs_api_version | ocs_status_code | pending_share_path | + | 1 | 100 | /sub | + | 2 | 200 | /sub | + + @issue-ocis-2021 + Scenario Outline: sharing subfolder when parent already shared with group of sharer + Given using OCS API version "" + And group "grp0" has been created + And user "Alice" has been added to group "grp0" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with group "grp0" + When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "" offered by user "Alice" + And as "Brian" folder "/Shares/sub" should exist + Examples: + | ocs_api_version | ocs_status_code | pending_share_path | + | 1 | 100 | /sub | + | 2 | 200 | /sub | + + + Scenario Outline: multiple users share a file with the same name but different permissions to a user + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has uploaded file with content "First data" to "/randomfile.txt" + And user "Carol" has uploaded file with content "Second data" to "/randomfile.txt" + When user "Brian" shares file "randomfile.txt" with user "Alice" with permissions "read" using the sharing API + And user "Alice" accepts share "/randomfile.txt" offered by user "Brian" using the sharing API + Then as "Alice" the info about the last share by user "Brian" with user "Alice" should include + | uid_owner | %username% | + | share_with | %username% | + | file_target | | + | item_type | file | + | permissions | read | + When user "Carol" shares file "randomfile.txt" with user "Alice" with permissions "read,update" using the sharing API + And user "Alice" accepts share "/randomfile.txt" offered by user "Carol" using the sharing API + Then as "Alice" the info about the last share by user "Carol" with user "Alice" should include + | uid_owner | %username% | + | share_with | %username% | + | file_target | | + | item_type | file | + | permissions | read,update | + And the content of file "/Shares/randomfile.txt" for user "Alice" should be "First data" + And the content of file "/Shares/randomfile (2).txt" for user "Alice" should be "Second data" + @skipOnOcis + Examples: + | ocs_api_version | file_target_1 | file_target_2 | + | 1 | /Shares/randomfile.txt | /Shares/randomfile (2).txt | + | 2 | /Shares/randomfile.txt | /Shares/randomfile (2).txt | + + @skipOnOcV10 @issue-ocis-2131 + Examples: + | ocs_api_version | file_target_1 | file_target_2 | + | 1 | /randomfile.txt | /randomfile (2).txt | + | 2 | /randomfile.txt | /randomfile (2).txt | + + + Scenario Outline: multiple users share a folder with the same name to a user + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/zzzfolder" + And user "Brian" has created folder "zzzfolder/Brian" + And user "Carol" has created folder "/zzzfolder" + And user "Carol" has created folder "zzzfolder/Carol" + When user "Brian" shares folder "zzzfolder" with user "Alice" with permissions "read,delete" using the sharing API + And user "Alice" accepts share "/zzzfolder" offered by user "Brian" using the sharing API + Then as "Alice" the info about the last share by user "Brian" with user "Alice" should include + | uid_owner | %username% | + | share_with | %username% | + | file_target | | + | item_type | folder | + | permissions | read,delete | + When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Alice" should be able to accept pending share "/zzzfolder" offered by user "Carol" + Then as "Alice" the info about the last share by user "Carol" with user "Alice" should include + | uid_owner | %username% | + | share_with | %username% | + | file_target | | + | item_type | folder | + | permissions | read,share | + And as "Alice" folder "/Shares/zzzfolder/Brian" should exist + And as "Alice" folder "/Shares/zzzfolder (2)/Carol" should exist + @skipOnOcis + Examples: + | ocs_api_version | file_target_1 | file_target_2 | ocs_status_code | + | 1 | /Shares/zzzfolder | /Shares/zzzfolder (2) | 100 | + | 2 | /Shares/zzzfolder | /Shares/zzzfolder (2) | 200 | + + @skipOnOcV10 @issue-ocis-2131 + Examples: + | ocs_api_version | file_target_1 | file_target_2 | ocs_status_code | + | 1 | /zzzfolder | /zzzfolder (2) | 100 | + | 2 | /zzzfolder | /zzzfolder (2) | 200 | + + @skipOnEncryptionType:user-keys @encryption-issue-132 @skipOnLDAP @skipOnGraph + Scenario Outline: share with a group and then add a user to that group that already has a file with the shared name + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And these groups have been created: + | groupname | + | grp1 | + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "Shared content" to "lorem.txt" + And user "Carol" has uploaded file with content "My content" to "lorem.txt" + And user "Alice" has created a share with settings + | path | /lorem.txt | + | shareType | group | + | shareWith | grp1 | + And user "Brian" has accepted share "/lorem.txt" offered by user "Alice" + When the administrator adds user "Carol" to group "grp1" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to accept pending share "/lorem.txt" offered by user "Alice" + And the content of file "Shares/lorem.txt" for user "Brian" should be "Shared content" + And the content of file "lorem.txt" for user "Carol" should be "My content" + And the content of file "Shares/lorem.txt" for user "Carol" should be "Shared content" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Sharing parent folder to user with all permissions and its child folder to group with read permission then check create operation + Given group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has created the following folders + | path | + | /parent | + | /parent/child1 | + | /parent/child1/child2 | + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has created a share with settings + | path | /parent | + | shareType | user | + | shareWith | Brian | + | permissions | all | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API + And user "Brian" accepts share "" offered by user "Carol" using the sharing API + And user "Alice" accepts share "" offered by user "Carol" using the sharing API + 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 "100" + And user "Brian" should be able to create folder "/Shares/parent/fo1" + And user "Brian" should be able to create folder "/Shares/parent/child1/fo2" + And user "Alice" should not be able to create folder "/Shares/child1/fo3" + @issue-2440 + Examples: + | path | + | /child1 | + + + Scenario Outline: Sharing parent folder to user with all permissions and its child folder to group with read permission then check rename operation + Given group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has created the following folders + | path | + | /parent | + | /parent/child1 | + | /parent/child1/child2 | + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt" + And user "Carol" has created a share with settings + | path | /parent | + | shareType | user | + | shareWith | Brian | + | permissions | all | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API + And user "Brian" accepts share "" offered by user "Carol" using the sharing API + And user "Alice" accepts share "" offered by user "Carol" using the sharing API + 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 "100" + And user "Brian" should be able to rename file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.txt" + And user "Brian" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt" + And user "Alice" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt" + @issue-2440 + Examples: + | path | + | /child1 | + + + Scenario Outline: Sharing parent folder to user with all permissions and its child folder to group with read permission then check delete operation + Given group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has created the following folders + | path | + | /parent | + | /parent/child1 | + | /parent/child1/child2 | + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt" + And user "Carol" has created a share with settings + | path | /parent | + | shareType | user | + | shareWith | Brian | + | permissions | all | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API + And user "Brian" accepts share "" offered by user "Carol" using the sharing API + And user "Alice" accepts share "" offered by user "Carol" using the sharing API + 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 "100" + And user "Brian" should be able to delete file "/Shares/parent/child1/child2/textfile-2.txt" + And user "Brian" should not be able to delete folder "/Shares/child1/child2" + And user "Alice" should not be able to delete folder "/Shares/child1/child2" + @issue-2440 + Examples: + | path | + | /child1 | + + + Scenario Outline: Sharing parent folder to user with all permissions and its child folder to group with read permission then check reshare operation + Given group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has created the following folders + | path | + | /parent | + | /parent/child1 | + | /parent/child1/child2 | + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has created a share with settings + | path | /parent | + | shareType | user | + | shareWith | Brian | + | permissions | all | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + And user "Brian" has accepted share "/parent" offered by user "Carol" + And user "Brian" has accepted share "" offered by user "Carol" + And user "Alice" has accepted share "" offered by user "Carol" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/parent | + | shareType | user | + | shareWith | Alice | + | permissions | read | + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And user "Alice" should be able to accept pending share "/parent" offered by user "Brian" + And as "Brian" folder "/Shares/child1" should exist + And as "Alice" folder "/Shares/child1" should exist + And as "Alice" folder "/Shares/parent" should exist + Examples: + | path | + | /child1 | + + + Scenario Outline: Sharing parent folder to group with read permission and its child folder to user with all permissions then check create operation + Given group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has created the following folders + | path | + | /parent | + | /parent/child1 | + | /parent/child1/child2 | + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has created a share with settings + | path | /parent | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | user | + | shareWith | Brian | + | permissions | all | + When user "Brian" accepts share "" offered by user "Carol" using the sharing API + And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API + And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API + 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 "100" + And user "Brian" should be able to create folder "/Shares/child1/fo1" + And user "Brian" should be able to create folder "/Shares/child1/child2/fo2" + But user "Brian" should not be able to create folder "/Shares/parent/fo3" + And user "Brian" should not be able to create folder "/Shares/parent/fo3" + And user "Alice" should not be able to create folder "/Shares/parent/fo3" + Examples: + | path | + | /child1 | + + + Scenario Outline: Sharing parent folder to group with read permission and its child folder to user with all permissions then check rename operation + Given group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has created the following folders + | path | + | /parent | + | /parent/child1 | + | /parent/child1/child2 | + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt" + And user "Carol" has created a share with settings + | path | /parent | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | user | + | shareWith | Brian | + | permissions | all | + When user "Brian" accepts share "" offered by user "Carol" using the sharing API + And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API + And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API + 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 "100" + And user "Brian" should be able to rename file "/Shares/child1/child2/textfile-2.txt" to "/Shares/child1/child2/rename.txt" + And user "Brian" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt" + And user "Alice" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt" + @issue-ocis-2440 + Examples: + | path | + | /child1 | + + + Scenario Outline: Sharing parent folder to group with read permission and its child folder to user with all permissions then check delete operation + Given group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has created the following folders + | path | + | /parent | + | /parent/child1 | + | /parent/child1/child2 | + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt" + And user "Carol" has created a share with settings + | path | /parent | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | user | + | shareWith | Brian | + | permissions | all | + When user "Brian" accepts share "" offered by user "Carol" using the sharing API + And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API + And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API + 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 "100" + And user "Brian" should be able to delete file "/Shares/child1/child2/textfile-2.txt" + And user "Brian" should not be able to delete folder "/Shares/parent/child1" + And user "Alice" should not be able to delete folder "/Shares/parent/child1" + @issue-ocis-2440 + Examples: + | path | + | /child1 | + + + Scenario Outline: Sharing parent folder to group with read permission and its child folder to user with all permissions then check reshare operation + Given group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has created the following folders + | path | + | /parent | + | /parent/child1 | + | /parent/child1/child2 | + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has created a share with settings + | path | /parent | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | user | + | shareWith | Brian | + | permissions | all | + When user "Brian" accepts share "" offered by user "Carol" using the sharing API + And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API + And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API + 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 "100" + And user "Brian" should be able to share folder "/Shares/child1" with user "Alice" with permissions "read" using the sharing API + And user "Alice" should be able to accept pending share "" offered by user "Brian" + And as "Brian" folder "/Shares/parent" should exist + And as "Alice" folder "/Shares/parent" should exist + And as "Alice" folder "/Shares/child1" should exist + Examples: + | path | + | /child1 | + + + Scenario Outline: Sharing parent folder to one group with all permissions and its child folder to another group with read permission + Given these groups have been created: + | groupname | + | grp1 | + | grp2 | + | grp3 | + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has created the following folders + | path | + | /parent | + | /parent/child1 | + | /parent/child1/child2 | + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp2" + And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt" + And user "Carol" has created a share with settings + | path | /parent | + | shareType | group | + | shareWith | grp1 | + | permissions | all | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | group | + | shareWith | grp2 | + | permissions | read | + When user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API + And user "Brian" accepts share "" offered by user "Carol" using the sharing API + 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 "100" + And user "Alice" should be able to create folder "/Shares/parent/child1/fo1" + And user "Alice" should be able to create folder "/Shares/parent/child1/child2/fo2" + And user "Alice" should be able to delete folder "/Shares/parent/child1/fo1" + And user "Alice" should be able to delete folder "/Shares/parent/child1/child2/fo2" + And user "Alice" should be able to rename file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.txt" + And user "Alice" should be able to share folder "/Shares/parent/child1" with group "grp3" with permissions "all" using the sharing API + And as "Brian" folder "/Shares/child1" should exist + And user "Brian" should not be able to create folder "/Shares/child1/fo1" + And user "Brian" should not be able to create folder "/Shares/child1/child2/fo2" + And user "Brian" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt" + And user "Brian" should not be able to share folder "/Shares/child1" with group "grp3" with permissions "read" using the sharing API + Examples: + | path | + | /child1 | + + @skipOnOcV10 @issue-39347 + Scenario Outline: Share receiver renames the received group share and shares same folder through user share again + Given using OCS API version "" + And group "grp" has been created + And user "Brian" has been added to group "grp" + And user "Alice" has been added to group "grp" + And user "Alice" has created folder "parent" + And user "Alice" has created folder "parent/child" + And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" + And user "Alice" has created a share with settings + | path | parent | + | shareType | group | + | shareWith | grp | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" + And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API + # Note: Brian has already accepted the share of this resource as a member of "grp". + # Now he has also received the same resource shared directly to "Brian". + # The server should effectively "auto-accept" this new "copy" of the resource + # and present to Brian only the single resource "Shares/sharedParent" + And as "Brian" folder "Shares/parent" should not exist + And as "Brian" folder "Shares/sharedParent" should exist + And as "Brian" file "Shares/sharedParent/child/lorem.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnOcV10 @issue-39347 + Scenario Outline: Share receiver renames a group share and receives same resource through user share with additional permissions + Given using OCS API version "" + And group "grp" has been created + And user "Brian" has been added to group "grp" + And user "Alice" has been added to group "grp" + And user "Alice" has created folder "parent" + And user "Alice" has created folder "parent/child" + And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" + And user "Alice" has created a share with settings + | path | parent | + | shareType | group | + | shareWith | grp | + | permissions | read | + And user "Brian" has accepted share "/parent" offered by user "Alice" + And user "Brian" has moved folder "/Shares/parent" to "/Shares/sharedParent" + When user "Alice" shares folder "parent" with user "Brian" with permissions "all" using the sharing API + # Note: Brian has already accepted the share of this resource as a member of "grp". + # Now he has also received the same resource shared directly to "Brian". + # The server should effectively "auto-accept" this new "copy" of the resource + # and present to Brian only the single resource "Shares/sharedParent" + Then as "Brian" folder "Shares/parent" should not exist + And as "Brian" folder "Shares/sharedParent" should exist + And as "Brian" file "Shares/sharedParent/child/lorem.txt" should exist + Examples: + | ocs_api_version | + | 1 | + | 2 | + + @skipOnOcV10 @issue-39347 + Scenario Outline: Share receiver renames a group share and receives same resource through user share with less permissions + Given using OCS API version "" + And group "grp" has been created + And user "Brian" has been added to group "grp" + And user "Alice" has been added to group "grp" + And user "Alice" has created folder "parent" + And user "Alice" has created folder "parent/child" + And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" + And user "Alice" has shared folder "parent" with group "grp" with permissions "all" + When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" + And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API + # Note: Brian has already accepted the share of this resource as a member of "grp". + # Now he has also received the same resource shared directly to "Brian". + # The server should effectively "auto-accept" this new "copy" of the resource + # and present to Brian only the single resource "Shares/sharedParent" + And as "Brian" folder "Shares/parent" should not exist + And as "Brian" folder "Shares/sharedParent" should exist + And as "Brian" file "Shares/sharedParent/child/lorem.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedMultipleWaysIssue39347.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedMultipleWaysIssue39347.feature new file mode 100644 index 00000000000..de6cc55f527 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedMultipleWaysIssue39347.feature @@ -0,0 +1,130 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: share resources where the sharee receives the share in multiple ways + + # These are the bug demonstration scenarios for https://github.com/owncloud/core/issues/39347 + # Once the issue is fixed, delete this file and unskip all the respective tests tagged with @issue-39347 + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: Share receiver renames the received group share and shares same folder through user share again + Given using OCS API version "" + And group "grp" has been created + And user "Brian" has been added to group "grp" + And user "Alice" has been added to group "grp" + And user "Alice" has created folder "parent" + And user "Alice" has created folder "parent/child" + And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" + And user "Alice" has created a share with settings + | path | parent | + | shareType | group | + | shareWith | grp | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" + And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API + And user "Brian" should be able to accept pending share "/parent" offered by user "Alice" + And as "Brian" folder "Shares/parent" should exist + And as "Brian" folder "Shares/sharedParent" should not exist + And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + # Note: after fixing the bug, this scenario is no longer relevant. + # Brian should not get a chance to decline (or accept) the 2nd share of the resource from Alice + Scenario Outline: Share receiver renames the received group share and declines another share of same folder through user share again + Given using OCS API version "" + And group "grp" has been created + And user "Brian" has been added to group "grp" + And user "Alice" has been added to group "grp" + And user "Alice" has created folder "parent" + And user "Alice" has created folder "parent/child" + And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" + And user "Alice" has created a share with settings + | path | parent | + | shareType | group | + | shareWith | grp | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" + And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API + And user "Brian" should be able to decline pending share "/parent" offered by user "Alice" + And as "Brian" folder "Shares/parent" should not exist + And as "Brian" folder "Shares/sharedParent" should not exist + And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Share receiver renames a group share and receives same resource through user share with additional permissions + Given using OCS API version "" + And group "grp" has been created + And user "Brian" has been added to group "grp" + And user "Alice" has been added to group "grp" + And user "Alice" has created folder "parent" + And user "Alice" has created folder "parent/child" + And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" + And user "Alice" has created a share with settings + | path | parent | + | shareType | group | + | shareWith | grp | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" + And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "all" using the sharing API + And user "Brian" should be able to accept pending share "/parent" offered by user "Alice" + And as "Brian" folder "Shares/parent" should exist + And as "Brian" folder "Shares/sharedParent" should not exist + And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist + And as "Brian" file "Shares/parent/child/lorem.txt" should exist + And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Share receiver renames a group share and receives same resource through user share with less permissions + Given using OCS API version " " + And group "grp" has been created + And user "Brian" has been added to group "grp" + And user "Alice" has been added to group "grp" + And user "Alice" has created folder "parent" + And user "Alice" has created folder "parent/child" + And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" + And user "Alice" has created a share with settings + | path | parent | + | shareType | group | + | shareWith | grp | + | permissions | all | + When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" + And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API + And user "Brian" should be able to accept pending share "/parent" offered by user "Alice" + And as "Brian" folder "Shares/parent" should exist + And as "Brian" folder "Shares/sharedParent" should not exist + And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist + And as "Brian" file "Shares/parent/child/lorem.txt" should exist + And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWhenShareWithOnlyMembershipGroups.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWhenShareWithOnlyMembershipGroups.feature new file mode 100644 index 00000000000..0ddcd246af9 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWhenShareWithOnlyMembershipGroups.feature @@ -0,0 +1,127 @@ +@api @files_sharing-app-required @issue-ocis-1328 +Feature: cannot share resources outside the group when share with membership groups is enabled + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + + @issue-ocis-1328 @skipOnOcis + Scenario Outline: sharer should not be able to share a folder to a group which he/she is not member of when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp0" has been created + And group "grp1" has been created + And user "Alice" has been added to group "grp0" + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" folder "/PARENT" should not exist + And as "Brian" folder "/Shares/PARENT" should not exist + And the sharing API should report to user "Brian" that no shares are in the pending state + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | + + + Scenario Outline: sharer should be able to share a folder to a user who is not member of sharer group when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp0" has been created + And user "Alice" has been added to group "grp0" + And user "Alice" has created folder "PARENT" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" folder "/Shares/PARENT" should exist + But as "Brian" folder "/PARENT" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharer should be able to share a folder to a group which he/she is member of when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp0" has been created + And user "Alice" has been added to group "grp0" + And user "Brian" has been added to group "grp0" + And user "Alice" has created folder "PARENT" + When user "Alice" shares folder "/PARENT" with group "grp0" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" folder "/Shares/PARENT" should exist + But as "Brian" folder "/PARENT" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-1328 @skipOnOcis + Scenario Outline: sharer should not be able to share a file to a group which he/she is not member of when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp0" has been created + And group "grp1" has been created + And user "Alice" has been added to group "grp0" + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" file "/textfile0.txt" should not exist + And as "Brian" file "/Shares/textfile0.txt" should not exist + And the sharing API should report to user "Brian" that no shares are in the pending state + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | + + + Scenario Outline: sharer should be able to share a file to a group which he/she is member of when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp0" has been created + And user "Alice" has been added to group "grp0" + And user "Brian" has been added to group "grp0" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/textfile0.txt" with group "grp0" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" file "/Shares/textfile0.txt" should exist + But as "Brian" file "/textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharer should be able to share a file to a user who is not a member of sharer group when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp0" has been created + And user "Alice" has been added to group "grp0" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/textfile0.txt" with user "Brian" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" file "/Shares/textfile0.txt" should exist + But as "Brian" file "/textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature new file mode 100644 index 00000000000..365d81730f3 --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature @@ -0,0 +1,30 @@ +@api @files_sharing-app-required @issue-ocis-1328 +Feature: share resources with a disabled user + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + + @issue-ocis-2212 + Scenario Outline: Creating a new share with a disabled user + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has been disabled + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "401" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 997 | + + @issue-32068 + 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 "textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "997" + #And the OCS status code should be "401" + And the HTTP status code should be "401" diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithInvalidPermissions.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithInvalidPermissions.feature new file mode 100644 index 00000000000..3f654ac014f --- /dev/null +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithInvalidPermissions.feature @@ -0,0 +1,118 @@ +@api @files_sharing-app-required +Feature: cannot share resources with invalid permissions + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has created folder "/PARENT" + + + Scenario Outline: Cannot create a share of a file or folder with invalid permissions + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" creates a share using the sharing API with settings + | path | | + | shareWith | Brian | + | shareType | user | + | permissions | | + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" entry "" should not exist + And as "Brian" entry "/Shares/" should not exist + And the sharing API should report to user "Brian" that no shares are in the pending state + Examples: + | ocs_api_version | ocs_status_code | http_status_code | item | permissions | + | 1 | 400 | 200 | textfile0.txt | 0 | + | 2 | 400 | 400 | textfile0.txt | 0 | + | 1 | 400 | 200 | PARENT | 0 | + | 2 | 400 | 400 | PARENT | 0 | + | 1 | 404 | 200 | textfile0.txt | 32 | + | 2 | 404 | 404 | textfile0.txt | 32 | + | 1 | 404 | 200 | PARENT | 32 | + | 2 | 404 | 404 | PARENT | 32 | + + + Scenario Outline: Cannot create a share of a file with a user with only create permission + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareWith | Brian | + | shareType | user | + | permissions | create | + Then the OCS status code should be "400" + And the HTTP status code should be "" + And as "Brian" entry "textfile0.txt" should not exist + And as "Brian" entry "/Shares/textfile0.txt" should not exist + And the sharing API should report to user "Brian" that no shares are in the pending state + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + + Scenario Outline: Cannot create a share of a file with a user with only (create,delete) permission + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareWith | Brian | + | shareType | user | + | permissions | | + Then the OCS status code should be "400" + And the HTTP status code should be "" + And as "Brian" entry "textfile0.txt" should not exist + And as "Brian" entry "/Shares/textfile0.txt" should not exist + And the sharing API should report to user "Brian" that no shares are in the pending state + Examples: + | ocs_api_version | http_status_code | permissions | + | 1 | 200 | delete | + | 2 | 400 | delete | + | 1 | 200 | create,delete | + | 2 | 400 | create,delete | + + @issue-ocis-reva-34 + Scenario Outline: Cannot create a share of a file with a group with only create permission + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareWith | grp1 | + | shareType | group | + | permissions | create | + Then the OCS status code should be "400" + And the HTTP status code should be "" + And as "Brian" entry "textfile0.txt" should not exist + And as "Brian" entry "/Shares/textfile0.txt" should not exist + And the sharing API should report to user "Brian" that no shares are in the pending state + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + @issue-ocis-reva-34 + Scenario Outline: Cannot create a share of a file with a group with only (create,delete) permission + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareWith | grp1 | + | shareType | group | + | permissions | | + Then the OCS status code should be "400" + And the HTTP status code should be "" + And as "Brian" entry "textfile0.txt" should not exist + And as "Brian" entry "/Shares/textfile0.txt" should not exist + And the sharing API should report to user "Brian" that no shares are in the pending state + Examples: + | ocs_api_version | http_status_code | permissions | + | 1 | 200 | delete | + | 2 | 400 | delete | + | 1 | 200 | create,delete | + | 2 | 400 | create,delete | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareFromLocalStorageToRootFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareFromLocalStorageToRootFolder.feature new file mode 100644 index 00000000000..154b87c8e4f --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareFromLocalStorageToRootFolder.feature @@ -0,0 +1,109 @@ +@api @local_storage @files_external-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: local-storage + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @skipOnEncryptionType:user-keys @encryption-issue-181 + Scenario Outline: Share a file inside a local external storage + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" + When user "Alice" shares file "/local_storage/filetoshare.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /filetoshare.txt | + | path | /local_storage/filetoshare.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + And as "Brian" file "/filetoshare.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Share a folder inside a local external storage + Given using OCS API version "" + And user "Alice" has created folder "/local_storage/foo" + When user "Alice" shares folder "/local_storage/foo" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /foo | + | path | /local_storage/foo | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | user | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnEncryptionType:user-keys @encryption-issue-181 + Scenario Outline: Share a file inside a local external storage to a group + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" + When user "Alice" shares file "/local_storage/filetoshare.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_with | grp1 | + | share_with_displayname | grp1 | + | file_target | /filetoshare.txt | + | path | /local_storage/filetoshare.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | group | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Share a folder inside a local external storage to a group + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Alice" has created folder "/local_storage/foo" + When user "Alice" shares folder "/local_storage/foo" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_with | grp1 | + | share_with_displayname | grp1 | + | file_target | /foo | + | path | /local_storage/foo | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | group | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareToRootFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareToRootFolder.feature new file mode 100644 index 00000000000..8f50be2609c --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementBasicToRoot/createShareToRootFolder.feature @@ -0,0 +1,593 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest @skipOnEncryptionType:user-keys @issue-32322 + Scenario Outline: Creating a share of a file with a user, the default permissions are read(1)+update(2)+can-share(16) + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | share_with_user_type | 0 | + | file_target | /textfile0.txt | + | path | /textfile0.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @skipOnEncryptionType:user-keys @issue-32322 + Scenario Outline: Creating a share of a file containing commas in the filename, with a user, the default permissions are read(1)+update(2)+can-share(16) + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "file with comma in filename" to "/sample,1.txt" + When user "Alice" shares file "sample,1.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /sample,1.txt | + | path | /sample,1.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + And the content of file "/sample,1.txt" for user "Brian" should be "file with comma in filename" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating a share of a file with a user and asking for various permission combinations + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /textfile0.txt | + | path | /textfile0.txt | + | permissions | | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + Examples: + | ocs_api_version | requested_permissions | granted_permissions | ocs_status_code | + # Ask for full permissions. You get share plus read plus update. create and delete do not apply to shares of a file + | 1 | 31 | 19 | 100 | + | 2 | 31 | 19 | 200 | + # Ask for read, share (17), create and delete. You get share plus read + | 1 | 29 | 17 | 100 | + | 2 | 29 | 17 | 200 | + # Ask for read, update, create, delete. You get read plus update. + | 1 | 15 | 3 | 100 | + | 2 | 15 | 3 | 200 | + # Ask for just update. You get exactly update (you do not get read or anything else) + | 1 | 2 | 2 | 100 | + | 2 | 2 | 2 | 200 | + + + Scenario Outline: Creating a share of a file with no permissions should fail + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "Random data" to "randomfile.txt" + When user "Alice" shares file "randomfile.txt" with user "Brian" with permissions "0" using the sharing API + Then the OCS status code should be "400" + And the HTTP status code should be "" + And as "Brian" file "randomfile.txt" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + + Scenario Outline: Creating a share of a folder with no permissions should fail + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/afolder" + When user "Alice" shares folder "afolder" with user "Brian" with permissions "0" using the sharing API + Then the OCS status code should be "400" + And the HTTP status code should be "" + And as "Brian" folder "afolder" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + + Scenario Outline: Creating a share of a folder with a user, the default permissions are all permissions(31) + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/FOLDER" + When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /FOLDER | + | path | /FOLDER | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | user | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating a share of a file with a group, the default permissions are read(1)+update(2)+can-share(16) + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_with | grp1 | + | share_with_displayname | grp1 | + | file_target | /textfile0.txt | + | path | /textfile0.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | group | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating a share of a folder with a group, the default permissions are all permissions(31) + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has created folder "/FOLDER" + When user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_with | grp1 | + | share_with_displayname | grp1 | + | file_target | /FOLDER | + | path | /FOLDER | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | group | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: Share of folder to a group + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "file in parent folder" to "/PARENT/parent.txt" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + Then user "Brian" should see the following elements + | /PARENT/ | + | /PARENT/parent.txt | + And the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should see the following elements + | /PARENT/ | + | /PARENT/parent.txt | + And the OCS status code should be "" + And the HTTP status code should be "200" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing again an own file while belonging to a group + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Brian" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Brian" has shared file "textfile0.txt" with group "grp1" + And user "Brian" has deleted the last share + When user "Brian" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing subfolder of already shared folder, GET result is correct + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + | David | + | Emily | + And user "Alice" has created folder "/folder1" + And user "Alice" has shared folder "/folder1" with user "Brian" + And user "Alice" has shared folder "/folder1" with user "Carol" + And user "Alice" has created folder "/folder1/folder2" + And user "Alice" has shared folder "/folder1/folder2" with user "David" + And user "Alice" has shared folder "/folder1/folder2" with user "Emily" + When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares" + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the response should contain 4 entries + And folder "/folder1" should be included as path in the response + And folder "/folder1/folder2" should be included as path in the response + When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares?path=/folder1/folder2" + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the response should contain 2 entries + And folder "/folder1" should not be included as path in the response + And folder "/folder1/folder2" should be included as path in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user shares a file with file name longer than 64 chars to another user + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" + When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user shares a file with file name longer than 64 chars to a group + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" + When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user shares a folder with folder name longer than 64 chars to another user + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test" to "/textfile0.txt" + And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" + And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" + When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user shares a folder with folder name longer than 64 chars to a group + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "ownCloud test" to "/textfile0.txt" + And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" + And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" + When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario: share with user when username contains capital letters + Given these users have been created without skeleton files: + | username | + | brian | + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" shares file "/randomfile.txt" with user "BRIAN" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "BRIAN" should include + | share_with | brian | + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | permissions | share,read,update | + | uid_owner | %username% | + And user "brian" should see the following elements + | /randomfile.txt | + And the content of file "randomfile.txt" for user "brian" should be "Random data" + + @skipOnLDAP + Scenario: creating a new share with user of a group when username contains capital letters + Given these users have been created without skeleton files: + | username | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" shares file "randomfile.txt" with group "grp1" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /randomfile.txt | + And the content of file "randomfile.txt" for user "Brian" should be "Random data" + + + Scenario Outline: Share of folder to a group with emoji in the name + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And group "😀 😁" has been created + And user "Brian" has been added to group "😀 😁" + And user "Carol" has been added to group "😀 😁" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "file in parent folder" to "/PARENT/parent.txt" + When user "Alice" shares folder "/PARENT" with group "😀 😁" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /PARENT/ | + | /PARENT/parent.txt | + And user "Carol" should see the following elements + | /PARENT/ | + | /PARENT/parent.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnEncryptionType:user-keys @encryption-issue-132 @skipOnLDAP + Scenario Outline: share with a group and then add a user to that group + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And these groups have been created: + | groupname | + | grp1 | + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "some content" to "lorem.txt" + And user "Alice" has shared file "lorem.txt" with group "grp1" + When the administrator adds user "Carol" to group "grp1" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "lorem.txt" for user "Brian" should be "some content" + And the content of file "lorem.txt" for user "Carol" should be "some content" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnLDAP + # deleting an LDAP group is not relevant or possible using the provisioning API + Scenario Outline: shares shared to deleted group should not be available + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" + When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares" + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_with | grp1 | + | file_target | /textfile0.txt | + | path | /textfile0.txt | + | uid_owner | %username% | + And as "Brian" file "/textfile0.txt" should exist + And as "Carol" file "/textfile0.txt" should exist + When the administrator deletes group "grp1" using the provisioning API + And user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares" + Then the OCS status code should be "" + And the HTTP status code should be "200" + And file "/textfile0.txt" should not be included as path in the response + And as "Brian" file "/textfile0.txt" should not exist + And as "Carol" file "/textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnFilesClassifier @issue-files-classifier-291 + Scenario: Share a file by multiple channels and download from sub-folder and direct file share + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/common" + And user "Alice" has created folder "/common/sub" + And user "Alice" has shared folder "common" with group "grp1" + And user "Brian" has uploaded file with content "ownCloud" to "/textfile0.txt" + And user "Brian" has shared file "textfile0.txt" with user "Carol" + And user "Brian" has moved file "/textfile0.txt" to "/common/textfile0.txt" + And user "Brian" has moved file "/common/textfile0.txt" to "/common/sub/textfile0.txt" + When user "Carol" uploads file "filesForUpload/file_to_overwrite.txt" to "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/common/sub/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line + And the content of file "/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line + And user "Carol" should see the following elements + | /common/sub/textfile0.txt | + | /textfile0.txt | + + + Scenario Outline: sharing back to resharer is not allowed + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "userZeroFolder" + And user "Alice" has shared folder "userZeroFolder" with user "Brian" + And user "Brian" has created folder "userZeroFolder/userOneFolder" + And user "Brian" has shared folder "userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share" + When user "Carol" shares folder "userOneFolder" with user "Brian" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Brian" folder "userOneFolder" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: sharing back to original sharer is not allowed + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "userZeroFolder" + And user "Alice" has shared folder "userZeroFolder" with user "Brian" + And user "Brian" has created folder "userZeroFolder/userOneFolder" + And user "Brian" has shared folder "userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share" + When user "Carol" shares folder "userOneFolder" with user "Alice" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Alice" folder "userOneFolder" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @issue-enterprise-3896 + Scenario Outline: sharing a subfolder to a user that already received parent folder share is not allowed + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + | David | + And user "Alice" has created folder "userZeroFolder" + And user "Alice" has shared folder "userZeroFolder" with user "Brian" + And user "Alice" has shared folder "userZeroFolder" with user "Carol" + And user "Brian" has created folder "userZeroFolder/userOneFolder" + And user "Brian" has shared folder "userZeroFolder/userOneFolder" with user "David" with permissions "read, share" + When user "David" shares folder "userOneFolder" with user "Carol" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "userOneFolder" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: shares to a deleted user should not be listed as shares for the sharer + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has shared file "textfile0.txt" with user "Carol" + And the administrator has deleted user "Brian" using the provisioning API + When user "Alice" gets all the shares from the file "textfile0.txt" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be included in the response + But user "Brian" should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-719 + Scenario Outline: Creating a share of a renamed file when another share exists + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/Folder1" + And user "Alice" has created folder "/Folder2" + And user "Alice" has shared folder "/Folder1" with user "Brian" + And user "Alice" has moved folder "/Folder2" to "/renamedFolder2" + When user "Alice" shares folder "/renamedFolder2" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /renamedFolder2 | + | path | /renamedFolder2 | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | user | + And as "Brian" folder "/renamedFolder2" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToRoot/deleteShareFromRoot.feature b/tests/acceptance/features/coreApiShareManagementBasicToRoot/deleteShareFromRoot.feature new file mode 100644 index 00000000000..ffdc7eb8615 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementBasicToRoot/deleteShareFromRoot.feature @@ -0,0 +1,182 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: Delete all group shares + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has shared file "fileToShare.txt" with group "grp1" + When user "Alice" deletes the last share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should not see the share id of the last share + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: delete a share + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has shared file "fileToShare.txt" with user "Brian" + When user "Alice" deletes the last share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share id should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario: orphaned shares + Given using OCS API version "1" + And user "Alice" has created folder "/common" + And user "Alice" has created folder "/common/sub" + And user "Alice" has shared folder "/common/sub" with user "Brian" + When user "Alice" deletes folder "/common" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" folder "/sub" should not exist + + @smokeTest @files_trashbin-app-required + Scenario: deleting a file out of a share as recipient creates a backup for the owner + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has moved file "/fileToShare.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + When user "Brian" deletes file "/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" file "/shared/shared_file.txt" should not exist + And as "Alice" file "/shared/shared_file.txt" should not exist + And as "Alice" file "/shared_file.txt" should exist in the trashbin + And as "Brian" file "/shared_file.txt" should exist in the trashbin + + @files_trashbin-app-required + Scenario: deleting a folder out of a share as recipient creates a backup for the owner + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/sub" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "shared/sub/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + When user "Brian" deletes folder "/shared/sub" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" folder "/shared/sub" should not exist + And as "Alice" folder "/shared/sub" should not exist + And as "Alice" folder "/sub" should exist in the trashbin + And as "Alice" file "/sub/shared_file.txt" should exist in the trashbin + And as "Brian" folder "/sub" should exist in the trashbin + And as "Brian" file "/sub/shared_file.txt" should exist in the trashbin + + @smokeTest + Scenario: unshare from self + And group "grp1" has been created + And these users have been created with default attributes and without skeleton files: + | username | + | Carol | + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Carol" has created folder "/PARENT" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" + And user "Carol" has shared file "/PARENT/parent.txt" with group "grp1" + And user "Carol" has stored etag of element "/PARENT" + And user "Brian" has stored etag of element "/" + When user "Brian" unshares file "parent.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the etag of element "/" of user "Brian" should have changed + And the etag of element "/PARENT" of user "Carol" should not have changed + + + Scenario: sharee of a read-only share folder tries to delete the shared folder + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "shared/shared_file.txt" + And user "Alice" has shared folder "shared" with user "Brian" with permissions "read" + When user "Brian" deletes file "/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Brian" file "/shared/shared_file.txt" should exist + + + Scenario: sharee of a upload-only shared folder tries to delete a file in the shared folder + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "shared/shared_file.txt" + And user "Alice" has shared folder "shared" with user "Brian" with permissions "create" + When user "Brian" deletes file "/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/shared/shared_file.txt" should exist + + + Scenario: sharee of an upload-only shared folder tries to delete their file in the folder + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has shared folder "shared" with user "Brian" with permissions "create" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "shared/textfile.txt" + When user "Brian" deletes file "/shared/textfile.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/shared/textfile.txt" should exist + + + Scenario Outline: A Group share recipient tries to delete the share + Given using OCS API version "" + And group "grp1" has been created + And these users have been created with default attributes and without skeleton files: + | username | + | Carol | + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" + And user "Alice" has shared entry "" with group "grp1" + When user "Brian" deletes the last share of user "Alice" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Alice" entry "" should exist + And as "Brian" entry "" should exist + And as "Carol" entry "" should exist + Examples: + | entry_to_share | ocs_api_version | http_status_code | received_entry | + | /PARENT/parent.txt | 1 | 200 | parent.txt | + | /PARENT/parent.txt | 2 | 404 | parent.txt | + | /PARENT | 1 | 200 | PARENT | + | /PARENT | 2 | 404 | PARENT | + + + Scenario Outline: An individual share recipient tries to delete the share + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" + And user "Alice" has shared entry "" with user "Brian" + When user "Brian" deletes the last share of user "Alice" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Alice" entry "" should exist + And as "Brian" entry "" should exist + Examples: + | entry_to_share | ocs_api_version | http_status_code | received_entry | + | /PARENT/parent.txt | 1 | 200 | parent.txt | + | /PARENT/parent.txt | 2 | 404 | parent.txt | + | /PARENT | 1 | 200 | PARENT | + | /PARENT | 2 | 404 | PARENT | + + + Scenario Outline: delete a share with wrong authentication + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has shared file "fileToShare.txt" with user "Brian" + When user "Brian" tries to delete the last share of user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 404 | 200 | + | 2 | 404 | 404 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToRoot/excludeGroupFromReceivingShares.feature b/tests/acceptance/features/coreApiShareManagementBasicToRoot/excludeGroupFromReceivingShares.feature new file mode 100644 index 00000000000..ca5ef40231d --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementBasicToRoot/excludeGroupFromReceivingShares.feature @@ -0,0 +1,159 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: Exclude groups from receiving shares + As an admin + I want to exclude groups from receiving shares + So that users do not mistakenly share with groups they should not e.g. huge meta groups + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + | David | + And group "grp1" has been created + And group "grp2" has been created + And user "Brian" has been added to group "grp1" + And user "David" has been added to group "grp2" + + + Scenario Outline: user cannot share with a group that is excluded from receiving shares but can share with other groups + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command + And user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And as "Brian" file "/fileToShare.txt" should not exist + When user "Alice" shares folder "PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And as "Brian" folder "/PARENT" should not exist + When user "Alice" shares file "fileToShare.txt" with group "grp2" using the sharing API + And user "Alice" shares folder "PARENT" with group "grp2" using the sharing API + Then as "David" file "/fileToShare.txt" should exist + And as "David" folder "/PARENT" should exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: exclude multiple groups from receiving shares stops the user to share with any of them + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And group "grp3" has been created + And user "Brian" has been added to group "grp3" + When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command + And the administrator adds group "grp2" to the exclude groups from receiving shares list using the occ command + And the administrator adds group "grp3" to the exclude groups from receiving shares list using the occ command + And user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And as "Brian" file "/fileToShare.txt" should not exist + When user "Alice" shares folder "PARENT" with group "grp2" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And as "Brian" folder "/PARENT" should not exist + When user "Alice" shares folder "PARENT/CHILD" with group "grp3" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And as "Brian" folder "/CHILD" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: user cannot reshare a received share with a group that is excluded from receiving shares but can share with other groups + Given using OCS API version "" + And user "Carol" has created folder "PARENT" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Carol" has shared file "fileToShare.txt" with user "Alice" + And user "Carol" has shared folder "PARENT" with user "Alice" + When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command + And user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And as "Brian" file "/fileToShare.txt" should not exist + When user "Alice" shares folder "PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And as "Brian" folder "/PARENT" should not exist + When user "Alice" shares file "fileToShare.txt" with group "grp2" using the sharing API + And user "Alice" shares folder "PARENT" with group "grp2" using the sharing API + Then as "David" file "/fileToShare.txt" should exist + And as "David" folder "/PARENT" should exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: sharing with a user that is part of a group that is excluded from receiving shares still works + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command + And user "Alice" shares file "fileToShare.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Alice" shares folder "PARENT" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" file "/fileToShare.txt" should exist + And as "Brian" folder "/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with a user that is part of a group that is excluded from receiving shares using an other group works + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And group "grp3" has been created + And user "Brian" has been added to group "grp3" + When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command + And user "Alice" shares file "fileToShare.txt" with group "grp3" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Alice" shares folder "PARENT" with group "grp3" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" file "/fileToShare.txt" should exist + And as "Brian" folder "/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: a user that is part of a group that is excluded from receiving shares still can initiate shares + Given using OCS API version "" + And user "Brian" has created folder "PARENT" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When the administrator adds group "grp1" to the exclude groups from receiving shares list using the occ command + And user "Brian" shares file "fileToShare.txt" with user "Carol" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Brian" shares folder "PARENT" with user "Carol" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" file "/fileToShare.txt" should exist + And as "Carol" folder "/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareFromLocalStorageToSharesFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareFromLocalStorageToSharesFolder.feature new file mode 100644 index 00000000000..d649a328ce3 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareFromLocalStorageToSharesFolder.feature @@ -0,0 +1,114 @@ +@api @local_storage @files_external-app-required @notToImplementOnOCIS @files_sharing-app-required +Feature: local-storage + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @skipOnEncryptionType:user-keys @encryption-issue-181 + Scenario Outline: Share a file inside a local external storage + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" + When user "Alice" shares file "/local_storage/filetoshare.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/filetoshare.txt | + | path | /local_storage/filetoshare.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + When user "Brian" accepts share "" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" file "/Shares/filetoshare.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | pending_share_path | + | 1 | 100 | /filetoshare.txt | + | 2 | 200 | /filetoshare.txt | + + + Scenario Outline: Share a folder inside a local external storage + Given using OCS API version "" + And user "Alice" has created folder "/local_storage/foo" + When user "Alice" shares folder "/local_storage/foo" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/foo | + | path | /local_storage/foo | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | user | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnEncryptionType:user-keys @encryption-issue-181 + Scenario Outline: Share a file inside a local external storage to a group + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" + When user "Alice" shares file "/local_storage/filetoshare.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_with | grp1 | + | share_with_displayname | grp1 | + | file_target | /Shares/filetoshare.txt | + | path | /local_storage/filetoshare.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | group | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Share a folder inside a local external storage to a group + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Alice" has created folder "/local_storage/foo" + When user "Alice" shares folder "/local_storage/foo" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_with | grp1 | + | share_with_displayname | grp1 | + | file_target | /Shares/foo | + | path | /local_storage/foo | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | group | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature new file mode 100644 index 00000000000..a7931f60b74 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature @@ -0,0 +1,783 @@ +@api @files_sharing-app-required +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + + @smokeTest @skipOnEncryptionType:user-keys @issue-32322 + Scenario Outline: Creating a share of a file with a user, the default permissions are read(1)+update(2)+can-share(16) + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | share_with_user_type | 0 | + | file_target | /Shares/textfile0.txt | + | path | /textfile0.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @skipOnEncryptionType:user-keys @issue-32322 @issue-ocis-2133 + Scenario Outline: Creating a share of a file containing commas in the filename, with a user, the default permissions are read(1)+update(2)+can-share(16) + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "file with comma in filename" to "/sample,1.txt" + When user "Alice" shares file "sample,1.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/sample,1.txt | + | path | /sample,1.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + When user "Brian" accepts share "/sample,1.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "/Shares/sample,1.txt" for user "Brian" should be "file with comma in filename" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-2133 @issue-ocis-reva-301 @issue-ocis-reva-302 + Scenario Outline: Creating a share of a file with a user and asking for various permission combinations + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/textfile0.txt | + | path | /textfile0.txt | + | permissions | | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + Examples: + | ocs_api_version | requested_permissions | granted_permissions | ocs_status_code | + # Ask for full permissions. You get share plus read plus update. create and delete do not apply to shares of a file + | 1 | 31 | 19 | 100 | + | 2 | 31 | 19 | 200 | + # Ask for read, share (17), create and delete. You get share plus read + | 1 | 29 | 17 | 100 | + | 2 | 29 | 17 | 200 | + # Ask for read, update, create, delete. You get read plus update. + | 1 | 15 | 3 | 100 | + | 2 | 15 | 3 | 200 | + # Ask for just update. You get exactly update (you do not get read or anything else) + | 1 | 2 | 2 | 100 | + | 2 | 2 | 2 | 200 | + + + Scenario Outline: Creating a share of a file with no permissions should fail + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "Random data" to "randomfile.txt" + When user "Alice" shares file "randomfile.txt" with user "Brian" with permissions "0" using the sharing API + Then the OCS status code should be "400" + And the HTTP status code should be "" + And the sharing API should report that no shares are shared with user "Brian" + And as "Brian" file "/Shares/randomfile.txt" should not exist + And as "Brian" file "randomfile.txt" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + + Scenario Outline: Creating a share of a folder with no permissions should fail + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/afolder" + When user "Alice" shares folder "afolder" with user "Brian" with permissions "0" using the sharing API + Then the OCS status code should be "400" + And the HTTP status code should be "" + And the sharing API should report that no shares are shared with user "Brian" + And as "Brian" folder "/Shares/afolder" should not exist + And as "Brian" folder "afolder" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + @issue-ocis-2133 + Scenario Outline: Creating a share of a folder with a user, the default permissions are all permissions(31) + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/FOLDER" + When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/FOLDER | + | path | /FOLDER | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | user | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-34 + Scenario Outline: Creating a share of a file with a group, the default permissions are read(1)+update(2)+can-share(16) + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_with | grp1 | + | share_with_displayname | grp1 | + | file_target | /Shares/textfile0.txt | + | path | /textfile0.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | group | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-34 + Scenario Outline: Creating a share of a folder with a group, the default permissions are all permissions(31) + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has created folder "/FOLDER" + When user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | grp1 | + | share_with_displayname | grp1 | + | file_target | /Shares/FOLDER | + | path | /FOLDER | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | group | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: Share of folder to a group + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "file in parent folder" to "/PARENT/parent.txt" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Carol" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + And user "Carol" should see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @skipOnReva # reva doesn't have a pre-created admin user + Scenario Outline: User included in multiple groups receives a share from the admin + Given using OCS API version "" + And group "grp1" has been created + And group "grp2" has been created + And user "Alice" has been added to group "grp1" + And user "Alice" has been added to group "grp2" + And admin has created folder "/PARENT" + When user "admin" shares folder "/PARENT" with group "grp1" using the sharing API + And user "Alice" accepts share "/PARENT" offered by user "admin" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: user included in multiple groups, shares a folder with a group + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + And group "grp1" has been created + And group "grp2" has been created + And user "Alice" has been added to group "grp1" + And user "Alice" has been added to group "grp2" + And user "Brian" has been added to group "grp1" + And user "Brian" has been added to group "grp2" + And user "Alice" has created folder "/PARENT" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing again an own file while belonging to a group + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Brian" has uploaded file with content "ownCloud test text file 0" to "/randomfile.txt" + And user "Brian" has shared file "randomfile.txt" with group "grp1" + And user "Brian" has deleted the last share + When user "Brian" shares file "/randomfile.txt" with group "grp1" using the sharing API + And user "Alice" accepts share "/randomfile.txt" offered by user "Brian" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And as "Alice" file "/Shares/randomfile.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-2201 + Scenario Outline: sharing subfolder of already shared folder, GET result is correct + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + | David | + | Emily | + And user "Alice" has created folder "/folder1" + And user "Alice" has shared folder "/folder1" with user "Brian" + And user "Alice" has shared folder "/folder1" with user "Carol" + And user "Alice" has created folder "/folder1/folder2" + And user "Alice" has shared folder "/folder1/folder2" with user "David" + And user "Alice" has shared folder "/folder1/folder2" with user "Emily" + When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares" + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the response should contain 4 entries + And folder "/folder1" should be included as path in the response + And folder "/folder1/folder2" should be included as path in the response + When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares?path=/folder1/folder2" + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the response should contain 2 entries + And folder "/folder1" should not be included as path in the response + And folder "/folder1/folder2" should be included as path in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user shares a file with file name longer than 64 chars to another user + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" + When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with user "Brian" using the sharing API + And user "Brian" accepts share "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user shares a file with file name longer than 64 chars to a group + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" + When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with group "grp1" using the sharing API + And user "Brian" accepts share "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user shares a folder with folder name longer than 64 chars to another user + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test" to "/textfile0.txt" + And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" + And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" + When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with user "Brian" using the sharing API + And user "Brian" accepts share "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the content of file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user shares a folder with folder name longer than 64 chars to a group + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "ownCloud test" to "/textfile0.txt" + And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" + And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" + When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with group "grp1" using the sharing API + And user "Brian" accepts share "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the content of file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-11 + Scenario: share with user when username contains capital letters + Given these users have been created without skeleton files: + | username | + | brian | + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" shares file "/randomfile.txt" with user "BRIAN" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "BRIAN" should include + | share_with | brian | + | file_target | /Shares/randomfile.txt | + | path | /randomfile.txt | + | permissions | share,read,update | + | uid_owner | %username% | + When user "brian" accepts share "/randomfile.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brian" should see the following elements + | /Shares/randomfile.txt | + And the content of file "Shares/randomfile.txt" for user "brian" should be "Random data" + + @skipOnLDAP + Scenario: creating a new share with user of a group when username contains capital letters + Given these users have been created without skeleton files: + | username | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + And user "Alice" has shared file "randomfile.txt" with group "grp1" + When user "Brian" accepts share "/randomfile.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /Shares/randomfile.txt | + And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data" + + @issue-ocis-reva-34 + Scenario Outline: Share of folder to a group with emoji in the name + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And group "😀 😁" has been created + And user "Brian" has been added to group "😀 😁" + And user "Carol" has been added to group "😀 😁" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "file in parent folder" to "/PARENT/parent.txt" + When user "Alice" shares folder "/PARENT" with group "😀 😁" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" accepts share "/PARENT" offered by user "Alice" using the sharing API + And the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + And user "Carol" should see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnEncryptionType:user-keys @encryption-issue-132 @skipOnLDAP @skipOnGraph + Scenario Outline: share with a group and then add a user to that group + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And these groups have been created: + | groupname | + | grp1 | + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "some content" to "lorem.txt" + When user "Alice" shares file "lorem.txt" with group "grp1" using the sharing API + And user "Brian" accepts share "/lorem.txt" offered by user "Alice" using the sharing API + And the administrator adds user "Carol" to group "grp1" using the provisioning API + And user "Carol" accepts share "/lorem.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the content of file "/Shares/lorem.txt" for user "Brian" should be "some content" + And the content of file "/Shares/lorem.txt" for user "Carol" should be "some content" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnLDAP + # deleting an LDAP group is not relevant or possible using the provisioning API + Scenario Outline: shares shared to deleted group should not be available + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" + When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares" + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | share_with | grp1 | + | file_target | | + | path | /textfile0.txt | + | uid_owner | %username% | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + And user "Carol" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then as "Brian" file "/Shares/textfile0.txt" should exist + And as "Carol" file "/Shares/textfile0.txt" should exist + When the administrator deletes group "grp1" using the provisioning API + And user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares" + Then the OCS status code should be "" + And the HTTP status code should be "200" + And file "/textfile0.txt" should not be included as path in the response + And as "Brian" file "/Shares/textfile0.txt" should not exist + And as "Carol" file "/Shares/textfile0.txt" should not exist + @skipOnOcis + Examples: + | ocs_api_version | ocs_status_code | path | + | 1 | 100 | /Shares/textfile0.txt | + | 2 | 200 | /Shares/textfile0.txt | + @skipOnOcV10 @issue-ocis-2441 + Examples: + | ocs_api_version | ocs_status_code | path | + | 1 | 100 | /textfile0.txt | + | 2 | 200 | /textfile0.txt | + + @skipOnFilesClassifier @issue-files-classifier-291 @issue-ocis-2146 + Scenario: Share a file by multiple channels and download from sub-folder and direct file share + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/common" + And user "Alice" has created folder "/common/sub" + And user "Alice" has shared folder "common" with group "grp1" + And user "Brian" has accepted share "/common" offered by user "Alice" + And user "Carol" has accepted share "/common" offered by user "Alice" + And user "Brian" has uploaded file with content "ownCloud" to "/textfile0.txt" + And user "Brian" has shared file "textfile0.txt" with user "Carol" + And user "Carol" has accepted share "/textfile0.txt" offered by user "Brian" + And user "Brian" has moved file "/textfile0.txt" to "/Shares/common/textfile0.txt" + And user "Brian" has moved file "/Shares/common/textfile0.txt" to "/Shares/common/sub/textfile0.txt" + When user "Carol" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/Shares/common/sub/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line + And the content of file "/Shares/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line + And user "Carol" should see the following elements + | /Shares/common/sub/textfile0.txt | + | /Shares/textfile0.txt | + And the content of file "/Shares/common/sub/textfile0.txt" for user "Brian" should be "BLABLABLA" plus end-of-line + And the content of file "/common/sub/textfile0.txt" for user "Alice" should be "BLABLABLA" plus end-of-line + + @issue-enterprise-3896 @issue-ocis-2201 + Scenario Outline: sharing back to resharer is allowed + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "userZeroFolder" + And user "Alice" has shared folder "userZeroFolder" with user "Brian" + And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice" + And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder" + And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share" + And user "Carol" has accepted share "" offered by user "Brian" + When user "Carol" shares folder "/Shares/userOneFolder" with user "Brian" using the sharing API + Then the HTTP status code should be "200" +# Then the HTTP status code should be "405" + And the sharing API should report to user "Brian" that no shares are in the pending state + And as "Brian" folder "/Shares/userOneFolder" should not exist + Examples: + | pending_share_path | + | /userOneFolder | + + @issue-enterprise-3896 @issue-ocis-2201 + Scenario Outline: sharing back to original sharer is allowed + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "userZeroFolder" + And user "Alice" has shared folder "userZeroFolder" with user "Brian" + And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice" + And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder" + And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share" + And user "Carol" has accepted share "" offered by user "Brian" + When user "Carol" shares folder "/Shares/userOneFolder" with user "Alice" using the sharing API + Then the HTTP status code should be "200" +# Then the HTTP status code should be "405" + And the sharing API should report to user "Alice" that no shares are in the pending state + And as "Alice" folder "/Shares/userOneFolder" should not exist + Examples: + | pending_share_path | + | /userOneFolder | + + @issue-enterprise-3896 @issue-ocis-2201 + Scenario Outline: sharing a subfolder to a user that already received parent folder share + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + | David | + And user "Alice" has created folder "userZeroFolder" + And user "Alice" has shared folder "userZeroFolder" with user "Brian" + And user "Alice" has shared folder "userZeroFolder" with user "Carol" + And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice" + And user "Carol" has accepted share "/userZeroFolder" offered by user "Alice" + And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder" + And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "David" with permissions "read, share" + And user "David" has accepted share "" offered by user "Brian" + When user "David" shares folder "/Shares/userOneFolder" with user "Carol" using the sharing API + Then the HTTP status code should be "200" +# Then the HTTP status code should be "405" + And the sharing API should report to user "Carol" that no shares are in the pending state + And as "Carol" folder "/Shares/userOneFolder" should not exist + Examples: + | pending_share_path | + | /userOneFolder | + + @smokeTest + Scenario Outline: Creating a share of a renamed file + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has moved file "/textfile0.txt" to "/renamed.txt" + When user "Alice" shares file "renamed.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/renamed.txt | + | path | /renamed.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + When user "Brian" accepts share "/renamed.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "/Shares/renamed.txt" for user "Brian" should be "ownCloud test text file 0" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-903 + Scenario Outline: shares to a deleted user should not be listed as shares for the sharer + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has shared file "textfile0.txt" with user "Carol" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Carol" has accepted share "/textfile0.txt" offered by user "Alice" + And the administrator has deleted user "Brian" using the provisioning API + When user "Alice" gets all the shares from the file "textfile0.txt" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be included in the response + But user "Brian" should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-719 + Scenario Outline: Creating a share of a renamed file when another share exists + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/Folder1" + And user "Alice" has created folder "/Folder2" + And user "Alice" has shared folder "/Folder1" with user "Brian" + And user "Brian" has accepted share "/Folder1" offered by user "Alice" + And user "Alice" has moved file "/Folder2" to "/renamedFolder2" + When user "Alice" shares folder "/renamedFolder2" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/renamedFolder2 | + | path | /renamedFolder2 | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | user | + When user "Brian" accepts share "/renamedFolder2" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" folder "/Shares/renamedFolder2" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-1710 + Scenario Outline: Sharing a same file twice to the same group is not possible + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API + Then the HTTP status code should be "" + And the OCS status code should be "403" + And the OCS status message should be "Path already shared with this group" + Examples: + | ocs-api-version | http-status | + | 1 | 200 | + | 2 | 403 | + + @issue-ocis-2215 + Scenario Outline: Sharing the shares folder to users is not possible + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" shares folder "Shares" with user "Carol" using the sharing API + Then the HTTP status code should be "" + And the OCS status code should be "403" + And the OCS status message should be "Path contains files shared with you" + Examples: + | ocs-api-version | http-status | + | 1 | 200 | + | 2 | 403 | + + @issue-ocis-2215 + Scenario Outline: Sharing the shares folder to groups is not possible + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "share_group" has been created + And user "Carol" has been added to group "share_group" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" shares folder "Shares" with group "share_group" using the sharing API + Then the HTTP status code should be "" + And the OCS status code should be "403" + And the OCS status message should be "Path contains files shared with you" + Examples: + | ocs-api-version | http-status | + | 1 | 200 | + | 2 | 403 | + + @issue-ocis-2215 + Scenario Outline: Sharing the shares folder as public link is not possible + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a public link share of folder "Shares" using the sharing API + Then the HTTP status code should be "" + And the OCS status code should be "403" + And the OCS status message should be "Path contains files shared with you" + Examples: + | ocs-api-version | http-status | + | 1 | 200 | + | 2 | 403 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature new file mode 100644 index 00000000000..7497376181d --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature @@ -0,0 +1,227 @@ +@api @files_sharing-app-required @issue-ocis-1328 @issue-ocis-1289 +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + + + Scenario Outline: Delete all group shares + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Brian" has moved file "/Shares/textfile0.txt" to "/Shares/anotherName.txt" + When user "Alice" deletes the last share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should not see the share id of the last share + And as "Brian" file "/Shares/textfile0.txt" should not exist + And as "Brian" file "/Shares/anotherName.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: delete a share + Given using OCS API version "" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Alice" deletes the last share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share id should not be included in the response + And as "Brian" file "/Shares/textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: orphaned shares + Given using OCS API version "1" + And user "Alice" has created folder "/common" + And user "Alice" has created folder "/common/sub" + And user "Alice" has shared folder "/common/sub" with user "Brian" + And user "Brian" has accepted share "" offered by user "Alice" + When user "Alice" deletes folder "/common" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" folder "/Shares/sub" should not exist + And as "Brian" folder "/sub" should not exist + Examples: + | pending_share_path | + | /sub | + + @smokeTest @files_trashbin-app-required + Scenario: deleting a file out of a share as recipient creates a backup for the owner + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + When user "Brian" deletes file "/Shares/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" file "/Shares/shared/shared_file.txt" should not exist + And as "Alice" file "/shared/shared_file.txt" should not exist + And as "Alice" file "/shared_file.txt" should exist in the trashbin + And as "Brian" file "/shared_file.txt" should exist in the trashbin + + @files_trashbin-app-required + Scenario: deleting a folder out of a share as recipient creates a backup for the owner + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/sub" + And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + When user "Brian" deletes folder "/Shares/shared/sub" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" folder "/Shares/shared/sub" should not exist + And as "Alice" folder "/shared/sub" should not exist + And as "Alice" folder "/sub" should exist in the trashbin + And as "Alice" file "/sub/shared_file.txt" should exist in the trashbin + And as "Brian" folder "/sub" should exist in the trashbin + And as "Brian" file "/sub/shared_file.txt" should exist in the trashbin + + @smokeTest + Scenario Outline: unshare from self + And group "grp1" has been created + And these users have been created with default attributes and without skeleton files: + | username | + | Carol | + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Carol" has created folder "PARENT" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Carol" has shared file "/PARENT/parent.txt" with group "grp1" + And user "Brian" has accepted share "" offered by user "Carol" + And user "Carol" has stored etag of element "/PARENT" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + When user "Brian" unshares file "/Shares/parent.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the etag of element "/" of user "Brian" should have changed + And the etag of element "/Shares" of user "Brian" should have changed + And the etag of element "/PARENT" of user "Carol" should not have changed + Examples: + | pending_share_path | + | /parent.txt | + + + Scenario: sharee of a read-only share folder tries to delete the shared folder + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "shared" with user "Brian" with permissions "read" + And user "Brian" has accepted share "/shared" offered by user "Alice" + When user "Brian" deletes file "/Shares/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/shared/shared_file.txt" should exist + And as "Brian" file "/Shares/shared/shared_file.txt" should exist + + + Scenario: sharee of a upload-only shared folder tries to delete a file in the shared folder + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "shared" with user "Brian" with permissions "create" + And user "Brian" has accepted share "/shared" offered by user "Alice" + When user "Brian" deletes file "/Shares/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/shared/shared_file.txt" should exist + # Note: for Brian, the file does not "exist" because he only has "create" permission, not "read" + And as "Brian" file "/Shares/shared/shared_file.txt" should not exist + + + Scenario: sharee of an upload-only shared folder tries to delete their file in the folder + Given using OCS API version "1" + And user "Alice" has created folder "/shared" + And user "Alice" has shared folder "shared" with user "Brian" with permissions "create" + And user "Brian" has accepted share "/shared" offered by user "Alice" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/Shares/shared/textfile.txt" + When user "Brian" deletes file "/Shares/shared/textfile.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/shared/textfile.txt" should exist + # Note: for Brian, the file does not "exist" because he only has "create" permission, not "read" + And as "Brian" file "/Shares/shared/textfile.txt" should not exist + + + Scenario Outline: A Group share recipient tries to delete the share + Given using OCS API version "" + And group "grp1" has been created + And these users have been created with default attributes and without skeleton files: + | username | + | Carol | + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared entry "" with group "grp1" + And user "Brian" has accepted share "" offered by user "Alice" + And user "Carol" has accepted share "" offered by user "Alice" + When user "Brian" deletes the last share of user "Alice" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Alice" entry "" should exist + And as "Brian" entry "" should exist + And as "Carol" entry "" should exist + Examples: + | entry_to_share | ocs_api_version | http_status_code | received_entry | pending_entry | + | /shared/shared_file.txt | 1 | 200 | /Shares/shared_file.txt | /Shares/shared_file.txt | + | /shared/shared_file.txt | 2 | 404 | /Shares/shared_file.txt | /Shares/shared_file.txt | + | /shared | 1 | 200 | /Shares/shared | /Shares/shared | + | /shared | 2 | 404 | /Shares/shared | /Shares/shared | + + + Scenario Outline: An individual share recipient tries to delete the share + Given using OCS API version "" + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared entry "" with user "Brian" + And user "Brian" has accepted share "" offered by user "Alice" + When user "Brian" deletes the last share of user "Alice" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Alice" entry "" should exist + And as "Brian" entry "" should exist + Examples: + | entry_to_share | ocs_api_version | http_status_code | received_entry | pending_entry | + | /shared/shared_file.txt | 1 | 200 | /Shares/shared_file.txt | /Shares/shared_file.txt | + | /shared/shared_file.txt | 2 | 404 | /Shares/shared_file.txt | /Shares/shared_file.txt | + | /shared | 1 | 200 | /Shares/shared | /Shares/shared | + | /shared | 2 | 404 | /Shares/shared | /Shares/shared | + + @issue-ocis-720 + Scenario Outline: request PROPFIND after sharer deletes the collaborator + Given using OCS API version "" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Alice" deletes the last share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Brian" requests "/remote.php/dav/files/%username%" with "PROPFIND" using basic auth + Then the HTTP status code should be "207" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-1229 + Scenario Outline: delete a share with wrong authentication + Given using OCS API version "" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" tries to delete the last share of user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 404 | 200 | + | 2 | 404 | 404 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/excludeGroupFromReceivingSharesToSharesFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/excludeGroupFromReceivingSharesToSharesFolder.feature new file mode 100644 index 00000000000..4cad03c72f5 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementBasicToShares/excludeGroupFromReceivingSharesToSharesFolder.feature @@ -0,0 +1,174 @@ +@api @files_sharing-app-required +Feature: Exclude groups from receiving shares + As an admin + I want to exclude groups from receiving shares + So that users do not mistakenly share with groups they should not e.g. huge meta groups + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + | David | + And group "grp1" has been created + And group "grp2" has been created + And user "Brian" has been added to group "grp1" + And user "David" has been added to group "grp2" + + @skipOnOcis + Scenario Outline: user cannot share with a group that is excluded from receiving shares but can share with other groups + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And the administrator has added group "grp1" to the exclude groups from receiving shares list + When user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And the sharing API should report to user "Brian" that no shares are in the pending state + When user "Alice" shares folder "PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And the sharing API should report to user "Brian" that no shares are in the pending state + When user "Alice" shares file "fileToShare.txt" with group "grp2" using the sharing API + And user "Alice" shares folder "PARENT" with group "grp2" using the sharing API + And user "David" accepts share "/fileToShare.txt" offered by user "Alice" using the sharing API + And user "David" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then as "David" file "/Shares/fileToShare.txt" should exist + And as "David" folder "/Shares/PARENT" should exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + @skipOnOcis + Scenario Outline: exclude multiple groups from receiving shares stops the user to share with any of them + Given using OCS API version "" + And group "grp3" has been created + And user "Brian" has been added to group "grp3" + And the administrator has added group "grp1, grp2, grp3" to the exclude group from sharing list + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And the administrator has added group "grp1" to the exclude groups from receiving shares list + And the administrator has added group "grp2" to the exclude groups from receiving shares list + And the administrator has added group "grp3" to the exclude groups from receiving shares list + When user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And the sharing API should report to user "Brian" that no shares are in the pending state + When user "Alice" shares folder "PARENT" with group "grp2" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And the sharing API should report to user "David" that no shares are in the pending state + When user "Alice" shares folder "PARENT/CHILD" with group "grp3" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And the sharing API should report to user "Brian" that no shares are in the pending state + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + @skipOnOcis + Scenario Outline: user cannot reshare a received share with a group that is excluded from receiving shares but can share with other groups + Given using OCS API version "" + And user "Carol" has created folder "PARENT" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Carol" has shared file "textfile0.txt" with user "Alice" + And user "Alice" has accepted share "/textfile0.txt" offered by user "Carol" + And user "Carol" has shared folder "PARENT" with user "Alice" + And user "Alice" has accepted share "/PARENT" offered by user "Carol" + And the administrator has added group "grp1" to the exclude groups from receiving shares list + When user "Alice" shares file "/Shares/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And the sharing API should report to user "Brian" that no shares are in the pending state + When user "Alice" shares folder "/Shares/PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And the OCS status message should be "The group is blacklisted for sharing" + And the sharing API should report to user "Brian" that no shares are in the pending state + When user "Alice" shares file "/Shares/textfile0.txt" with group "grp2" using the sharing API + And user "Alice" shares folder "/Shares/PARENT" with group "grp2" using the sharing API + And user "David" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + And user "David" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then as "David" file "/Shares/textfile0.txt" should exist + And as "David" folder "/Shares/PARENT" should exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: sharing with a user that is part of a group that is excluded from receiving shares still works + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And the administrator has added group "grp1" to the exclude groups from receiving shares list + When user "Alice" shares file "fileToShare.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Alice" shares folder "PARENT" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Brian" accepts share "/fileToShare.txt" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then as "Brian" file "/Shares/fileToShare.txt" should exist + And as "Brian" folder "/Shares/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: sharing with a user that is part of a group that is excluded from receiving shares using an other group works + Given using OCS API version "" + And group "grp3" has been created + And user "Brian" has been added to group "grp3" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And the administrator has added group "grp1" to the exclude groups from receiving shares list + When user "Alice" shares file "fileToShare.txt" with group "grp3" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Alice" shares folder "PARENT" with group "grp3" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Brian" accepts share "/fileToShare.txt" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then as "Brian" file "/Shares/fileToShare.txt" should exist + And as "Brian" folder "/Shares/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: a user that is part of a group that is excluded from receiving shares still can initiate shares + Given using OCS API version "" + And user "Brian" has created folder "PARENT" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And the administrator has added group "grp1" to the exclude groups from receiving shares list + When user "Brian" shares file "fileToShare.txt" with user "Carol" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" shares folder "PARENT" with user "Carol" using the sharing API + And the OCS status code should be "" + And the HTTP status code should be "200" + When user "Carol" accepts share "/fileToShare.txt" offered by user "Brian" using the sharing API + And user "Carol" accepts share "/PARENT" offered by user "Brian" using the sharing API + Then as "Carol" file "/Shares/fileToShare.txt" should exist + And as "Carol" folder "/Shares/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/acceptShares.feature b/tests/acceptance/features/coreApiShareManagementToRoot/acceptShares.feature new file mode 100644 index 00000000000..e8322eaf8ba --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToRoot/acceptShares.feature @@ -0,0 +1,960 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: accept/decline shares coming from internal users + As a user + I want to have control of which received shares I accept + So that I can keep my file system clean + + Background: + Given using OCS API version "1" + And using new DAV path + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "FOLDER" + And user "Brian" has created folder "PARENT" + And user "Brian" has created folder "FOLDER" + And user "Carol" has created folder "PARENT" + And user "Carol" has created folder "FOLDER" + And user "Alice" has uploaded file with content "ownCloud text file 0" to "/textfile0.txt" + And user "Brian" has uploaded file with content "ownCloud text file 0" to "/textfile0.txt" + And user "Carol" has uploaded file with content "ownCloud text file 0" to "/textfile0.txt" + And user "Alice" has uploaded file with content "ownCloud test text file parent" to "/PARENT/parent.txt" + And user "Brian" has uploaded file with content "ownCloud test text file parent" to "/PARENT/parent.txt" + And user "Carol" has uploaded file with content "ownCloud test text file parent" to "/PARENT/parent.txt" + + @smokeTest + Scenario Outline: share a file & folder with another internal user with different permissions when auto accept is enabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has created folder "PARENT/CHILD" + And user "Brian" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" + And user "Brian" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" + When user "Alice" creates a share using the sharing API with settings + | path | PARENT | + | shareType | user | + | shareWith | Brian | + | permissions | | + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /PARENT (2)/ | + | /textfile0 (2).txt | + And the content of file "/PARENT (2)/CHILD/child.txt" for user "Brian" should be "ownCloud test text file child" + And the content of file "/textfile0 (2).txt" for user "Brian" should be "ownCloud text file 0" + Examples: + | permissions | + | read | + | change | + | all | + + + Scenario Outline: share a file & folder with another internal user when auto accept is enabled and there is a default folder for received shares + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And the administrator has set the default folder for received shares to "" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | // | + | //parent.txt | + | /textfile0.txt | + | / | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | // | + | / | + Examples: + | share_folder | top_folder | received_parent_name | received_textfile_name | + | | | PARENT (2) | textfile0 (2).txt | + | / | | PARENT (2) | textfile0 (2).txt | + | /ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | + | ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | + | /My/Received/Shares | /My/Received/Shares | PARENT | textfile0.txt | + + + Scenario Outline: share a file & folder with internal group with different permissions when auto accept is enabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has created folder "PARENT/CHILD" + And user "Brian" has created folder "PARENT/CHILD" + And user "Carol" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" + And user "Brian" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" + And user "Carol" has uploaded file with content "ownCloud test text file child" to "/PARENT/CHILD/child.txt" + When user "Alice" creates a share using the sharing API with settings + | path | PARENT | + | shareType | group | + | shareWith | grp1 | + | permissions | | + And user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /PARENT (2)/ | + | /textfile0 (2).txt | + And user "Carol" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Carol" that these shares are in the accepted state + | path | + | /PARENT (2)/ | + | /textfile0 (2).txt | + And the content of file "/PARENT (2)/CHILD/child.txt" for user "Carol" should be "ownCloud test text file child" + And the content of file "/textfile0 (2).txt" for user "Carol" should be "ownCloud text file 0" + Examples: + | permissions | + | read | + | change | + | all | + + @smokeTest + Scenario Outline: decline a share that has been auto-accepted + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" declines share "/PARENT (2)" offered by user "Alice" using the sharing API + And user "Brian" declines share "/textfile0 (2).txt" offered by user "Alice" using the sharing API + 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 "100" + And user "Brian" should not see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | | + | | + Examples: + | declined_share_path_1 | declined_share_path_2 | + | /PARENT (2)/ | /textfile0 (2).txt | + + + Scenario Outline: accept a share that has been declined before + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Brian" has declined share "/PARENT (2)" offered by user "Alice" + And user "Brian" has declined share "/textfile0 (2).txt" offered by user "Alice" + When user "Brian" accepts share "" offered by user "Alice" using the sharing API + And user "Brian" accepts share "" offered by user "Alice" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /PARENT (2)/ | + | /textfile0 (2).txt | + Examples: + | pending_share_path_1 | pending_share_path_2 | + | /PARENT (2) | /textfile0 (2).txt | + + + Scenario Outline: unshare a share that has been auto-accepted + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" unshares folder "/PARENT (2)" using the WebDAV API + And user "Brian" unshares file "/textfile0 (2).txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And user "Brian" should not see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | | + | | + Examples: + | declined_share_path_1 | declined_share_path_2 | + | /PARENT (2)/ | /textfile0 (2).txt | + + + Scenario Outline: unshare a share that was shared with a group and auto-accepted + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has shared folder "/PARENT" with group "grp1" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" + When user "Brian" unshares folder "/PARENT (2)" using the WebDAV API + And user "Brian" unshares file "/textfile0 (2).txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And user "Brian" should not see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | | + | | + But user "Carol" should see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Carol" that these shares are in the accepted state + | path | + | /PARENT (2)/ | + | /textfile0 (2).txt | + Examples: + | declined_share_path_1 | declined_share_path_2 | + | /PARENT (2)/ | /textfile0 (2).txt | + + + Scenario Outline: rename accepted share, decline it + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has shared folder "/PARENT" with user "Brian" + When user "Brian" moves folder "/PARENT (2)" to "/PARENT-renamed" using the WebDAV API + And user "Brian" declines share "/PARENT-renamed" offered by user "Alice" using the sharing API + Then the HTTP status code of responses on each endpoint should be "201, 200" respectively + #OCS status code is checked only for Sharing API request + And the OCS status code should be "100" + And user "Brian" should not see the following elements + | /PARENT (2)/ | + | /PARENT-renamed/ | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | | + Examples: + | declined_share_path | + | /PARENT-renamed/ | + + + Scenario Outline: rename accepted share, decline it then accept again, name stays + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Brian" has moved folder "/PARENT (2)" to "/PARENT-renamed" + When user "Brian" declines share "/PARENT-renamed" offered by user "Alice" using the sharing API + And user "Brian" accepts share "" offered by user "Alice" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /PARENT/ | + | /PARENT-renamed/ | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /PARENT-renamed/ | + Examples: + | declined_share_path | + | /PARENT-renamed | + + + Scenario Outline: move accepted share, decline it, accept again + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has moved folder "/shared" to "/PARENT/shared" + When user "Brian" declines share "/PARENT/shared" offered by user "Alice" using the sharing API + And user "Brian" accepts share "" offered by user "Alice" using the sharing API + 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 "100" + And user "Brian" should not see the following elements + | /shared/ | + But user "Brian" should see the following elements + | /PARENT/shared/ | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /PARENT/shared/ | + Examples: + | declined_share_path | + | /PARENT/shared | + + + Scenario Outline: move accepted share, decline it, delete parent folder, accept again + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has moved folder "/shared" to "/PARENT/shared" + When user "Brian" declines share "/PARENT/shared" offered by user "Alice" using the sharing API + And user "Brian" deletes folder "/PARENT" using the WebDAV API + And user "Brian" accepts share "" offered by user "Alice" using the sharing API + Then the HTTP status code of responses on each endpoint should be "200, 204, 200" respectively + #OCS status code is checked only for Sharing API request + And the OCS status code of responses on all endpoints should be "100" + And user "Brian" should not see the following elements + | /PARENT/ | + But user "Brian" should see the following elements + | /shared/ | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /shared/ | + Examples: + | declined_share_path | + | /PARENT/shared | + + + Scenario: receive two shares with identical names from different users + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/Alice" + And user "Brian" has created folder "/shared" + And user "Brian" has created folder "/shared/Brian" + When user "Alice" shares folder "/shared" with user "Carol" using the sharing API + And user "Brian" shares folder "/shared" with user "Carol" using the sharing API + 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 "100" + And user "Carol" should see the following elements + | /shared/Alice/ | + | /shared (2)/Brian/ | + And the sharing API should report to user "Carol" that these shares are in the accepted state + | path | + | /shared/ | + | /shared (2)/ | + + @smokeTest + Scenario: share a file & folder with another internal group when auto accept is disabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + But user "Brian" should not see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the pending state + | path | + | /PARENT/ | + | /textfile0.txt | + And user "Carol" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + But user "Carol" should not see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Carol" that these shares are in the pending state + | path | + | /PARENT/ | + | /textfile0.txt | + + + Scenario: share a file & folder with another internal user when auto accept is disabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + But user "Brian" should not see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the pending state + | path | + | /PARENT/ | + | /textfile0.txt | + + @smokeTest + Scenario: accept a pending share + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + 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 "100" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | share_type | user | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | share,read,update | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | state | 0 | + | path | /textfile0 (2).txt | + | item_type | file | + | mimetype | text/plain | + | storage_id | shared::/textfile0 (2).txt | + | storage | A_STRING | + | item_source | A_STRING | + | file_source | A_STRING | + | file_target | /textfile0 (2).txt | + | share_with | %username% | + | share_with_displayname | %displayname% | + | mail_send | 0 | + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /PARENT (2)/ | + | /textfile0 (2).txt | + + + Scenario Outline: accept a pending share when there is a default folder for received shares + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And the administrator has set the default folder for received shares to "" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + 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 "100" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | share_type | user | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | share,read,update | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | state | 0 | + | path | / | + | item_type | file | + | mimetype | text/plain | + | storage_id | shared::/ | + | storage | A_STRING | + | item_source | A_STRING | + | file_source | A_STRING | + | file_target | / | + | share_with | %username% | + | share_with_displayname | %displayname% | + | mail_send | 0 | + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | // | + | //parent.txt | + | /textfile0.txt | + | / | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | // | + | / | + Examples: + | share_folder | top_folder | received_parent_name | received_textfile_name | + | | | PARENT (2) | textfile0 (2).txt | + | / | | PARENT (2) | textfile0 (2).txt | + | /ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | + | ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | + | /My/Received/Shares | /My/Received/Shares | PARENT | textfile0.txt | + + + Scenario: accept an accepted share + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + When user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /shared/ | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /shared/ | + + @smokeTest + Scenario: declines a pending share + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" declines share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" declines share "/textfile0.txt" offered by user "Alice" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + But user "Brian" should not see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | /PARENT/ | + | /textfile0.txt | + + @smokeTest + Scenario Outline: decline an accepted share + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" declines share "/PARENT (2)" offered by user "Alice" using the sharing API + And user "Brian" declines share "/textfile0 (2).txt" offered by user "Alice" using the sharing API + 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 "100" + And user "Brian" should not see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | | + | | + Examples: + | declined_share_path_1 | declined_share_path_2 | + | /PARENT (2)/ | /textfile0 (2).txt | + + + Scenario: deleting shares in pending state + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Alice" deletes folder "/PARENT" using the WebDAV API + And user "Alice" deletes file "/textfile0.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And the sharing API should report that no shares are shared with user "Brian" + + + Scenario: only one user in a group accepts a share + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has shared folder "/PARENT" with group "grp1" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" + When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + 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 "100" + And user "Carol" should not see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Carol" that these shares are in the pending state + | path | + | /PARENT/ | + | /textfile0.txt | + But user "Brian" should see the following elements + | /PARENT (2)/ | + | /PARENT (2)/parent.txt | + | /textfile0 (2).txt | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /PARENT (2)/ | + | /textfile0 (2).txt | + + + Scenario: receive two shares with identical names from different users, accept one by one + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/Alice" + And user "Brian" has created folder "/shared" + And user "Brian" has created folder "/shared/Brian" + And user "Alice" has shared folder "/shared" with user "Carol" + And user "Brian" has shared folder "/shared" with user "Carol" + When user "Carol" accepts share "/shared" offered by user "Brian" using the sharing API + And user "Carol" accepts share "/shared" offered by user "Alice" using the sharing API + 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 "100" + And user "Carol" should see the following elements + | /shared/Brian/ | + | /shared (2)/Alice/ | + And the sharing API should report to user "Carol" that these shares are in the accepted state + | path | + | /shared/ | + | /shared (2)/ | + + + Scenario: share with a group that you are part of yourself + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the sharing API should report to user "Brian" that these shares are in the pending state + | path | + | /PARENT/ | + And the sharing API should report that no shares are shared with user "Alice" + + + Scenario Outline: user accepts file that was initially accepted from another user and then declined + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has uploaded file with content "First file" to "/testfile.txt" + And user "Brian" has uploaded file with content "Second file" to "/testfile.txt" + And user "Carol" has uploaded file with content "Third file" to "/testfile.txt" + And user "Alice" has shared file "/testfile.txt" with user "Carol" + And user "Carol" has accepted share "/testfile.txt" offered by user "Alice" + When user "Carol" declines share "/testfile (2).txt" offered by user "Alice" using the sharing API + And user "Brian" shares file "/testfile.txt" with user "Carol" using the sharing API + And user "Carol" accepts share "/testfile.txt" offered by user "Brian" using the sharing API + And user "Carol" accepts share "" offered by user "Alice" using the sharing API + 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 "100" + And the sharing API should report to user "Carol" that these shares are in the accepted state + | path | + | /testfile (2).txt | + | /testfile (2) (2).txt | + And the content of file "/testfile.txt" for user "Carol" should be "Third file" + And the content of file "/testfile (2).txt" for user "Carol" should be "Second file" + And the content of file "/testfile (2) (2).txt" for user "Carol" should be "First file" + Examples: + | accepted_share_path | + | /testfile (2).txt | + + + Scenario Outline: user accepts shares received from multiple users with the same name when auto-accept share is disabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "David" has been created with default attributes and without skeleton files + And user "David" has created folder "/PARENT" + And user "Brian" has shared folder "/PARENT" with user "Alice" + And user "Carol" has shared folder "/PARENT" with user "Alice" + When user "Alice" accepts share "/PARENT" offered by user "Brian" using the sharing API + And user "Alice" declines share "/PARENT (2)" offered by user "Brian" using the sharing API + And user "Alice" accepts share "/PARENT" offered by user "Carol" using the sharing API + And user "Alice" accepts share "" offered by user "Brian" using the sharing API + And user "Alice" declines share "/PARENT (2)" offered by user "Carol" using the sharing API + And user "Alice" declines share "/PARENT (2) (2)" offered by user "Brian" using the sharing API + And user "David" shares folder "/PARENT" with user "Alice" using the sharing API + And user "Alice" accepts share "/PARENT" offered by user "David" using the sharing API + And user "Alice" accepts share "" offered by user "Carol" using the sharing API + And user "Alice" accepts share "" offered by user "Brian" using the sharing API + 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 "100" + And the sharing API should report to user "Alice" that these shares are in the accepted state + | path | uid_owner | + | /PARENT (2)/ | David | + | /PARENT (2) (2)/ | Carol | + | /PARENT (2) (2) (2)/ | Brian | + Examples: + | accepted_share_path_1 | accepted_share_path_2 | + | /PARENT (2) | /PARENT (2) (2) | + + + Scenario: user shares folder with matching folder-name for both user involved in sharing + Given user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" + And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /PARENT (2)/ | + | /PARENT (2)/abc.txt | + | /FOLDER (2)/ | + | /FOLDER (2)/abc.txt | + And user "Brian" should not see the following elements + | /FOLDER/abc.txt | + | /PARENT/abc.txt | + And the content of file "/PARENT (2)/abc.txt" for user "Brian" should be "uploaded content" + And the content of file "/FOLDER (2)/abc.txt" for user "Brian" should be "uploaded content" + + + Scenario: user shares folder in a group with matching folder-name for every users involved + Given user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" + And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /PARENT (2)/ | + | /FOLDER (2)/ | + | /PARENT (2)/abc.txt | + | /FOLDER (2)/abc.txt | + And user "Brian" should not see the following elements + | /FOLDER/abc.txt | + | /PARENT/abc.txt | + And user "Carol" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /PARENT (2)/ | + | /FOLDER (2)/ | + | /PARENT (2)/abc.txt | + | /FOLDER (2)/abc.txt | + And user "Carol" should not see the following elements + | /FOLDER/abc.txt | + | /PARENT/abc.txt | + And the content of file "/PARENT (2)/abc.txt" for user "Brian" should be "uploaded content" + And the content of file "/FOLDER (2)/abc.txt" for user "Brian" should be "uploaded content" + And the content of file "/PARENT (2)/abc.txt" for user "Carol" should be "uploaded content" + And the content of file "/FOLDER (2)/abc.txt" for user "Carol" should be "uploaded content" + + + Scenario: user shares files in a group with matching file-names for every users involved in sharing + Given user "Alice" has uploaded file with content "ownCloud text file 1" to "/textfile1.txt" + And user "Brian" has uploaded file with content "ownCloud text file 1" to "/textfile1.txt" + And user "Carol" has uploaded file with content "ownCloud text file 1" to "/textfile1.txt" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + And user "Alice" shares file "/textfile1.txt" with group "grp1" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /textfile0.txt | + | /textfile1.txt | + | /textfile0 (2).txt | + | /textfile1 (2).txt | + And user "Carol" should see the following elements + | /textfile0.txt | + | /textfile1.txt | + | /textfile0 (2).txt | + | /textfile1 (2).txt | + + + Scenario: user shares resource with matching resource-name with another user when auto accept is disabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /PARENT/ | + | /textfile0.txt | + But user "Brian" should not see the following elements + | /textfile0 (2).txt | + | /PARENT (2)/ | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /PARENT/ | + | /textfile0.txt | + | /PARENT (2)/ | + | /textfile0 (2).txt | + + + Scenario: user shares file in a group with matching filename when auto accept is disabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /textfile0.txt | + But user "Brian" should not see the following elements + | /textfile0 (2).txt | + And user "Carol" should see the following elements + | /textfile0.txt | + But user "Carol" should not see the following elements + | /textfile0 (2).txt | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + And user "Carol" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + 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 "100" + And user "Brian" should see the following elements + | /textfile0.txt | + | /textfile0 (2).txt | + And user "Carol" should see the following elements + | /textfile0.txt | + | /textfile0 (2).txt | + + @skipOnLDAP + Scenario: user shares folder with matching folder name a user before that user has logged in + Given these users have been created with small skeleton files but not initialized: + | username | + | David | + And user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" + When user "Alice" shares folder "/PARENT" with user "David" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "David" should see the following elements + | /PARENT/ | + | /PARENT/abc.txt | + | /FOLDER/ | + | /textfile0.txt | + | /textfile1.txt | + | /textfile2.txt | + | /textfile3.txt | + And user "David" should not see the following elements + | /PARENT (2)/ | + And the content of file "/PARENT/abc.txt" for user "David" should be "uploaded content" + + @issue-ocis-765 + Scenario: shares exist after restoring already shared file to a previous version + Given user "Alice" has uploaded file with content "Test Content." to "/toShareFile.txt" + And user "Alice" has uploaded file with content "Content Test Updated." to "/toShareFile.txt" + And user "Alice" has shared file "/toShareFile.txt" with user "Brian" + When user "Alice" restores version index "1" of file "/toShareFile.txt" using the WebDAV API + And the HTTP status code should be "204" + And the content of file "/toShareFile.txt" for user "Alice" should be "Test Content." + And the content of file "/toShareFile.txt" for user "Brian" should be "Test Content." + + + Scenario: a user receives multiple group shares for matching file and folder name + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And group "grp2" has been created + And user "Alice" has been added to group "grp2" + And user "Brian" has been added to group "grp2" + And user "Alice" has created folder "/PaRent" + And user "Alice" has uploaded the following files with content "subfile, from alice to grp2" + | path | + | /PARENT/parent.txt | + | /PaRent/parent.txt | + And user "Alice" has uploaded the following files with content "from alice to grp2" + | path | + | /PARENT.txt | + And user "Carol" has uploaded the following files with content "subfile, from carol to grp1" + | path | + | /PARENT/parent.txt | + And user "Carol" has uploaded the following files with content "from carol to grp1" + | path | + | /PARENT.txt | + | /parent.txt | + When user "Alice" shares the following entries with group "grp2" using the sharing API + | path | + | /PARENT | + | /PaRent | + | /PARENT.txt | + And user "Carol" shares the following entries with group "grp2" using the sharing API + | path | + | /PARENT | + | /PARENT.txt | + | /parent.txt | + And user "Brian" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /PARENT | + | /PaRent | + | /PARENT.txt | + And user "Brian" accepts the following shares offered by user "Carol" using the sharing API + | path | + | /PARENT | + | /PARENT.txt | + | /parent.txt | + 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 "100" + And user "Brian" should see the following elements + | /PARENT/ | + | /PARENT (2)/ | + | /PARENT (3)/ | + | /PaRent/ | + | /PARENT.txt | + | /PARENT (2).txt | + | /parent.txt | + And the content of file "/PARENT (2)/parent.txt" for user "Brian" should be "subfile, from alice to grp2" + And the content of file "/PARENT (3)/parent.txt" for user "Brian" should be "subfile, from carol to grp1" + And the content of file "/PARENT.txt" for user "Brian" should be "from alice to grp2" + And the content of file "/PARENT (2).txt" for user "Brian" should be "from carol to grp1" + And the content of file "/parent.txt" for user "Brian" should be "from carol to grp1" + + + Scenario: a group receives multiple shares from non-member for matching file and folder name + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Brian" has been removed from group "grp1" + And user "Alice" has created folder "/PaRent" + And user "Alice" has uploaded the following files with content "subfile, from alice to grp1" + | path | + | /PARENT/parent.txt | + | /PaRent/parent.txt | + And user "Alice" has uploaded the following files with content "from alice to grp1" + | path | + | /PARENT.txt | + And user "Brian" has uploaded the following files with content "subfile, from brian to grp1" + | path | + | /PARENT/parent.txt | + And user "Brian" has uploaded the following files with content "from brian to grp1" + | path | + | /PARENT.txt | + | /parent.txt | + When user "Alice" shares the following entries with group "grp1" using the sharing API + | path | + | /PARENT | + | /PaRent | + | /PARENT.txt | + And user "Brian" shares the following entries with group "grp1" using the sharing API + | path | + | /PARENT | + | /PARENT.txt | + | /parent.txt | + And user "Carol" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /PARENT | + | /PaRent | + | /PARENT.txt | + And user "Carol" accepts the following shares offered by user "Brian" using the sharing API + | path | + | /PARENT | + | /PARENT.txt | + | /parent.txt | + 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 "100" + And user "Carol" should see the following elements + | /PARENT/ | + | /PARENT (2)/ | + | /PARENT (3)/ | + | /PaRent/ | + | /PARENT.txt | + | /PARENT (2).txt | + | /parent.txt | + And the content of file "/PARENT (2)/parent.txt" for user "Carol" should be "subfile, from alice to grp1" + And the content of file "/PARENT (3)/parent.txt" for user "Carol" should be "subfile, from brian to grp1" + And the content of file "/PARENT.txt" for user "Carol" should be "from alice to grp1" + And the content of file "/PARENT (2).txt" for user "Carol" should be "from brian to grp1" + + + Scenario: user receives a share and uploads a file with the identical name + Given user "Alice" has uploaded file with content "from alice" to "/message.txt" + And user "Alice" has shared file "/message.txt" with user "Carol" + And user "Carol" has accepted share "/message.txt" offered by user "Alice" + When user "Carol" declines share "/message.txt" offered by user "Alice" using the sharing API + And user "Carol" uploads file with content "carol file" to "/message.txt" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "200, 201" respectively + And the OCS status code of responses on all endpoints should be "100" + And user "Carol" should see the following elements + | /message.txt | + And the content of file "/message.txt" for user "Carol" should be "carol file" + When user "Carol" accepts share "/message.txt" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And user "Carol" should see the following elements + | /message.txt | + | /message (2).txt | + And the content of file "/message (2).txt" for user "Carol" should be "from alice" + + + Scenario: user receives a share and creates a folder with the identical name + Given user "Alice" has created folder "/PaRent" + And user "Alice" has uploaded file with content "from alice" to "/PaRent/message.txt" + And user "Alice" has shared folder "/PaRent" with user "Carol" + And user "Carol" has accepted share "/PaRent" offered by user "Alice" + When user "Carol" declines share "/PaRent" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + When user "Carol" creates folder "/PaRent" using the WebDAV API + And user "Carol" uploads file with content "carol file" to "/PaRent/message.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And user "Carol" should see the following elements + | /PaRent/ | + And the content of file "/PaRent/message.txt" for user "Carol" should be "carol file" + When user "Carol" accepts share "/PaRent" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And user "Carol" should see the following elements + | /PaRent/ | + | /PaRent (2)/ | + And the content of file "/PaRent (2)/message.txt" for user "Carol" should be "from alice" diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/disableSharing.feature b/tests/acceptance/features/coreApiShareManagementToRoot/disableSharing.feature new file mode 100644 index 00000000000..f851abb62d2 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToRoot/disableSharing.feature @@ -0,0 +1,175 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + As an admin + I want to be able to disable sharing functionality + So that ownCloud users cannot share file or folder + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario Outline: user tries to share a file with another user when the sharing api has been disabled + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When parameter "shareapi_enabled" of app "core" has been set to "no" + Then user "Alice" should not be able to share file "fileToShare.txt" with user "Brian" using the sharing API + And the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: user tries to share a folder with another user when the sharing api has been disabled + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + When parameter "shareapi_enabled" of app "core" has been set to "no" + Then user "Alice" should not be able to share folder "/FOLDER" with user "Brian" using the sharing API + And the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: user tries to share a file with group when the sharing api has been disabled + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When parameter "shareapi_enabled" of app "core" has been set to "no" + Then user "Alice" should not be able to share file "fileToShare.txt" with group "grp1" using the sharing API + And the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: user tries to share a folder with group when the sharing api has been disabled + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When parameter "shareapi_enabled" of app "core" has been set to "no" + Then user "Alice" should not be able to share folder "/FOLDER" with group "grp1" using the sharing API + And the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: user tries to create public link share of a file when the sharing api has been disabled + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When parameter "shareapi_enabled" of app "core" has been set to "no" + Then user "Alice" should not be able to create a public link share of file "fileToShare.txt" using the sharing API + And the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @smokeTest + Scenario Outline: user tries to create public link share of a folder when the sharing api has been disabled + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + When parameter "shareapi_enabled" of app "core" has been set to "no" + Then user "Alice" should not be able to create a public link share of folder "/FOLDER" using the sharing API + And the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @smokeTest + Scenario Outline: user tries to share a file with user who is not in their group when sharing outside the group has been restricted + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" + Then user "Brian" should not be able to share file "fileToShare.txt" with user "Alice" using the sharing API + And the OCS status code should be "403" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + + Scenario Outline: user shares a file with user who is in their group when sharing outside the group has been restricted + Given using OCS API version "" + And group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" + Then user "Carol" should be able to share file "fileToShare.txt" with user "Brian" using the sharing API + And the OCS status code should be "" + And the HTTP status code should be "200" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user shares a file with the group they are not member of when sharing outside the group has been restricted + Given using OCS API version "" + And group "grp2" has been created + And group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp2" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" + Then user "Carol" should be able to share file "fileToShare.txt" with group "grp1" using the sharing API + And the OCS status code should be "" + And the HTTP status code should be "200" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: user who is not a member of a group tries to share a file in the group when group sharing has been disabled + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + Then user "Alice" should not be able to share file "fileToShare.txt" with group "grp1" using the sharing API + And the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: user who is a member of a group tries to share a file in the group when group sharing has been disabled + Given using OCS API version "" + And group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + When parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + Then user "Carol" should not be able to share file "fileToShare.txt" with group "grp1" using the sharing API + And the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/mergeShare.feature b/tests/acceptance/features/coreApiShareManagementToRoot/mergeShare.feature new file mode 100644 index 00000000000..466572d8ba2 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToRoot/mergeShare.feature @@ -0,0 +1,126 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + + @smokeTest + Scenario: Merging shares for recipient when shared from outside with group and member + Given user "Alice" has created folder "/merge-test-outside" + When user "Alice" shares folder "/merge-test-outside" with group "grp1" using the sharing API + And user "Alice" shares folder "/merge-test-outside" with user "Brian" using the sharing API + 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 "100" + And as "Brian" folder "/merge-test-outside" should exist + And as "Brian" folder "/merge-test-outside (2)" should not exist + + + Scenario: Merging shares for recipient when shared from outside with group and member with different permissions + Given user "Alice" has created folder "/merge-test-outside-perms" + When user "Alice" shares folder "/merge-test-outside-perms" with group "grp1" with permissions "read" using the sharing API + And user "Alice" shares folder "/merge-test-outside-perms" with user "Brian" with permissions "all" using the sharing API + 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 "100" + And as user "Brian" folder "/merge-test-outside-perms" should contain a property "oc:permissions" with value "SRDNVCK" + And as "Brian" folder "/merge-test-outside-perms (2)" should not exist + + + Scenario: Merging shares for recipient when shared from outside with two groups + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Alice" has created folder "/merge-test-outside-twogroups" + When user "Alice" shares folder "/merge-test-outside-twogroups" with group "grp1" using the sharing API + And user "Alice" shares folder "/merge-test-outside-twogroups" with group "grp2" using the sharing API + 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 "100" + And as "Brian" folder "/merge-test-outside-twogroups" should exist + And as "Brian" folder "/merge-test-outside-twogroups (2)" should not exist + + + Scenario: Merging shares for recipient when shared from outside with two groups with different permissions + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Alice" has created folder "/merge-test-outside-twogroups-perms" + When user "Alice" shares folder "/merge-test-outside-twogroups-perms" with group "grp1" with permissions "read" using the sharing API + And user "Alice" shares folder "/merge-test-outside-twogroups-perms" with group "grp2" with permissions "all" using the sharing API + 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 "100" + And as user "Brian" folder "/merge-test-outside-twogroups-perms" should contain a property "oc:permissions" with value "SRDNVCK" + And as "Brian" folder "/merge-test-outside-twogroups-perms (2)" should not exist + + + Scenario: Merging shares for recipient when shared from outside with two groups and member + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Alice" has created folder "/merge-test-outside-twogroups-member-perms" + When user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with group "grp1" with permissions "read" using the sharing API + And user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with group "grp2" with permissions "all" using the sharing API + And user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with user "Brian" with permissions "read" using the sharing API + 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 "100" + And as user "Brian" folder "/merge-test-outside-twogroups-member-perms" should contain a property "oc:permissions" with value "SRDNVCK" + And as "Brian" folder "/merge-test-outside-twogroups-member-perms (2)" should not exist + + + Scenario: Merging shares for recipient when shared from inside with group + Given user "Brian" has created folder "/merge-test-inside-group" + When user "Brian" shares folder "/merge-test-inside-group" with group "grp1" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And as "Brian" folder "/merge-test-inside-group" should exist + And as "Brian" folder "/merge-test-inside-group (2)" should not exist + + + Scenario: Merging shares for recipient when shared from inside with two groups + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Brian" has created folder "/merge-test-inside-twogroups" + When user "Brian" shares folder "/merge-test-inside-twogroups" with group "grp1" using the sharing API + And user "Brian" shares folder "/merge-test-inside-twogroups" with group "grp2" using the sharing API + 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 "100" + And as "Brian" folder "/merge-test-inside-twogroups" should exist + And as "Brian" folder "/merge-test-inside-twogroups (2)" should not exist + And as "Brian" folder "/merge-test-inside-twogroups (3)" should not exist + + + Scenario: Merging shares for recipient when shared from inside with group with less permissions + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Brian" has created folder "/merge-test-inside-twogroups-perms" + When user "Brian" shares folder "/merge-test-inside-twogroups-perms" with group "grp1" using the sharing API + And user "Brian" shares folder "/merge-test-inside-twogroups-perms" with group "grp2" using the sharing API + 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 "100" + And as user "Brian" folder "/merge-test-inside-twogroups-perms" should contain a property "oc:permissions" with value "RDNVCK" or with value "RMDNVCK" + And as "Brian" folder "/merge-test-inside-twogroups-perms (2)" should not exist + And as "Brian" folder "/merge-test-inside-twogroups-perms (3)" should not exist + + + Scenario: Merging shares for recipient when shared from outside with group then user and recipient renames in between + Given user "Alice" has created folder "/merge-test-outside-groups-renamebeforesecondshare" + When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with group "grp1" using the sharing API + And user "Brian" moves folder "/merge-test-outside-groups-renamebeforesecondshare" to "/merge-test-outside-groups-renamebeforesecondshare-renamed" using the WebDAV API + And user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with user "Brian" using the sharing API + Then the HTTP status code of responses on each endpoint should be "200, 201, 200" respectively + #OCS status code is checked only for Sharing API request + And the OCS status code of responses on all endpoints should be "100" + And as user "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should contain a property "oc:permissions" with value "SRDNVCK" + And as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare" should not exist + + + Scenario: Merging shares for recipient when shared from outside with user then group and recipient renames in between + Given user "Alice" has created folder "/merge-test-outside-groups-renamebeforesecondshare" + When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with user "Brian" using the sharing API + And user "Brian" moves folder "/merge-test-outside-groups-renamebeforesecondshare" to "/merge-test-outside-groups-renamebeforesecondshare-renamed" using the WebDAV API + And user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with group "grp1" using the sharing API + Then the HTTP status code of responses on each endpoint should be "200, 201, 200" respectively + And the OCS status code of responses on all endpoints should be "100" + And as user "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should contain a property "oc:permissions" with value "SRDNVCK" + And as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare" should not exist diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShare.feature b/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShare.feature new file mode 100644 index 00000000000..444d14c8f16 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShare.feature @@ -0,0 +1,103 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + + + Scenario: Keep usergroup shares (#22143) + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/TMP" + When user "Alice" shares folder "TMP" with group "grp1" using the sharing API + And user "Brian" creates folder "/myFOLDER" using the WebDAV API + And user "Brian" moves folder "/TMP" to "/myFOLDER/myTMP" using the WebDAV API + And the administrator deletes user "Carol" using the provisioning API + 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 "100" + And user "Brian" should see the following elements + | /myFOLDER/myTMP/ | + + + Scenario: keep user shared file name same after one of recipient has renamed the file + Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" + And user "Alice" has shared file "/sharefile.txt" with user "Brian" + And user "Alice" has shared file "/sharefile.txt" with user "Carol" + When user "Carol" moves file "/sharefile.txt" to "/renamedsharefile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Carol" file "/renamedsharefile.txt" should exist + And as "Alice" file "/sharefile.txt" should exist + And as "Brian" file "/sharefile.txt" should exist + + + Scenario: keep user shared file directory same in respect to respective user if one of the recipient has moved the file + Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" + And user "Alice" has shared file "/sharefile.txt" with user "Brian" + And user "Alice" has shared file "/sharefile.txt" with user "Carol" + And user "Carol" has created folder "newfolder" + When user "Carol" moves file "/sharefile.txt" to "/newfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Carol" file "/newfolder/sharefile.txt" should exist + And as "Alice" file "/sharefile.txt" should exist + And as "Brian" file "/sharefile.txt" should exist + + + Scenario Outline: move folder inside received folder with special characters + Given group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "" + And user "Alice" has created folder "" + And user "Brian" has created folder "" + And user "Carol" has created folder "" + When user "Alice" shares folder "" with user "Brian" using the sharing API + And user "Brian" moves folder "" to "/" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "200, 201" respectively + #OCS status code is checked only for Sharing API request + And the OCS status code of responses on all endpoints should be "100" + And as "Alice" folder "/" should exist + And as "Brian" folder "/" should exist + When user "Alice" shares folder "" with group "grp1" using the sharing API + And user "Carol" moves folder "" to "/" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "200, 201" respectively + And the OCS status code of responses on all endpoints should be "100" + And as "Alice" folder "/" should exist + And as "Carol" folder "/" should exist + Examples: + | sharer_folder | group_folder | receiver_folder | + | ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | + | @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | + + + Scenario: receiver renames a received share with share, read, change 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,change" + 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 + But as "Alice" folder "myFolder" should not exist + When user "Brian" moves file "/myFolder/fileInside" to "/myFolder/renamedFile" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/myFolder/renamedFile" should exist + And as "Alice" file "/folderToShare/renamedFile" should exist + But as "Alice" file "/folderToShare/fileInside" should not exist + + + 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 + But as "Alice" folder "myFolder" should not exist + 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 "/myFolder/renamedFile" should not exist + But as "Brian" file "/myFolder/fileInside" should exist diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShareFromLocalStorage.feature b/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShareFromLocalStorage.feature new file mode 100644 index 00000000000..b06c544f72b --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToRoot/moveReceivedShareFromLocalStorage.feature @@ -0,0 +1,64 @@ +@api @local_storage @files_external-app-required @notToImplementOnOCIS +Feature: local-storage + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @skipOnEncryptionType:user-keys @encryption-issue-181 + Scenario Outline: receiver renames a received file share from local storage + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" + And user "Alice" has shared file "/local_storage/filetoshare.txt" with user "Brian" + When user "Brian" moves file "/filetoshare.txt" to "/newFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/newFile.txt" should exist + But as "Brian" file "/filetoshare.txt.txt" should not exist + And as "Alice" file "/local_storage/filetoshare.txt" should exist + But as "Alice" file "/local_storage/newFile.txt" should not exist + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: receiver renames a received folder share from local storage + Given using OCS API version "" + And user "Alice" has created folder "/local_storage/foo" + And user "Alice" has shared folder "/local_storage/foo" with user "Brian" + When user "Brian" moves folder "/foo" to "/newFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/newFolder" should exist + But as "Brian" folder "/foo" should not exist + And as "Alice" folder "/local_storage/foo" should exist + But as "Alice" folder "/local_storage/newFolder" should not exist + Examples: + | ocs_api_version | + | 1 | + | 2 | + + @skipOnEncryptionType:user-keys @encryption-issue-181 + Scenario Outline: sub-folders,file inside a renamed received folder shared from local storage are accessible + Given using OCS API version "" + And user "Alice" has created folder "/local_storage/foo" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/foo/filetoshare.txt" + And user "Alice" has created folder "/local_storage/foo/folder1" + And user "Alice" has created folder "/local_storage/foo/folder2" + And user "Alice" has created folder "/local_storage/foo/folder2/subfolder" + And user "Alice" has shared folder "/local_storage/foo" with user "Brian" + When user "Brian" moves folder "/foo" to "/newFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/newFolder" should exist + And as "Brian" file "/newFolder/filetoshare.txt" should exist + And as "Brian" folder "/newFolder/folder1" should exist + And as "Brian" folder "/newFolder/folder2" should exist + And as "Brian" folder "/newFolder/folder2/subfolder" should exist + But as "Brian" folder "/foo" should not exist + And as "Alice" folder "/local_storage/foo" should exist + But as "Alice" folder "/local_storage/newFolder" should not exist + Examples: + | ocs_api_version | + | 1 | + | 2 | diff --git a/tests/acceptance/features/coreApiShareManagementToRoot/moveShareInsideAnotherShare.feature b/tests/acceptance/features/coreApiShareManagementToRoot/moveShareInsideAnotherShare.feature new file mode 100644 index 00000000000..c3f3f48d107 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToRoot/moveShareInsideAnotherShare.feature @@ -0,0 +1,79 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: moving a share inside another share + As a user + I want to move a shared resource inside another shared resource + Because I need full flexibility when managing resources. + + Background: + Given using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "folderA" + And user "Alice" has created folder "folderB" + And user "Alice" has uploaded file with content "text A" to "/folderA/fileA.txt" + And user "Alice" has uploaded file with content "text B" to "/folderB/fileB.txt" + And user "Alice" has shared folder "folderA" with user "Brian" + And user "Alice" has shared folder "folderB" with user "Brian" + + + Scenario: share receiver cannot move a whole share inside another share + When user "Brian" moves folder "folderB" to "folderA/folderB" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" folder "/folderB" should exist + And as "Brian" folder "/folderB" should exist + And as "Alice" file "/folderB/fileB.txt" should exist + And as "Brian" file "/folderB/fileB.txt" should exist + + + Scenario: share owner moves a whole share inside another share + When user "Alice" moves folder "folderB" to "folderA/folderB" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" folder "/folderB" should not exist + And as "Alice" folder "/folderA/folderB" should exist + And as "Brian" folder "/folderB" should exist + And as "Alice" file "/folderA/folderB/fileB.txt" should exist + And as "Brian" file "/folderA/folderB/fileB.txt" should exist + And as "Brian" file "/folderB/fileB.txt" should exist + + + Scenario: share receiver moves a whole share inside a local folder + Given user "Brian" has created folder "localFolder" + And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" + When user "Brian" moves folder "folderB" to "localFolder/folderB" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/localFolder/folderB" should exist + And as "Brian" file "/localFolder/folderB/fileB.txt" should exist + And as "Brian" file "/localFolder/localFile.txt" should exist + But as "Brian" file "/folderB/fileB.txt" should not exist + + + Scenario: share receiver moves a whole share inside a local folder then moves the local folder inside a received share + Given user "Brian" has created folder "localFolder" + And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" + When user "Brian" moves folder "folderB" to "localFolder/folderB" using the WebDAV API + And user "Brian" moves folder "localFolder" to "folderA/localFolder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" folder "/folderA/localFolder" should exist + And as "Brian" folder "/folderA/localFolder" should exist + And as "Alice" file "/folderA/localFolder/localFile.txt" should exist + And as "Brian" file "/folderA/localFolder/localFile.txt" should exist + # folderB now exists separately, and is no longer inside localFolder + And as "Alice" file "/folderB/fileB.txt" should exist + And as "Brian" file "/folderB/fileB.txt" should exist + But as "Alice" folder "/folderA/localFolder/folderB" should not exist + And as "Brian" folder "/folderA/localFolder/folderB" should not exist + + + Scenario: share receiver moves a whole share inside a local folder then tries to move the share inside a received share + Given user "Brian" has created folder "localFolder" + And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" + When user "Brian" moves folder "folderB" to "localFolder/folderB" using the WebDAV API + And user "Brian" moves folder "localFolder/folderB" to "folderA/folderB" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 403" respectively + And as "Alice" file "/folderB/fileB.txt" should exist + And as "Brian" folder "/localFolder/folderB" should exist + And as "Brian" file "/localFolder/folderB/fileB.txt" should exist + But as "Alice" folder "/folderA/folderB" should not exist + And as "Brian" folder "/folderA/folderB" should not exist diff --git a/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature b/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature new file mode 100644 index 00000000000..5c48f73ce70 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature @@ -0,0 +1,666 @@ +@api @files_sharing-app-required @issue-ocis-1289 @issue-ocis-1328 +Feature: accept/decline shares coming from internal users + As a user + I want to have control of which received shares I accept + So that I can keep my file system clean + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "1" + And using new DAV path + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "FOLDER" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Brian" has created folder "PARENT" + And user "Brian" has created folder "FOLDER" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + + @smokeTest + Scenario Outline: share a file & folder with another internal group when auto accept is disabled + Given user "Carol" has created folder "FOLDER" + And user "Carol" has created folder "PARENT" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + But user "Brian" should not see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /Shares/textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the pending state + | path | + | | + | | + And user "Carol" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + But user "Carol" should not see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /Shares/textfile0.txt | + And the sharing API should report to user "Carol" that these shares are in the pending state + | path | + | | + | | + @issue-ocis-2540 + Examples: + | pending_share_path_1 | pending_share_path_2 | + | /Shares/PARENT/ | /Shares/textfile0.txt | + + + Scenario Outline: share a file & folder with another internal user when auto accept is disabled + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + But user "Brian" should not see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /Shares/textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the pending state + | path | + | | + | | + @issue-ocis-2540 + Examples: + | pending_share_path_1 | pending_share_path_2 | + | /Shares/PARENT/ | /Shares/textfile0.txt | + + @smokeTest @issue-ocis-2131 + Scenario: accept a pending share + Given user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | share_type | user | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | share,read,update | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | state | 0 | + | path | /Shares/textfile0.txt | + | item_type | file | + | mimetype | text/plain | + | storage_id | shared::/Shares/textfile0.txt | + | storage | A_STRING | + | item_source | A_STRING | + | file_source | A_STRING | + | file_target | /Shares/textfile0.txt | + | share_with | %username% | + | share_with_displayname | %displayname% | + | mail_send | 0 | + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /Shares/textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /Shares/PARENT | + | /Shares/textfile0.txt | + + @notToImplementOnOCIS + Scenario Outline: accept a pending share when there is a default folder for received shares + Given the administrator has set the default folder for received shares to "" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | share_type | user | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | share,read,update | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | state | 0 | + | path | / | + | item_type | file | + | mimetype | text/plain | + | storage_id | shared::/ | + | storage | A_STRING | + | item_source | A_STRING | + | file_source | A_STRING | + | file_target | / | + | share_with | %username% | + | share_with_displayname | %displayname% | + | mail_send | 0 | + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | // | + | //parent.txt | + | /textfile0.txt | + | / | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | // | + | / | + Examples: + | share_folder | top_folder | received_parent_name | received_textfile_name | + | | | PARENT (2) | textfile0 (2).txt | + | / | | PARENT (2) | textfile0 (2).txt | + | /ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | + | ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | + | /My/Received/Shares | /My/Received/Shares | PARENT | textfile0.txt | + + + Scenario: accept an accepted share + Given user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + When user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /Shares/shared/ | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /Shares/shared/ | + + @smokeTest + Scenario Outline: declines a pending share + Given user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" declines share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" declines share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + But user "Brian" should not see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /Shares/textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | | + | | + @issue-ocis-2540 + Examples: + | declined_share_path_1 | declined_share_path_2 | + | /Shares/PARENT/ | /Shares/textfile0.txt | + + @smokeTest @issue-ocis-2128 + Scenario Outline: decline an accepted share + Given user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" declines share "/Shares/PARENT" offered by user "Alice" using the sharing API + And user "Brian" declines share "/Shares/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should not see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /Shares/textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | | + | | + @issue-ocis-2540 + Examples: + | declined_share_path_1 | declined_share_path_2 | + | /Shares/PARENT/ | /Shares/textfile0.txt | + + + Scenario: deleting shares in pending state + Given user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Alice" deletes folder "/PARENT" using the WebDAV API + And user "Alice" deletes file "/textfile0.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And the sharing API should report that no shares are shared with user "Brian" + + + Scenario Outline: only one user in a group accepts a share + Given user "Alice" has shared folder "/PARENT" with group "grp1" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" + When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Carol" should not see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /Shares/textfile0.txt | + And the sharing API should report to user "Carol" that these shares are in the pending state + | path | + | | + | | + But user "Brian" should see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /Shares/textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /Shares/PARENT/ | + | /Shares/textfile0.txt | + @issue-ocis-2540 + Examples: + | pending_share_path_1 | pending_share_path_2 | + | /Shares/PARENT/ | /Shares/textfile0.txt | + + @issue-ocis-2131 + Scenario: receive two shares with identical names from different users, accept one by one + Given user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/Alice" + And user "Brian" has created folder "/shared" + And user "Brian" has created folder "/shared/Brian" + And user "Alice" has shared folder "/shared" with user "Carol" + And user "Brian" has shared folder "/shared" with user "Carol" + When user "Carol" accepts share "/shared" offered by user "Brian" using the sharing API + And user "Carol" accepts share "/shared" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Carol" should see the following elements + | /Shares/shared/Brian/ | + | /Shares/shared (2)/Alice/ | + And the sharing API should report to user "Carol" that these shares are in the accepted state + | path | + | /Shares/shared/ | + | /Shares/shared (2)/ | + + + Scenario Outline: share with a group that you are part of yourself + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the sharing API should report to user "Brian" that these shares are in the pending state + | path | + | | + And the sharing API should report that no shares are shared with user "Alice" + @issue-ocis-2540 + Examples: + | pending_share_path | + | /Shares/PARENT/ | + + + Scenario Outline: user accepts file that was initially accepted from another user and then declined + Given user "Alice" has uploaded file with content "First file" to "/testfile.txt" + And user "Brian" has uploaded file with content "Second file" to "/testfile.txt" + And user "Carol" has created folder "Shares" + And user "Carol" has uploaded file with content "Third file" to "/Shares/testfile.txt" + And user "Alice" has shared file "/testfile.txt" with user "Carol" + And user "Carol" has accepted share "/testfile.txt" offered by user "Alice" + When user "Carol" declines share "/Shares/testfile (2).txt" offered by user "Alice" using the sharing API + And user "Brian" shares file "/testfile.txt" with user "Carol" using the sharing API + And user "Carol" accepts share "/testfile.txt" offered by user "Brian" using the sharing API + And user "Carol" accepts share "" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the sharing API should report to user "Carol" that these shares are in the accepted state + | path | + | /Shares/testfile (2).txt | + | /Shares/testfile (2) (2).txt | + And the content of file "/Shares/testfile.txt" for user "Carol" should be "Third file" + And the content of file "/Shares/testfile (2).txt" for user "Carol" should be "Second file" + And the content of file "/Shares/testfile (2) (2).txt" for user "Carol" should be "First file" + Examples: + | accepted_share_path | + | /testfile (2).txt | + + + Scenario Outline: user accepts shares received from multiple users with the same name when auto-accept share is disabled + Given user "David" has been created with default attributes and without skeleton files + And user "David" has created folder "PARENT" + And user "Brian" has shared folder "/PARENT" with user "Alice" + And user "Carol" has created folder "PARENT" + And user "Carol" has shared folder "/PARENT" with user "Alice" + And user "Alice" has created folder "Shares" + And user "Alice" has created folder "Shares/PARENT" + When user "Alice" accepts share "/PARENT" offered by user "Brian" using the sharing API + And user "Alice" declines share "/Shares/PARENT (2)" offered by user "Brian" using the sharing API + And user "Alice" accepts share "/PARENT" offered by user "Carol" using the sharing API + And user "Alice" accepts share "" offered by user "Brian" using the sharing API + And user "Alice" declines share "/Shares/PARENT (2)" offered by user "Carol" using the sharing API + And user "Alice" declines share "/Shares/PARENT (2) (2)" offered by user "Brian" using the sharing API + And user "David" shares folder "/PARENT" with user "Alice" using the sharing API + And user "Alice" accepts share "/PARENT" offered by user "David" using the sharing API + And user "Alice" accepts share "" offered by user "Carol" using the sharing API + And user "Alice" accepts share "" offered by user "Brian" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And the sharing API should report to user "Alice" that these shares are in the accepted state + | path | uid_owner | + | /Shares/PARENT (2)/ | David | + | /Shares/PARENT (2) (2)/ | Carol | + | /Shares/PARENT (2) (2) (2)/ | Brian | + Examples: + | accepted_share_path_1 | accepted_share_path_2 | + | /PARENT (2) | /PARENT (2) (2) | + + + Scenario: user shares folder with matching folder-name for both user involved in sharing + Given user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" + And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /Shares/PARENT/ | + | /Shares/PARENT/abc.txt | + | /Shares/FOLDER/ | + | /Shares/FOLDER/abc.txt | + And user "Brian" should not see the following elements + | /FOLDER/abc.txt | + | /PARENT/abc.txt | + And the content of file "/Shares/PARENT/abc.txt" for user "Brian" should be "uploaded content" + And the content of file "/Shares/FOLDER/abc.txt" for user "Brian" should be "uploaded content" + + + Scenario: user shares folder in a group with matching folder-name for every users involved + Given user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" + And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt" + And user "Carol" has created folder "PARENT" + And user "Carol" has created folder "FOLDER" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API + When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + And user "Carol" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Carol" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /Shares/PARENT/ | + | /Shares/FOLDER/ | + | /Shares/PARENT/abc.txt | + | /Shares/FOLDER/abc.txt | + And user "Brian" should not see the following elements + | /FOLDER/abc.txt | + | /PARENT/abc.txt | + And user "Carol" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /Shares/PARENT/ | + | /Shares/FOLDER/ | + | /Shares/PARENT/abc.txt | + | /Shares/FOLDER/abc.txt | + And user "Carol" should not see the following elements + | /FOLDER/abc.txt | + | /PARENT/abc.txt | + And the content of file "/Shares/PARENT/abc.txt" for user "Brian" should be "uploaded content" + And the content of file "/Shares/FOLDER/abc.txt" for user "Brian" should be "uploaded content" + And the content of file "/Shares/PARENT/abc.txt" for user "Carol" should be "uploaded content" + And the content of file "/Shares/FOLDER/abc.txt" for user "Carol" should be "uploaded content" + + + Scenario: user shares files in a group with matching file-names for every users involved in sharing + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + And user "Alice" shares file "/textfile1.txt" with group "grp1" using the sharing API + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/textfile1.txt" offered by user "Alice" using the sharing API + And user "Carol" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + And user "Carol" accepts share "/textfile1.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /textfile0.txt | + | /textfile1.txt | + | /Shares/textfile0.txt | + | /Shares/textfile1.txt | + And user "Carol" should see the following elements + | /textfile0.txt | + | /textfile1.txt | + | /Shares/textfile0.txt | + | /Shares/textfile1.txt | + + + Scenario: user shares resource with matching resource-name with another user when auto accept is disabled + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /PARENT/ | + | /textfile0.txt | + But user "Brian" should not see the following elements + | /Shares/textfile0.txt | + | /Shares/PARENT/ | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /PARENT/ | + | /textfile0.txt | + | /Shares/PARENT/ | + | /Shares/textfile0.txt | + + + Scenario: user shares file in a group with matching filename when auto accept is disabled + Given user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /textfile0.txt | + But user "Brian" should not see the following elements + | /Shares/textfile0.txt | + And user "Carol" should see the following elements + | /textfile0.txt | + But user "Carol" should not see the following elements + | /Shares/textfile0.txt | + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + When user "Carol" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /textfile0.txt | + | /Shares/textfile0.txt | + And user "Carol" should see the following elements + | /textfile0.txt | + | /Shares/textfile0.txt | + + @skipOnLDAP + Scenario: user shares folder with matching folder name to a user before that user has logged in + Given these users have been created without skeleton files and not initialized: + | username | + | David | + And user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" + When user "Alice" shares folder "/PARENT" with user "David" using the sharing API + And user "David" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "David" should see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/abc.txt | + And user "David" should not see the following elements + | /PARENT (2)/ | + And the content of file "/Shares/PARENT/abc.txt" for user "David" should be "uploaded content" + + @issue-ocis-1123 + Scenario Outline: deleting a share accepted file and folder + Given user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" deletes file "/Shares/PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | | + @issue-ocis-2540 + Examples: + | declined_share_path | + | /Shares/PARENT | + + @issue-ocis-765 @issue-ocis-2131 + Scenario: shares exist after restoring already shared file to a previous version + And user "Alice" has uploaded file with content "Test Content." to "/toShareFile.txt" + And user "Alice" has uploaded file with content "Content Test Updated." to "/toShareFile.txt" + And user "Alice" has shared file "/toShareFile.txt" with user "Brian" + And user "Brian" has accepted share "/toShareFile.txt" offered by user "Alice" + When user "Alice" restores version index "1" of file "/toShareFile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/toShareFile.txt" for user "Alice" should be "Test Content." + And the content of file "/Shares/toShareFile.txt" for user "Brian" should be "Test Content." + + @issue-ocis-2131 + Scenario: a user receives multiple group shares for matching file and folder name + Given group "grp2" has been created + And user "Alice" has been added to group "grp2" + And user "Brian" has been added to group "grp2" + And user "Carol" has created folder "/PARENT" + And user "Alice" has created folder "/PaRent" + And user "Alice" has uploaded the following files with content "subfile, from alice to grp2" + | path | + | /PARENT/parent.txt | + | /PaRent/parent.txt | + And user "Alice" has uploaded the following files with content "from alice to grp2" + | path | + | /PARENT.txt | + And user "Carol" has uploaded the following files with content "subfile, from carol to grp1" + | path | + | /PARENT/parent.txt | + And user "Carol" has uploaded the following files with content "from carol to grp1" + | path | + | /PARENT.txt | + | /parent.txt | + When user "Alice" shares the following entries with group "grp2" using the sharing API + | path | + | /PARENT | + | /PaRent | + | /PARENT.txt | + And user "Brian" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /PARENT | + | /PaRent | + | /PARENT.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /PARENT/ | + | /Shares/PARENT/ | + | /Shares/PaRent/ | + | /Shares/PARENT.txt | + And the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "subfile, from alice to grp2" + And the content of file "/Shares/PaRent/parent.txt" for user "Brian" should be "subfile, from alice to grp2" + And the content of file "/Shares/PARENT.txt" for user "Brian" should be "from alice to grp2" + When user "Carol" shares the following entries with group "grp2" using the sharing API + | path | + | /PARENT | + | /PARENT.txt | + | /parent.txt | + And user "Brian" accepts the following shares offered by user "Carol" using the sharing API + | path | + | /PARENT | + | /PARENT.txt | + | /parent.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /PARENT/ | + | /Shares/PARENT/ | + | /Shares/PARENT (2)/ | + | /Shares/PaRent/ | + | /Shares/PARENT.txt | + | /Shares/PARENT (2).txt | + | /Shares/parent.txt | + And the content of file "/Shares/PARENT (2)/parent.txt" for user "Brian" should be "subfile, from carol to grp1" + And the content of file "/Shares/PARENT (2).txt" for user "Brian" should be "from carol to grp1" + And the content of file "/Shares/parent.txt" for user "Brian" should be "from carol to grp1" + + @issue-ocis-2131 + Scenario: a group receives multiple shares from non-member for matching file and folder name + Given user "Brian" has been removed from group "grp1" + And user "Alice" has created folder "/PaRent" + And user "Carol" has created folder "/PARENT" + And user "Alice" has uploaded the following files with content "subfile, from alice to grp1" + | path | + | /PARENT/parent.txt | + | /PaRent/parent.txt | + And user "Alice" has uploaded the following files with content "from alice to grp1" + | path | + | /PARENT.txt | + And user "Brian" has uploaded the following files with content "subfile, from brian to grp1" + | path | + | /PARENT/parent.txt | + And user "Brian" has uploaded the following files with content "from brian to grp1" + | path | + | /PARENT.txt | + | /parent.txt | + When user "Alice" shares the following entries with group "grp1" using the sharing API + | path | + | /PARENT | + | /PaRent | + | /PARENT.txt | + And user "Carol" accepts the following shares offered by user "Alice" using the sharing API + | path | + | /PARENT | + | /PaRent | + | /PARENT.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Carol" should see the following elements + | /PARENT/ | + | /Shares/PARENT/ | + | /Shares/PaRent/ | + | /Shares/PARENT.txt | + And the content of file "/Shares/PARENT/parent.txt" for user "Carol" should be "subfile, from alice to grp1" + And the content of file "/Shares/PARENT.txt" for user "Carol" should be "from alice to grp1" + When user "Brian" shares the following entries with group "grp1" using the sharing API + | path | + | /PARENT | + | /PARENT.txt | + | /parent.txt | + And user "Carol" accepts the following shares offered by user "Brian" using the sharing API + | path | + | /PARENT | + | /PARENT.txt | + | /parent.txt | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Carol" should see the following elements + | /PARENT/ | + | /Shares/PARENT/ | + | /Shares/PARENT (2)/ | + | /Shares/PaRent/ | + | /Shares/PARENT.txt | + | /Shares/PARENT (2).txt | + | /Shares/parent.txt | + And the content of file "/Shares/PARENT (2)/parent.txt" for user "Carol" should be "subfile, from brian to grp1" + And the content of file "/Shares/PARENT (2).txt" for user "Carol" should be "from brian to grp1" diff --git a/tests/acceptance/features/coreApiShareManagementToShares/acceptSharesToSharesFolder.feature b/tests/acceptance/features/coreApiShareManagementToShares/acceptSharesToSharesFolder.feature new file mode 100644 index 00000000000..ab1dbe33750 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToShares/acceptSharesToSharesFolder.feature @@ -0,0 +1,75 @@ +@api @files_sharing-app-required +Feature: accept/decline shares coming from internal users to the Shares folder + As a user + I want to have control of which received shares I accept + So that I can keep my file system clean + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using OCS API version "1" + And using new DAV path + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario: When accepting a share of a file, the received file is accessible + Given user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" + + + Scenario: When accepting a share of a folder, the received folder is accessible + Given user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Alice" has shared file "/PARENT" with user "Brian" + When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" + + + Scenario: When accepting a share of a file, the response is valid + Given user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/textfile0.txt | + | path | /Shares/textfile0.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" + + + Scenario: When accepting a share of a folder, the response is valid + Given user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Alice" has shared file "/PARENT" with user "Brian" + When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/PARENT | + | path | /Shares/PARENT | + | permissions | all | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | folder | + | mimetype | httpd/unix-directory | + | storage_id | ANY_VALUE | + | share_type | user | + And the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "ownCloud test text file parent" diff --git a/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature b/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature new file mode 100644 index 00000000000..a28b21edd25 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature @@ -0,0 +1,158 @@ +@api @files_sharing-app-required @issue-ocis-reva-1328 @issues-ocis-1289 +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + + @smokeTest + Scenario: Merging shares for recipient when shared from outside with group and member + Given user "Alice" has created folder "/merge-test-outside" + When user "Alice" shares folder "/merge-test-outside" with group "grp1" using the sharing API + And user "Alice" shares folder "/merge-test-outside" with user "Brian" using the sharing API + And user "Brian" accepts share "/merge-test-outside" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" folder "/Shares/merge-test-outside" should exist + And as "Brian" folder "/Shares/merge-test-outside (2)" should not exist + + + Scenario: Merging shares for recipient when shared from outside with group and member with different permissions + Given user "Alice" has created folder "/merge-test-outside-perms" + When user "Alice" shares folder "/merge-test-outside-perms" with group "grp1" with permissions "read" using the sharing API + And user "Alice" shares folder "/merge-test-outside-perms" with user "Brian" with permissions "all" using the sharing API + And user "Brian" accepts share "/merge-test-outside-perms" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as user "Brian" folder "/Shares/merge-test-outside-perms" should contain a property "oc:permissions" with value "SRDNVCK" + And as "Brian" folder "/Shares/merge-test-outside-perms (2)" should not exist + + + Scenario: Merging shares for recipient when shared from outside with two groups + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Alice" has created folder "/merge-test-outside-twogroups" + When user "Alice" shares folder "/merge-test-outside-twogroups" with group "grp1" using the sharing API + And user "Alice" shares folder "/merge-test-outside-twogroups" with group "grp2" using the sharing API + And user "Brian" accepts share "/merge-test-outside-twogroups" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" folder "/Shares/merge-test-outside-twogroups" should exist + And as "Brian" folder "/Shares/merge-test-outside-twogroups (2)" should not exist + + + Scenario: Merging shares for recipient when shared from outside with two groups with different permissions + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Alice" has created folder "/merge-test-outside-twogroups-perms" + When user "Alice" shares folder "/merge-test-outside-twogroups-perms" with group "grp1" with permissions "read" using the sharing API + And user "Alice" shares folder "/merge-test-outside-twogroups-perms" with group "grp2" with permissions "all" using the sharing API + And user "Brian" accepts share "/merge-test-outside-twogroups-perms" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as user "Brian" folder "/Shares/merge-test-outside-twogroups-perms" should contain a property "oc:permissions" with value "SRDNVCK" + And as "Brian" folder "/Shares/merge-test-outside-twogroups-perms (2)" should not exist + + + Scenario: Merging shares for recipient when shared from outside with two groups and member + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Alice" has created folder "/merge-test-outside-twogroups-member-perms" + When user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with group "grp1" with permissions "read" using the sharing API + And user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with group "grp2" with permissions "all" using the sharing API + And user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with user "Brian" with permissions "read" using the sharing API + And user "Brian" accepts share "/merge-test-outside-twogroups-member-perms" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as user "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms" should contain a property "oc:permissions" with value "SRDNVCK" + And as "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms (2)" should not exist + + + Scenario: Merging shares for recipient when shared from inside with group + Given user "Brian" has created folder "/merge-test-inside-group" + When user "Brian" shares folder "/merge-test-inside-group" with group "grp1" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And as "Brian" folder "/merge-test-inside-group" should exist + And as "Brian" folder "/Shares/merge-test-inside-group" should not exist + + + Scenario: Merging shares for recipient when shared from inside with two groups + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Brian" has created folder "/merge-test-inside-twogroups" + When user "Brian" shares folder "/merge-test-inside-twogroups" with group "grp1" using the sharing API + And user "Brian" shares folder "/merge-test-inside-twogroups" with group "grp2" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" folder "/merge-test-inside-twogroups" should exist + And as "Brian" folder "/Shares/merge-test-inside-twogroups" should not exist + And as "Brian" folder "/Shares/merge-test-inside-twogroups (2)" should not exist + + + Scenario Outline: Merging shares for recipient when shared from inside with group with less permissions + Given group "grp2" has been created + And user "Brian" has been added to group "grp2" + And user "Brian" has created folder "/merge-test-inside-twogroups-perms" + When user "Brian" shares folder "/merge-test-inside-twogroups-perms" with group "grp1" using the sharing API + And user "Brian" shares folder "/merge-test-inside-twogroups-perms" with group "grp2" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as user "Brian" folder "/merge-test-inside-twogroups-perms" should contain a property "oc:permissions" with value "" or with value "" + And as "Brian" folder "/Shares/merge-test-inside-twogroups-perms" should not exist + And as "Brian" folder "/Shares/merge-test-inside-twogroups-perms (2)" should not exist + @skipOnOcV10 + Examples: + | expected_permission_1 | expected_permission_2 | + | RDNVCKZ | RMDNVCKZ | + @skipOnOcis + Examples: + | expected_permission_1 | expected_permission_2 | + | RDNVCK | RMDNVCK | + + + Scenario: Merging shares for recipient when shared from outside with group then user and recipient renames in between + Given user "Alice" has created folder "/merge-test-outside-groups-renamebeforesecondshare" + # Section 1: Brian receives and accepts the group share from Alice and moves and renames it out of the "Shares" folder + When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with group "grp1" using the sharing API + And user "Brian" accepts share "/merge-test-outside-groups-renamebeforesecondshare" offered by user "Alice" using the sharing API + And user "Brian" moves folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" to "/merge-test-outside-groups-renamebeforesecondshare-renamed" using the WebDAV API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on each endpoint should be "200, 200, 201" respectively + And as "Brian" folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" should not exist + But as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should exist + # Section 2: Brian receives and accepts the user share from Alice. Brian now has 2 shares of the same folder owned by Alice + # The server "merges" the 2 shares and presents them to Brian as a single folder inside the "Shares" folder + When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with user "Brian" using the sharing API + And user "Brian" accepts share "/merge-test-outside-groups-renamebeforesecondshare" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" should exist + But as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should not exist + + + Scenario: Merging shares for recipient when shared from outside with user then group and recipient renames in between + Given user "Alice" has created folder "/merge-test-outside-groups-renamebeforesecondshare" + # Section 1: Brian receives and accepts the user share from Alice and moves and renames it out of the "Shares" folder + When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with user "Brian" using the sharing API + And user "Brian" accepts share "/merge-test-outside-groups-renamebeforesecondshare" offered by user "Alice" using the sharing API + And user "Brian" moves folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" to "/merge-test-outside-groups-renamebeforesecondshare-renamed" using the WebDAV API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on each endpoint should be "200, 200, 201" respectively + And as "Brian" folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" should not exist + But as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should exist + # Section 2: Brian receives and accepts the group share from Alice. Brian now has 2 shares of the same folder owned by Alice + # The server "merges" the 2 shares and presents them to Brian as a single folder inside the "Shares" folder + When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with group "grp1" using the sharing API + And user "Brian" accepts share "/merge-test-outside-groups-renamebeforesecondshare" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" should exist + But as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should not exist diff --git a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature new file mode 100644 index 00000000000..6f31015a0ba --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature @@ -0,0 +1,376 @@ +@api @files_sharing-app-required @issue-ocis-1289 @issue-ocis-1328 +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + + @issue-ocis-2141 @notToImplementOnOCIS + Scenario: Keep usergroup shares (#22143) + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/TMP" + When user "Alice" shares folder "TMP" with group "grp1" using the sharing API + And user "Brian" accepts share "/TMP" offered by user "Alice" using the sharing API + And user "Carol" accepts share "/TMP" offered by user "Alice" using the sharing API + And user "Brian" creates folder "/myFOLDER" using the WebDAV API + And user "Brian" moves folder "/Shares/TMP" to "/myFOLDER/myTMP" using the WebDAV API + And the administrator deletes user "Carol" using the provisioning API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /myFOLDER/myTMP/ | + + + Scenario: Keep usergroup shares when the user renames the share within the Shares folder(#22143) + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/TMP" + When user "Alice" shares folder "TMP" with group "grp1" using the sharing API + And user "Brian" accepts share "/TMP" offered by user "Alice" using the sharing API + And user "Carol" accepts share "/TMP" offered by user "Alice" using the sharing API + And user "Brian" moves folder "/Shares/TMP" to "/Shares/new" using the WebDAV API + And the administrator deletes user "Carol" using the provisioning API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /Shares/new/| + + @issue-ocis-2141 @notToImplementOnOCIS + Scenario: keep user shared file name same after one of recipient has renamed the file + Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" + And user "Alice" has shared file "/sharefile.txt" with user "Brian" + And user "Alice" has shared file "/sharefile.txt" with user "Carol" + And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" + And user "Carol" has accepted share "/sharefile.txt" offered by user "Alice" + When user "Carol" moves file "/Shares/sharefile.txt" to "/renamedsharefile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Carol" file "/renamedsharefile.txt" should exist + And as "Alice" file "/sharefile.txt" should exist + And as "Brian" file "/Shares/sharefile.txt" should exist + + + Scenario: keep user shared file name same after one of recipient has renamed the file inside the Shares folder + Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" + And user "Alice" has shared file "/sharefile.txt" with user "Brian" + And user "Alice" has shared file "/sharefile.txt" with user "Carol" + And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" + And user "Carol" has accepted share "/sharefile.txt" offered by user "Alice" + When user "Carol" moves file "/Shares/sharefile.txt" to "/Shares/renamedsharefile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Carol" file "/Shares/renamedsharefile.txt" should exist + And as "Alice" file "/sharefile.txt" should exist + And as "Brian" file "/Shares/sharefile.txt" should exist + + @issue-ocis-2141 @notToImplementOnOCIS + Scenario: keep user shared file directory same in respect to respective user if one of the recipient has moved the file + Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" + And user "Alice" has shared file "/sharefile.txt" with user "Brian" + And user "Alice" has shared file "/sharefile.txt" with user "Carol" + And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" + And user "Carol" has accepted share "/sharefile.txt" offered by user "Alice" + And user "Carol" has created folder "newfolder" + When user "Carol" moves file "/Shares/sharefile.txt" to "/newfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Carol" file "/newfolder/sharefile.txt" should exist + And as "Alice" file "/sharefile.txt" should exist + And as "Brian" file "/Shares/sharefile.txt" should exist + + @issue-ocis-2146 @notToImplementOnOCIS + Scenario Outline: move folder inside received folder with special characters + Given group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "" + And user "Alice" has created folder "" + And user "Brian" has created folder "" + And user "Carol" has created folder "" + And user "Alice" has shared folder "" with user "Brian" + And user "Brian" has accepted share "/" offered by user "Alice" + When user "Brian" moves folder "" to "/Shares//" using the WebDAV API + And user "Alice" shares folder "" with group "grp1" using the sharing API + And user "Carol" accepts share "/" offered by user "Alice" using the sharing API + And user "Carol" moves folder "/" to "/Shares//" using the WebDAV API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on each endpoint should be "201, 200, 200, 201" respectively + And as "Alice" folder "/" should exist + And as "Brian" folder "/Shares//" should exist + And as "Alice" folder "/" should exist + And as "Carol" folder "/Shares//" should exist + Examples: + | sharer_folder | group_folder | receiver_folder | + | ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | + | @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | + + @issue-ocis-2141 @notToImplementOnOCIS + Scenario: receiver renames a received share with share, read, change 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,change" + And user "Brian" has accepted share "/folderToShare" offered by user "Alice" + When user "Brian" moves folder "/Shares/folderToShare" to "myFolder" using the WebDAV API + 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 + Then the HTTP status code should be "201" + And as "Brian" file "/myFolder/renamedFile" should exist + And as "Alice" file "/folderToShare/renamedFile" should exist + But as "Alice" file "/folderToShare/fileInside" should not exist + + + Scenario: receiver renames a received share with share, read, change permissions inside the Shares folder + 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,change" + And user "Brian" has accepted share "/folderToShare" offered by user "Alice" + When user "Brian" moves folder "/Shares/folderToShare" to "/Shares/myFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/myFolder" should exist + But as "Alice" folder "/Shares/myFolder" should not exist + When user "Brian" moves file "/Shares/myFolder/fileInside" to "/Shares/myFolder/renamedFile" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/myFolder/renamedFile" should exist + And as "Alice" file "/folderToShare/renamedFile" should exist + But as "Alice" file "/folderToShare/fileInside" should not exist + + @issue-ocis-2141 @notToImplementOnOCIS + 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" + And user "Brian" has accepted share "/folderToShare" offered by user "Alice" + When user "Brian" moves folder "/Shares/folderToShare" to "/myFolder" using the WebDAV API + 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 + Then the HTTP status code should be "403" + And as "Brian" file "/myFolder/renamedFile" should not exist + But as "Brian" file "/myFolder/fileInside" should exist + + + Scenario: receiver tries to rename a received share with share, read permissions inside the Shares folder + 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" + And user "Brian" has accepted share "/folderToShare" offered by user "Alice" + When user "Brian" moves folder "/Shares/folderToShare" to "/Shares/myFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/myFolder" should exist + But as "Alice" folder "/Shares/myFolder" should not exist + When user "Brian" moves file "/Shares/myFolder/fileInside" to "/Shares/myFolder/renamedFile" using the WebDAV API + Then the HTTP status code should be "403" + And as "Brian" file "/Shares/myFolder/renamedFile" should not exist + But as "Brian" file "Shares/myFolder/fileInside" should exist + + + Scenario: receiver renames a received folder share to a different name on the same folder + Given user "Alice" has created folder "PARENT" + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/myFolder" should exist + But as "Alice" folder "myFolder" should not exist + + + Scenario: receiver renames a received file share to different name on the same folder + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has shared file "fileToShare.txt" with user "Brian" + And user "Brian" has accepted share "/fileToShare.txt" offered by user "Alice" + When user "Brian" moves file "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/newFile.txt" should exist + But as "Alice" file "newFile.txt" should not exist + + + Scenario: receiver renames a received file share to different name on the same folder for group sharing + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has shared file "fileToShare.txt" with group "grp1" + And user "Brian" has accepted share "/fileToShare.txt" offered by user "Alice" + When user "Brian" moves file "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/newFile.txt" should exist + But as "Alice" file "newFile.txt" should not exist + + + Scenario: receiver renames a received folder share to different name on the same folder for group sharing + Given group "grp1" has been created + And user "Alice" has created folder "PARENT" + And user "Brian" has been added to group "grp1" + And user "Alice" has shared folder "PARENT" with group "grp1" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/myFolder" should exist + But as "Alice" folder "myFolder" should not exist + + @issue-ocis-2141 @notToImplementOnOCIS + Scenario: receiver renames a received file share with read,update,share permissions in group sharing + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "read,update,share" + And user "Brian" has accepted share "/fileToShare.txt" offered by user "Alice" + When user "Brian" moves folder "/Shares/fileToShare.txt" to "newFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "newFile.txt" should exist + But as "Alice" file "newFile.txt" should not exist + + + Scenario: receiver renames a received file share with read,update,share permissions inside the Shares folder in group sharing + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "read,update,share" + And user "Brian" has accepted share "/fileToShare.txt" offered by user "Alice" + When user "Brian" moves folder "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/newFile.txt" should exist + But as "Alice" file "/Shares/newFile.txt" should not exist + + @issue-ocis-2141 @notToImplementOnOCIS + Scenario: receiver renames a received folder share with share, read, change permissions in group sharing + Given group "grp1" has been created + And user "Alice" has created folder "PARENT" + And user "Brian" has been added to group "grp1" + And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read,change" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" moves folder "/Shares/PARENT" to "myFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "myFolder" should exist + But as "Alice" folder "myFolder" should not exist + + + Scenario: receiver renames a received folder share with share, read, change permissions inside the Shares folder in group sharing + Given group "grp1" has been created + And user "Alice" has created folder "PARENT" + And user "Brian" has been added to group "grp1" + And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read,change" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/myFolder" should exist + But as "Alice" folder "/Shares/myFolder" should not exist + + @issue-ocis-2141 @notToImplementOnOCIS + Scenario: receiver renames a received file share with share, read permissions in group sharing + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "share,read" + And user "Brian" has accepted share "/fileToShare.txt" offered by user "Alice" + When user "Brian" moves file "/Shares/fileToShare.txt" to "/newFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "newFile.txt" should exist + But as "Alice" file "newFile.txt" should not exist + + + Scenario: receiver renames a received file share with share, read permissions inside the Shares folder in group sharing) + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" + And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "share,read" + And user "Brian" has accepted share "/fileToShare.txt" offered by user "Alice" + When user "Brian" moves file "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/newFile.txt" should exist + But as "Alice" file "/Shares/newFile.txt" should not exist + + @issue-ocis-2141 @notToImplementOnOCIS + Scenario: receiver renames a received folder share with share, read permissions in group sharing + Given group "grp1" has been created + And user "Alice" has created folder "PARENT" + And user "Brian" has been added to group "grp1" + And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" moves folder "/Shares/PARENT" to "/myFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "myFolder" should exist + But as "Alice" folder "myFolder" should not exist + + + Scenario: receiver renames a received folder share with share, read permissions inside the Shares folder in group sharing + Given group "grp1" has been created + And user "Alice" has created folder "PARENT" + And user "Brian" has been added to group "grp1" + And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/myFolder" should exist + But as "Alice" folder "/Shares/myFolder" should not exist + + @issue-ocis-2141 + Scenario Outline: receiver renames a received folder share to name with special characters in group sharing + Given group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "" + And user "Alice" has created folder "" + And user "Alice" has shared folder "" with user "Brian" + And user "Brian" has accepted share "/" offered by user "Alice" + When user "Brian" moves folder "/Shares/" to "/Shares/" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" folder "" should not exist + And as "Brian" folder "/Shares/" should exist + When user "Alice" shares folder "" with group "grp1" using the sharing API + And user "Carol" accepts share "/" offered by user "Alice" using the sharing API + And user "Carol" moves folder "/Shares/" to "/Shares/" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" folder "" should not exist + But as "Carol" folder "/Shares/" should exist + Examples: + | sharer_folder | group_folder | receiver_folder | + | ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | + | @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | + + @issue-ocis-2141 + Scenario Outline: receiver renames a received file share to name with special characters with share, read, change permissions in group sharing + Given group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "" + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "//fileInside" + And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "//fileInside" + And user "Alice" has shared folder "" with user "Brian" with permissions "share,read,change" + And user "Brian" has accepted share "/" offered by user "Alice" + When user "Brian" moves folder "/Shares//fileInside" to "/Shares//" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/" should exist + And as "Brian" file "/Shares//" should exist + When user "Alice" shares folder "" with group "grp1" with permissions "share,read,change" using the sharing API + And user "Carol" accepts share "/" offered by user "Alice" using the sharing API + And user "Carol" moves folder "/Shares//fileInside" to "/Shares//" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/" should exist + And as "Carol" file "/Shares//" should exist + Examples: + | sharer_folder | group_folder | receiver_file | + | ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | + | @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | + + @issue-ocis-2141 @notToImplementOnOCIS + Scenario: receiver moves file within a received folder to new folder + Given user "Alice" has created folder "folderToShare" + And user "Brian" has created folder "FOLDER" + And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileToShare1.txt" + And user "Alice" has uploaded file with content "thisIsAnotherFileInsideTheSharedFolder" to "/folderToShare/fileToShare2.txt" + And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read,change" + And user "Brian" has accepted share "/folderToShare" offered by user "Alice" + When user "Brian" moves file "/Shares/folderToShare/fileToShare1.txt" to "/FOLDER/fileToShare1.txt" using the WebDAV API + And user "Brian" moves file "/Shares/folderToShare/fileToShare2.txt" to "/FOLDER/fileToShare2.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And as "Brian" file "/FOLDER/fileToShare1.txt" should exist + And as "Brian" file "/FOLDER/fileToShare2.txt" should exist + But as "Alice" file "/folderToShare/fileToShare1.txt" should not exist + And as "Alice" file "/folderToShare/fileToShare2.txt" should not exist diff --git a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShareFromLocalStorage.feature b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShareFromLocalStorage.feature new file mode 100644 index 00000000000..59207f03c29 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShareFromLocalStorage.feature @@ -0,0 +1,90 @@ +@api @local_storage @files_external-app-required @notToImplementOnOCIS +Feature: local-storage + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @skipOnEncryptionType:user-keys @encryption-issue-181 + Scenario Outline: receiver renames a received file share from local storage + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" + And user "Alice" has shared file "/local_storage/filetoshare.txt" with user "Brian" + And user "Brian" has accepted share "" offered by user "Alice" + When user "Brian" moves file "/Shares/filetoshare.txt" to "/Shares/newFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/newFile.txt" should exist + But as "Brian" file "/Shares/filetoshare.txt" should not exist + And as "Alice" file "/local_storage/filetoshare.txt" should exist + But as "Alice" file "/local_storage/newFile.txt" should not exist + Examples: + | ocs_api_version | pending_share_path | + | 1 | /filetoshare.txt | + | 2 | /filetoshare.txt | + + + Scenario Outline: receiver renames a received folder share from local storage + Given using OCS API version "" + And user "Alice" has created folder "/local_storage/foo" + And user "Alice" has shared folder "/local_storage/foo" with user "Brian" + And user "Brian" has accepted share "" offered by user "Alice" + When user "Brian" moves folder "/Shares/foo" to "/Shares/newFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/newFolder" should exist + But as "Brian" folder "/Shares/foo" should not exist + And as "Alice" folder "/local_storage/foo" should exist + But as "Alice" folder "/local_storage/newFolder" should not exist + Examples: + | ocs_api_version | pending_share_path | + | 1 | /foo | + | 2 | /foo | + + @skipOnEncryptionType:user-keys @encryption-issue-181 + Scenario Outline: sub-folders,file inside a renamed received folder shared from local storage are accessible + Given using OCS API version "" + And user "Alice" has created folder "/local_storage/foo" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/foo/filetoshare.txt" + And user "Alice" has created folder "/local_storage/foo/folder1" + And user "Alice" has created folder "/local_storage/foo/folder2" + And user "Alice" has created folder "/local_storage/foo/folder2/subfolder" + And user "Alice" has shared folder "/local_storage/foo" with user "Brian" + And user "Brian" has accepted share "" offered by user "Alice" + When user "Brian" moves folder "/Shares/foo" to "/Shares/newFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/newFolder" should exist + And as "Brian" file "/Shares/newFolder/filetoshare.txt" should exist + And as "Brian" folder "/Shares/newFolder/folder1" should exist + And as "Brian" folder "/Shares/newFolder/folder2" should exist + And as "Brian" folder "/Shares/newFolder/folder2/subfolder" should exist + But as "Brian" folder "/Shares/foo" should not exist + And as "Alice" folder "/local_storage/foo" should exist + But as "Alice" folder "/local_storage/newFolder" should not exist + Examples: + | ocs_api_version | pending_share_path | + | 1 | /foo | + | 2 | /foo | + + @skipOnEncryptionType:user-keys @encryption-issue-181 + Scenario Outline: receiver renames a received file share from local storage in group sharing + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" + And user "Alice" has shared file "/local_storage/filetoshare.txt" with group "grp1" + And user "Brian" has accepted share "" offered by user "Alice" + When user "Brian" moves file "/Shares/filetoshare.txt" to "/Shares/newFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/newFile.txt" should exist + But as "Brian" file "/Shares/filetoshare.txt" should not exist + And as "Alice" file "/local_storage/filetoshare.txt" should exist + But as "Alice" file "/local_storage/newFile.txt" should not exist + Examples: + | ocs_api_version | pending_share_path | + | 1 | /filetoshare.txt | + | 2 | /filetoshare.txt | + \ No newline at end of file diff --git a/tests/acceptance/features/coreApiShareManagementToShares/moveShareInsideAnotherShare.feature b/tests/acceptance/features/coreApiShareManagementToShares/moveShareInsideAnotherShare.feature new file mode 100644 index 00000000000..1a9528e3b63 --- /dev/null +++ b/tests/acceptance/features/coreApiShareManagementToShares/moveShareInsideAnotherShare.feature @@ -0,0 +1,107 @@ +@api @files_sharing-app-required +Feature: moving a share inside another share + As a user + I want to move a shared resource inside another shared resource + Because I need full flexibility when managing resources. + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "folderA" + And user "Alice" has created folder "folderB" + And user "Alice" has uploaded file with content "text A" to "/folderA/fileA.txt" + And user "Alice" has uploaded file with content "text B" to "/folderB/fileB.txt" + And user "Alice" has shared folder "folderA" with user "Brian" + And user "Alice" has shared folder "folderB" with user "Brian" + And user "Brian" has accepted share "/folderA" offered by user "Alice" + And user "Brian" has accepted share "/folderB" offered by user "Alice" + + + Scenario: share receiver cannot move a whole share inside another share + When user "Brian" moves folder "Shares/folderB" to "Shares/folderA/folderB" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" folder "/folderB" should exist + And as "Brian" folder "/Shares/folderB" should exist + And as "Alice" file "/folderB/fileB.txt" should exist + And as "Brian" file "/Shares/folderB/fileB.txt" should exist + + + Scenario: share owner moves a whole share inside another share + When user "Alice" moves folder "folderB" to "folderA/folderB" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" folder "/folderB" should not exist + And as "Alice" folder "/folderA/folderB" should exist + And as "Brian" folder "/Shares/folderB" should exist + And as "Alice" file "/folderA/folderB/fileB.txt" should exist + And as "Brian" file "/Shares/folderA/folderB/fileB.txt" should exist + And as "Brian" file "/Shares/folderB/fileB.txt" should exist + + @notToImplementOnOCIS + Scenario: share receiver moves a whole share inside a local folder + Given user "Brian" has created folder "localFolder" + And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" + When user "Brian" moves folder "Shares/folderB" to "localFolder/folderB" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/localFolder/folderB" should exist + And as "Brian" file "/localFolder/folderB/fileB.txt" should exist + And as "Brian" file "/localFolder/localFile.txt" should exist + But as "Brian" file "/Shares/folderB/fileB.txt" should not exist + + @notToImplementOnOCIS + Scenario: share receiver moves a whole share inside a local folder then moves the local folder inside a received share + Given user "Brian" has created folder "localFolder" + And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" + When user "Brian" moves folder "Shares/folderB" to "localFolder/folderB" using the WebDAV API + And user "Brian" moves folder "localFolder" to "Shares/folderA/localFolder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" folder "/folderA/localFolder" should exist + And as "Brian" folder "/Shares/folderA/localFolder" should exist + And as "Alice" file "/folderA/localFolder/localFile.txt" should exist + And as "Brian" file "/Shares/folderA/localFolder/localFile.txt" should exist + # folderB now exists separately, and is no longer inside localFolder + And as "Alice" file "/folderB/fileB.txt" should exist + And as "Brian" file "/Shares/folderB/fileB.txt" should exist + But as "Alice" folder "/folderA/localFolder/folderB" should not exist + And as "Brian" folder "/Shares/folderA/localFolder/folderB" should not exist + + @notToImplementOnOCIS + Scenario: share receiver moves a whole share inside a local folder then tries to move the share inside a received share + Given user "Brian" has created folder "localFolder" + And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" + When user "Brian" moves folder "Shares/folderB" to "localFolder/folderB" using the WebDAV API + And user "Brian" moves folder "localFolder/folderB" to "Shares/folderA/folderB" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 403" respectively + And as "Alice" file "/folderB/fileB.txt" should exist + And as "Brian" folder "/localFolder/folderB" should exist + And as "Brian" file "/localFolder/folderB/fileB.txt" should exist + But as "Alice" folder "/folderA/folderB" should not exist + And as "Brian" folder "/Shares/folderA/folderB" should not exist + + + Scenario: share receiver moves a local folder inside a received share (local folder does not have a share in it) + Given user "Brian" has created folder "localFolder" + And user "Brian" has created folder "localFolder/subFolder" + And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" + When user "Brian" moves folder "localFolder" to "Shares/folderA/localFolder" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" folder "/folderA/localFolder" should exist + And as "Brian" folder "/Shares/folderA/localFolder" should exist + And as "Alice" folder "/folderA/localFolder/subFolder" should exist + And as "Brian" folder "/Shares/folderA/localFolder/subFolder" should exist + And as "Alice" file "/folderA/localFolder/localFile.txt" should exist + And as "Brian" file "/Shares/folderA/localFolder/localFile.txt" should exist + + @skipOnOcV10 + Scenario: share receiver tries to move a whole share inside a local folder + Given user "Brian" has created folder "localFolder" + And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" + # On oCIS you cannot move received shares out of the "Shares" folder + When user "Brian" moves folder "Shares/folderB" to "localFolder/folderB" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/folderB/fileB.txt" should exist + And as "Brian" file "/Shares/folderB/fileB.txt" should exist diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/accessToShare.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/accessToShare.feature new file mode 100644 index 00000000000..240214d9bbd --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot1/accessToShare.feature @@ -0,0 +1,108 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Brian" has uploaded file with content "some data" to "/textfile0.txt" + + @smokeTest + Scenario Outline: Sharee can see the share + Given using OCS API version "" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + When user "Brian" gets all the shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share_id should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: Sharee can see the filtered share + Given using OCS API version "" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Brian" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has shared file "textfile1.txt" with user "Brian" + When user "Brian" gets all the shares shared with him that are received as file "textfile1 (2).txt" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share_id should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: Sharee can't see the share that is filtered out + Given using OCS API version "" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Brian" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has shared file "textfile1.txt" with user "Brian" + When user "Brian" gets all the shares shared with him that are received as file "textfile0 (2).txt" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share id should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: Sharee can see the group share + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + When user "Brian" gets all the shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share_id should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user should not be able to access a pending share (file) + Given using OCS API version "" + And auto-accept shares has been disabled + And user "Alice" has uploaded file with content "test data" to "/textfile1.txt" + When user "Alice" shares file "/textfile1.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" file "textfile1.txt" should not exist + And the sharing API should report to user "Brian" that these shares are in the pending state + | path | + | /textfile1.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user should not be able to access a pending share (folder) + Given using OCS API version "" + And auto-accept shares has been disabled + And user "Alice" has created folder "simple-folder" + And user "Alice" has created folder "simple-folder/sub" + And user "Alice" has uploaded file with content "test data" to "/simple-folder/textfile1.txt" + When user "Alice" shares file "/simple-folder" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" folder "simple-folder/" should not exist + And as "Brian" folder "simple-folder/sub" should not exist + And as "Brian" file "simple-folder/textfile1.txt" should not exist + And the sharing API should report to user "Brian" that these shares are in the pending state + | path | + | /simple-folder | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/changingFilesShare.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/changingFilesShare.feature new file mode 100644 index 00000000000..bc7779badb2 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot1/changingFilesShare.feature @@ -0,0 +1,111 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + + @smokeTest + Scenario Outline: moving a file into a share as recipient + Given using DAV path + And user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + When user "Brian" moves file "/textfile0.txt" to "/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/shared/shared_file.txt" should exist + And as "Alice" file "/shared/shared_file.txt" should exist + Examples: + | dav-path-version | + | old | + | new | + + @smokeTest @files_trashbin-app-required + Scenario Outline: moving a file out of a share as recipient creates a backup for the owner + Given using DAV path + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared file "/shared" with user "Brian" + And user "Brian" has moved folder "/shared" to "/shared_renamed" + When user "Brian" moves file "/shared_renamed/shared_file.txt" to "/taken_out.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/taken_out.txt" should exist + And as "Alice" file "/shared/shared_file.txt" should not exist + And as "Alice" file "/shared_file.txt" should exist in the trashbin + Examples: + | dav-path-version | + | old | + | new | + + @files_trashbin-app-required + Scenario Outline: moving a folder out of a share as recipient creates a backup for the owner + Given using DAV path + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/sub" + And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" + And user "Alice" has shared file "/shared" with user "Brian" + And user "Brian" has moved folder "/shared" to "/shared_renamed" + When user "Brian" moves folder "/shared_renamed/sub" to "/taken_out" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/taken_out" should exist + And as "Alice" folder "/shared/sub" should not exist + And as "Alice" folder "/sub" should exist in the trashbin + And as "Alice" file "/sub/shared_file.txt" should exist in the trashbin + Examples: + | dav-path-version | + | old | + | new | + + + Scenario: Move files between shares by same user + Given user "Alice" has created folder "share1" + And user "Alice" has created folder "share2" + And user "Alice" has moved file "textfile0.txt" to "share1/shared_file.txt" + And user "Alice" has shared folder "/share1" with user "Brian" + And user "Alice" has shared folder "/share2" with user "Brian" + When user "Brian" moves file "share1/shared_file.txt" to "share2/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "share1/shared_file.txt" should not exist + But as "Brian" file "share2/shared_file.txt" should exist + And as "Alice" file "share1/shared_file.txt" should not exist + But as "Alice" file "share2/shared_file.txt" should exist + + + Scenario: Move files between shares by same user added by sharee + Given user "Alice" has created folder "share1" + And user "Alice" has created folder "share2" + And user "Alice" has shared folder "/share1" with user "Brian" + And user "Alice" has shared folder "/share2" with user "Brian" + And user "Alice" has moved file "/textfile0.txt" to "share1/shared_file.txt" + When user "Brian" moves file "share1/shared_file.txt" to "share2/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "share2/shared_file.txt" should exist + And as "Alice" file "share2/shared_file.txt" should exist + + + Scenario: Move files between shares by different users + Given user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT" + And user "Carol" has created folder "/PARENT" + And user "Alice" has moved file "textfile0.txt" to "PARENT/shared_file.txt" + And user "Alice" has shared folder "/PARENT" with user "Carol" + And user "Brian" has shared folder "/PARENT" with user "Carol" + When user "Carol" moves file "PARENT (2)/shared_file.txt" to "PARENT (3)/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Carol" file "PARENT (3)/shared_file.txt" should exist + And as "Brian" file "PARENT/shared_file.txt" should exist + But as "Alice" file "PARENT/shared_file.txt" should not exist + + + Scenario: overwrite a received file share + Given user "Alice" has uploaded file with content "this is the old content" to "/textfile1.txt" + And user "Alice" has shared file "/textfile1.txt" with user "Brian" + When user "Brian" uploads file with content "this is a new content" to "/textfile1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" file "/textfile1.txt" should exist + And the content of file "/textfile1.txt" for user "Brian" should be "this is a new content" + And the content of file "/textfile1.txt" for user "Alice" should be "this is a new content" diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingShares.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingShares.feature new file mode 100644 index 00000000000..0256b0aae3e --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingShares.feature @@ -0,0 +1,151 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + + @smokeTest + Scenario Outline: getting all shares of a user using that user + Given using OCS API version "" + And user "Alice" has moved file "/textfile0.txt" to "/file_to_share.txt" + And user "Alice" has shared file "file_to_share.txt" with user "Brian" + When user "Alice" gets all shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And file "file_to_share.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting all shares of a user using another user + Given using OCS API version "" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + When the administrator gets all shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And file "textfile0.txt" should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: getting all shares of a file + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Carol | + | David | + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has shared file "textfile0.txt" with user "Carol" + When user "Alice" gets all the shares from the file "textfile0.txt" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be included in the response + And user "Carol" should be included in the response + And user "David" should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: getting all shares of a file with reshares + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Carol | + | David | + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has shared file "textfile0.txt" with user "Carol" + When user "Alice" gets all the shares with reshares from the file "textfile0.txt" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be included in the response + And user "Carol" should be included in the response + And user "David" should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: User's own shares reshared to him don't appear when getting "shared with me" shares + Given using OCS API version "" + And group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has been added to group "grp1" + And user "Carol" has created folder "/shared" + And user "Carol" has uploaded file "/filesForUpload/textfile.txt" to "/shared/shared_file.txt" + And user "Carol" has shared folder "/shared" with user "Brian" + And user "Brian" has shared folder "/shared" with group "grp1" + When user "Carol" gets all the shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share id should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-374 + Scenario Outline: Get a share with a user that didn't receive the share + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has uploaded file "/filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + When user "Carol" gets the info of the last share using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @skipOnLDAP + Scenario Outline: Share of folder to a group, remove user from that group + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And group "group0" has been created + And user "Brian" has been added to group "group0" + And user "Carol" has been added to group "group0" + And user "Alice" has created folder "/PARENT" + And user "Alice" has moved file "textfile0.txt" to "PARENT/parent.txt" + And user "Alice" has shared folder "/PARENT" with group "group0" + When the administrator removes user "Carol" from group "group0" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /PARENT/ | + | /PARENT/parent.txt | + And user "Carol" should see the following elements + | textfile0.txt | + But user "Carol" should not see the following elements + | /PARENT/ | + | /PARENT/parent.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting all the shares inside the folder + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has moved file "textfile0.txt" to "PARENT/parent.txt" + And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" + When user "Alice" gets all the shares inside the folder "PARENT" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And file "parent.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFiltered.feature new file mode 100644 index 00000000000..a9989a316f8 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFiltered.feature @@ -0,0 +1,57 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: get the received shares filtered by type (user, group etc) + As a user + I want to be able to know the shares that I have received of a particular type (user, group etc) + So that I can reduce the amount of data that has to be transferred to be just the data that I need + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/folderToShareWithUser" + And user "Alice" has created folder "/folderToShareWithGroup" + And user "Alice" has created folder "/folderToShareWithPublic" + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" + And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" + And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + + + Scenario Outline: getting shares received from users + Given using OCS API version "" + When user "Brian" gets the user shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "folderToShareWithUser" should be included in the response + And file "fileToShareWithUser.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares received from groups + Given using OCS API version "" + When user "Brian" gets the group shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "folderToShareWithGroup" should be included in the response + And folder "fileToShareWithGroup.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFilteredEmpty.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFilteredEmpty.feature new file mode 100644 index 00000000000..b0d8bfd18f9 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesReceivedFilteredEmpty.feature @@ -0,0 +1,84 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: get the received shares filtered by type (user, group etc) + As a user + I want to be able to know the shares that I have received of a particular type (user, group etc) + So that I can reduce the amount of data that has to be transferred to be just the data that I need + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/folderToShareWithUser" + And user "Alice" has created folder "/folderToShareWithGroup" + And user "Alice" has created folder "/folderToShareWithPublic" + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" + And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" + And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" + + + Scenario Outline: getting shares received from users when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Brian" gets the user shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares received from groups when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Brian" gets the group shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares received from public links when there are none + # Note: public links are purposely created in this scenario + # users do not receive public links, so asking for a list of public links + # that are "shared with me" should always return an empty list. + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Brian" gets the public link shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFiltered.feature new file mode 100644 index 00000000000..d066eb58f7a --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFiltered.feature @@ -0,0 +1,87 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: get shares filtered by type (user, group etc) + As a user + I want to be able to know the shares that I have made of a particular type (user, group etc) + So that I can reduce the amount of data that has to be transferred to be just the data that I need + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/folderToShareWithUser" + And user "Alice" has created folder "/folderToShareWithGroup" + And user "Alice" has created folder "/folderToShareWithPublic" + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" + And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" + And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + + + Scenario Outline: getting shares shared to users + Given using OCS API version "" + When user "Alice" gets the user shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "folderToShareWithUser" should be included in the response + And file "fileToShareWithUser.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to groups + Given using OCS API version "" + When user "Alice" gets the group shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "folderToShareWithGroup" should be included in the response + And folder "fileToShareWithGroup.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to public links + Given using OCS API version "" + When user "Alice" gets the public link shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "folderToShareWithPublic" should be included in the response + And folder "fileToShareWithPublic.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to users and groups + Given using OCS API version "" + When user "Alice" gets the user and group shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 4 files or folders should be included in the response + And folder "folderToShareWithUser" should be included in the response + And file "fileToShareWithUser.txt" should be included in the response + And folder "folderToShareWithGroup" should be included in the response + And folder "fileToShareWithGroup.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFilteredEmpty.feature b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFilteredEmpty.feature new file mode 100644 index 00000000000..dab91cdec55 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot1/gettingSharesSharedFilteredEmpty.feature @@ -0,0 +1,75 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: get shares filtered by type (user, group etc) + As a user + I want to be able to know the shares that I have made of a particular type (user, group etc) + So that I can reduce the amount of data that has to be transferred to be just the data that I need + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/folderToShareWithUser" + And user "Alice" has created folder "/folderToShareWithGroup" + And user "Alice" has created folder "/folderToShareWithPublic" + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" + And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" + And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" + + + Scenario Outline: getting shares shared to users when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Alice" gets the user shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to groups when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Alice" gets the group shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to public links when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + When user "Alice" gets the public link shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot2/getWebDAVSharePermissions.feature b/tests/acceptance/features/coreApiShareOperationsToRoot2/getWebDAVSharePermissions.feature new file mode 100644 index 00000000000..693c988e037 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot2/getWebDAVSharePermissions.feature @@ -0,0 +1,319 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario Outline: Correct webdav share-permissions for owned file + Given using DAV path + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + When user "Alice" gets the following properties of file "/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "201" + And the single response should contain a property "ocs:share-permissions" with value "19" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received file with edit and reshare permissions + Given using DAV path + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has shared file "/tmp.txt" with user "Brian" + When user "Brian" gets the following properties of file "/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "19" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared file with edit and reshare permissions + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has created a share with settings + | path | /tmp.txt | + | shareType | group | + | permissions | share,update,read | + | shareWith | grp1 | + When user "Brian" gets the following properties of file "/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "19" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received file with edit permissions but no reshare permissions + Given using DAV path + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has shared file "tmp.txt" with user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | update,read | + Then the HTTP status code should be "200" + And as user "Brian" file "/tmp.txt" should contain a property "ocs:share-permissions" with value "3" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared file with edit permissions but no reshare permissions + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has created a share with settings + | path | /tmp.txt | + | shareType | group | + | permissions | update,read | + | shareWith | grp1 | + When user "Brian" gets the following properties of file "/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "3" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received file with reshare permissions but no edit permissions + Given using DAV path + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has shared file "tmp.txt" with user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | share,read | + Then the HTTP status code should be "200" + And as user "Brian" file "/tmp.txt" should contain a property "ocs:share-permissions" with value "17" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared file with reshare permissions but no edit permissions + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has created a share with settings + | path | /tmp.txt | + | shareType | group | + | permissions | share,read | + | shareWith | grp1 | + When user "Brian" gets the following properties of file "/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "17" + Examples: + | dav-path | + | old | + | new | + + + + Scenario Outline: Correct webdav share-permissions for owned folder + Given using DAV path + And user "Alice" has created folder "/tmp" + When user "Alice" gets the following properties of folder "/" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "201" + And the single response should contain a property "ocs:share-permissions" with value "31" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received folder with all permissions + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "31" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "31" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received folder with all permissions but edit + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | share,delete,create,read | + Then the HTTP status code should be "200" + And as user "Brian" folder "/tmp" should contain a property "ocs:share-permissions" with value "29" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but edit + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + | permissions | share,delete,create,read | + When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "29" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received folder with all permissions but create + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | share,delete,update,read | + Then the HTTP status code should be "200" + And as user "Brian" folder "/tmp" should contain a property "ocs:share-permissions" with value "27" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but create + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + | permissions | share,delete,update,read | + When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "27" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received folder with all permissions but delete + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the HTTP status code should be "200" + And as user "Brian" folder "/tmp" should contain a property "ocs:share-permissions" with value "23" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but delete + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + | permissions | share,create,update,read | + When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "23" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received folder with all permissions but share + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | change | + Then the HTTP status code should be "200" + And as user "Brian" folder "/tmp" should contain a property "ocs:share-permissions" with value "15" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but share + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + | permissions | change | + When user "Brian" gets the following properties of folder "/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "15" + Examples: + | dav-path | + | old | + | new | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot2/shareAccessByID.feature b/tests/acceptance/features/coreApiShareOperationsToRoot2/shareAccessByID.feature new file mode 100644 index 00000000000..c128edf8e1c --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot2/shareAccessByID.feature @@ -0,0 +1,71 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: share access by ID + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: Get a share with a valid share ID + Given using OCS API version "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + And user "Alice" gets share with id "%last_share_id%" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /textfile0.txt | + | path | /textfile0.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: accept a share using the share Id + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And using OCS API version "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + And user "Brian" accepts share with ID "%last_share_id%" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /textfile0.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: decline a share using the share Id + Given using OCS API version "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + And user "Brian" declines share with ID "%last_share_id%" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should not see the following elements + | /textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | /textfile0.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToRoot2/uploadToShare.feature b/tests/acceptance/features/coreApiShareOperationsToRoot2/uploadToShare.feature new file mode 100644 index 00000000000..6204a0ca6a7 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToRoot2/uploadToShare.feature @@ -0,0 +1,248 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + + + Scenario: Uploading file to a user read-only share folder does not work + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | read | + | shareWith | Brian | + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/FOLDER/textfile.txt" should not exist + + + Scenario Outline: Uploading file to a group read-only share folder does not work + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | read | + | shareWith | grp1 | + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/FOLDER/textfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading file to a user upload-only share folder works + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | create | + | shareWith | Brian | + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Brian" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading file to a group upload-only share folder works + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | create | + | shareWith | grp1 | + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Brian" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + @smokeTest + Scenario Outline: Uploading file to a user read/write share folder works + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | change | + | shareWith | Brian | + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading file to a group read/write share folder works + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + @smokeTest @skipOnGraph + Scenario Outline: Check quota of owners parent directory of a shared file + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "0" + And user "Alice" has uploaded file with content "some data" to "myfile.txt" + And user "Alice" has shared file "myfile.txt" with user "Brian" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/myfile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the following headers should match these regular expressions for user "Brian" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/myfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading to a user shared folder with read/write permission when the sharer has unsufficient quota does not work + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | change | + | shareWith | Brian | + And the quota of user "Alice" has been set to "0" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/myfile.txt" using the WebDAV API + Then the HTTP status code should be "507" + And as "Alice" file "/FOLDER/myfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading to a group shared folder with read/write permission when the sharer has unsufficient quota does not work + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + And the quota of user "Alice" has been set to "0" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/myfile.txt" using the WebDAV API + Then the HTTP status code should be "507" + And as "Alice" file "/FOLDER/myfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading to a user shared folder with upload-only permission when the sharer has insufficient quota does not work + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | create | + | shareWith | Brian | + And the quota of user "Alice" has been set to "0" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/myfile.txt" using the WebDAV API + Then the HTTP status code should be "507" + And as "Alice" file "/FOLDER/myfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading to a group shared folder with upload-only permission when the sharer has insufficient quota does not work + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | create | + | shareWith | grp1 | + And the quota of user "Alice" has been set to "0" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "FOLDER/myfile.txt" using the WebDAV API + Then the HTTP status code should be "507" + And as "Alice" file "/FOLDER/myfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + + Scenario: Uploading a file in to a shared folder without edit permissions + Given using new DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/READ_ONLY" + And user "Alice" has created a share with settings + | path | /READ_ONLY | + | shareType | user | + | permissions | read | + | shareWith | Brian | + When user "Brian" uploads the following chunks to "/READ_ONLY/myfile.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | hallo | + | 2 | welt | + Then the HTTP status code should be "403" + And as "Alice" file "/FOLDER/myfile.txt" should not exist diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/accessToShare.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/accessToShare.feature new file mode 100644 index 00000000000..9c3c3163c35 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/accessToShare.feature @@ -0,0 +1,75 @@ +@api @files_sharing-app-required +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + + @smokeTest + Scenario Outline: Sharee can see the share + Given using OCS API version "" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" gets all the shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share_id should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: Sharee can see the filtered share + Given using OCS API version "" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has shared file "textfile1.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Brian" has accepted share "/textfile1.txt" offered by user "Alice" + When user "Brian" gets all the shares shared with him that are received as file "/Shares/textfile1.txt" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share_id should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @issue-ocis-reva-260 + Scenario Outline: Sharee can't see the share that is filtered out + Given using OCS API version "" + And user "Alice" has uploaded file with content "some data" to "/textfile1.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has shared file "textfile1.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Brian" has accepted share "/textfile1.txt" offered by user "Alice" + When user "Brian" gets all the shares shared with him that are received as file "/Shares/textfile0.txt" using the provisioning API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share id should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @issue-ocis-reva-34 @issue-ocis-reva-194 + Scenario Outline: Sharee can see the group share + Given using OCS API version "" + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" gets all the shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share_id should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/accessToSharesFolder.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/accessToSharesFolder.feature new file mode 100644 index 00000000000..a6f4da75122 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/accessToSharesFolder.feature @@ -0,0 +1,119 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: write directly into the folder for received shares + On ownCloud10 with the folder for received shares set, for example, to "Shares" + A user should see a "Shares" folder when they have received a share. + A user should be able to add their own resources into the "Shares" folder + and those resources will act like any resource that is local to the user. + Even if the user has no more received shares, the "Shares" folder is still there. + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario: the Shares folder does not exist before the first share is received + Then as "Alice" folder "/Shares" should not exist + And as "Brian" folder "/Shares" should not exist + + + Scenario: the Shares folder does not exist if no share has been accepted + Given user "Alice" has created folder "/shared" + When user "Alice" shares folder "/shared" with user "Brian" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And as "Brian" folder "/Shares" should not exist + And as "Alice" folder "/Shares" should not exist + + + Scenario: the Shares folder exists for the sharee after a share is accepted + Given user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + When user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And as "Brian" folder "/Shares" should exist + But as "Alice" folder "/Shares" should not exist + + + Scenario: the Shares folder exists after a share is received, accepted and deleted + Given user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + When user "Alice" deletes the last share using the sharing API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And as "Brian" folder "/Shares" should exist + But as "Alice" folder "/Shares" should not exist + + + Scenario: the Shares folder can be created first by the user + Given user "Alice" has created folder "/shared" + When user "Brian" creates folder "/Shares" using the WebDAV API + And user "Brian" creates folder "/Shares/aFolder" using the WebDAV API + And user "Alice" shares folder "/shared" with user "Brian" using the sharing API + And user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API + # OCS status code is available only for the Sharing API request + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on each endpoint should be "201, 201, 200, 200" respectively + And as "Brian" folder "/Shares" should exist + And as "Brian" folder "/Shares/shared" should exist + + + Scenario: the user can have created a matching resource in Shares before receiving a share + Given user "Alice" has created folder "/shared" + And user "Alice" has uploaded file with content "shared data" to "/shared/aFile.txt" + And user "Brian" has created folder "/Shares" + And user "Brian" has created folder "/Shares/shared" + And user "Brian" has uploaded file with content "data of Brian" to "/Shares/shared/aFile.txt" + When user "Alice" shares folder "/shared" with user "Brian" using the sharing API + And user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" folder "/Shares" should exist + And as "Brian" folder "/Shares/shared" should exist + And as "Brian" folder "/Shares/shared (2)" should exist + And the content of file "/Shares/shared/aFile.txt" for user "Brian" should be "data of Brian" + And the content of file "/Shares/shared (2)/aFile.txt" for user "Brian" should be "shared data" + + + Scenario: the user can write directly into the Shares folder + Given user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + When user "Brian" uploads file with content "some data" to "/Shares/textfile.txt" using the WebDAV API + And user "Brian" creates folder "/Shares/aFolder" using the WebDAV API + And user "Brian" uploads file with content "more data" to "/Shares/aFolder/aFile.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And as "Brian" file "/Shares/textfile.txt" should exist + And the content of file "/Shares/textfile.txt" for user "Brian" should be "some data" + And as "Brian" file "/Shares/aFolder/aFile.txt" should exist + And the content of file "Shares/aFolder/aFile.txt" for user "Brian" should be "more data" + + + Scenario: the user can move files directly into the Shares folder + Given user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + And user "Brian" has uploaded file with content "some data" to "/textfile.txt" + When user "Brian" moves file "/textfile.txt" to "/Shares/textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/textfile.txt" should exist + And the content of file "Shares/textfile.txt" for user "Brian" should be "some data" + + + Scenario: the user can delete files that they wrote into the Shares folder + Given user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + And user "Brian" has uploaded file with content "some data" to "/Shares/textfile.txt" + And user "Brian" has created folder "/Shares/aFolder" + When user "Brian" deletes file "/Shares/textfile.txt" using the WebDAV API + And user "Brian" deletes folder "/Shares/aFolder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And as "Brian" folder "/Shares" should exist + But as "Brian" file "/Shares/textfile.txt" should not exist + And as "Brian" folder "/Shares/aFolder" should not exist diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature new file mode 100644 index 00000000000..032f308d657 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature @@ -0,0 +1,149 @@ +@api @files_sharing-app-required @issue-ocis-1289 @issue-ocis-1328 +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario Outline: moving a file into a share as recipient + Given using DAV path + And user "Alice" has created folder "/shared" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + And user "Brian" has uploaded file with content "some data" to "/textfile0.txt" + When user "Brian" moves file "textfile0.txt" to "/Shares/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/shared/shared_file.txt" should exist + And as "Alice" file "/shared/shared_file.txt" should exist + Examples: + | dav_version | + | old | + | new | + + @smokeTest @files_trashbin-app-required @notToImplementOnOCIS + Scenario Outline: moving a file out of a share as recipient creates a backup for the owner + Given using DAV path + And user "Alice" has created folder "/shared" + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared file "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + And user "Brian" has moved folder "/Shares/shared" to "/shared_renamed" + When user "Brian" moves file "/shared_renamed/shared_file.txt" to "/taken_out.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/taken_out.txt" should exist + And as "Alice" file "/shared/shared_file.txt" should not exist + And as "Alice" file "/shared_file.txt" should exist in the trashbin + Examples: + | dav_version | + | old | + | new | + + @files_trashbin-app-required @notToImplementOnOCIS + Scenario Outline: moving a folder out of a share as recipient creates a backup for the owner + Given using DAV path + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/sub" + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" + And user "Alice" has shared file "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + And user "Brian" has moved folder "/Shares/shared" to "/shared_renamed" + When user "Brian" moves folder "/shared_renamed/sub" to "/taken_out" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/taken_out" should exist + And as "Alice" folder "/shared/sub" should not exist + And as "Alice" folder "/sub" should exist in the trashbin + And as "Alice" file "/sub/shared_file.txt" should exist in the trashbin + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Move files between shares by same user + Given using DAV path + And user "Alice" has created folder "share1" + And user "Alice" has created folder "share2" + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has moved file "textfile0.txt" to "share1/textfile0.txt" + And user "Alice" has shared folder "/share1" with user "Brian" + And user "Alice" has shared folder "/share2" with user "Brian" + And user "Brian" has accepted share "/share1" offered by user "Alice" + And user "Brian" has accepted share "/share2" offered by user "Alice" + When user "Brian" moves file "/Shares/share1/textfile0.txt" to "/Shares/share2/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/share1/textfile0.txt" should not exist + But as "Brian" file "/Shares/share2/textfile0.txt" should exist + And as "Alice" file "share1/textfile0.txt" should not exist + But as "Alice" file "share2/textfile0.txt" should exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Move files between shares by same user added by sharee + Given using DAV path + And user "Alice" has created folder "share1" + And user "Alice" has created folder "share2" + And user "Brian" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has shared folder "/share1" with user "Brian" + And user "Alice" has shared folder "/share2" with user "Brian" + And user "Brian" has accepted share "/share1" offered by user "Alice" + And user "Brian" has accepted share "/share2" offered by user "Alice" + When user "Brian" moves file "textfile0.txt" to "/Shares/share1/shared_file.txt" using the WebDAV API + And user "Brian" moves file "/Shares/share1/shared_file.txt" to "/Shares/share2/shared_file.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And as "Brian" file "/Shares/share1/shared_file.txt" should not exist + And as "Alice" file "share1/shared_file.txt" should not exist + But as "Brian" file "/Shares/share2/shared_file.txt" should exist + And as "Alice" file "share2/shared_file.txt" should exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Move files between shares by different users + Given using DAV path + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has created folder "/PARENT" + And user "Brian" has created folder "/PARENT" + And user "Alice" has moved file "textfile0.txt" to "PARENT/shared_file.txt" + And user "Alice" has shared folder "/PARENT" with user "Carol" + And user "Brian" has shared folder "/PARENT" with user "Carol" + And user "Carol" has accepted share "/PARENT" offered by user "Alice" + And user "Carol" has accepted share "/PARENT" offered by user "Brian" + When user "Carol" moves file "/Shares/PARENT/shared_file.txt" to "/Shares/PARENT (2)/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Carol" file "/Shares/PARENT (2)/shared_file.txt" should exist + And as "Brian" file "PARENT/shared_file.txt" should exist + But as "Alice" file "PARENT/shared_file.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: overwrite a received file share + Given using DAV path + And user "Alice" has uploaded file with content "this is the old content" to "/textfile1.txt" + And user "Alice" has shared file "/textfile1.txt" with user "Brian" + And user "Brian" has accepted share "/textfile1.txt" offered by user "Alice" + When user "Brian" uploads file with content "this is a new content" to "/Shares/textfile1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" file "Shares/textfile1.txt" should exist + And the content of file "Shares/textfile1.txt" for user "Brian" should be "this is a new content" + And the content of file "textfile1.txt" for user "Alice" should be "this is a new content" + Examples: + | dav_version | + | old | + | new | + diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature new file mode 100644 index 00000000000..0018e5b2776 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature @@ -0,0 +1,222 @@ +@api @files_sharing-app-required +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest @issue-ocis-reva-262 + Scenario Outline: getting all shares of a user using that user + Given using OCS API version "" + And user "Alice" has uploaded file with content "some data" to "/file_to_share.txt" + And user "Alice" has shared file "file_to_share.txt" with user "Brian" + And user "Brian" has accepted share "/file_to_share.txt" offered by user "Alice" + When user "Alice" gets all shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And file "/Shares/file_to_share.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-65 + Scenario Outline: getting all shares of a user using another user + Given using OCS API version "" + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When the administrator gets all shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And file "/Shares/textfile0.txt" should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: getting all shares of a file + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Carol | + | David | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has shared file "textfile0.txt" with user "Carol" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Carol" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Alice" gets all the shares from the file "textfile0.txt" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be included in the response + And user "Carol" should be included in the response + And user "David" should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: getting all shares of a file with reshares + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Carol | + | David | + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Brian" has shared file "/Shares/textfile0.txt" with user "Carol" + And user "Carol" has accepted share "/textfile0.txt" offered by user "Brian" + When user "Alice" gets all the shares with reshares from the file "textfile0.txt" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be included in the response + And user "Carol" should be included in the response + And user "David" should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest + Scenario Outline: User's own shares reshared to him don't appear when getting "shared with me" shares + Given using OCS API version "" + And group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Carol" has been added to group "grp1" + And user "Carol" has created folder "/shared" + And user "Carol" has uploaded file with content "some data" to "/shared/shared_file.txt" + And user "Carol" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Carol" + And user "Brian" has shared folder "/Shares/shared" with group "grp1" + # no need to accept this share as it is Carol's file + When user "Carol" gets all the shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the last share id should not be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @toFixOnOCIS @issue-ocis-reva-357 @issue-ocis-reva-301 @issue-ocis-reva-302 + #after fixing all the issues merge this scenario with the one below + Scenario Outline: getting share info of a share + Given using OCS API version "" + And user "Alice" has uploaded file with content "some data" to "/file_to_share.txt" + And user "Alice" has shared file "file_to_share.txt" with user "Brian" + And user "Brian" has accepted share "/file_to_share.txt" offered by user "Alice" + When user "Alice" gets the info of the last share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | user | + | share_with | %username% | + | file_source | A_STRING | + | file_target | /Shares/file_to_share.txt | + | path | /file_to_share.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | share_with_displayname | %displayname% | + | displayname_owner | %displayname% | + | mimetype | text/plain | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @toFixOnOCIS @issue-ocis-reva-357 @issue-ocis-reva-301 @issue-ocis-reva-302 + #after fixing all the issues merge this scenario with the one above + Scenario Outline: getting share info of a share (Bug demonstration for ocis) + Given using OCS API version "" + And user "Alice" has uploaded file with content "some data" to "/file_to_share.txt" + And user "Alice" has shared file "file_to_share.txt" with user "Brian" + And user "Brian" has accepted share "/file_to_share.txt" offered by user "Alice" + When user "Alice" gets the info of the last share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | user | + | share_with | %username% | + | file_source | A_STRING | + | file_target | /Shares/file_to_share.txt | + | path | /file_to_share.txt | + | permissions | share,read,update | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | +# | share_with_displayname | %displayname% | +# | displayname_owner | %displayname% | +# | mimetype | text/plain | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-374 + Scenario Outline: Get a share with a user that didn't receive the share + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + When user "Carol" gets the info of the last share using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @skipOnLDAP @issue-ocis-reva-194 @skipOnGraph + Scenario: Share of folder to a group, remove user from that group + Given using OCS API version "1" + And user "Carol" has been created with default attributes and without skeleton files + And group "group0" has been created + And user "Brian" has been added to group "group0" + And user "Carol" has been added to group "group0" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + And user "Alice" has shared folder "/PARENT" with group "group0" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Carol" has accepted share "/PARENT" offered by user "Alice" + When the administrator removes user "Carol" from group "group0" using the provisioning API + Then the HTTP status code should be "200" + And user "Brian" should see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + But user "Carol" should not see the following elements + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + + @issue-ocis-reva-372 + Scenario Outline: getting all the shares inside the folder + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" + And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" + And user "Brian" has accepted share "" offered by user "Alice" + When user "Alice" gets all the shares inside the folder "PARENT" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And file "/Shares/parent.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | pending_share_path | + | 1 | 100 | /parent.txt | + | 2 | 200 | /parent.txt | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesPendingFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesPendingFiltered.feature new file mode 100644 index 00000000000..3181330c3f8 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesPendingFiltered.feature @@ -0,0 +1,59 @@ +@api @files_sharing-app-required +Feature: get the pending shares filtered by type (user, group etc) + As a user + I want to be able to know the pending shares that I have received of a particular type (user, group etc) + So that I can reduce the amount of data that has to be transferred to be just the data that I need + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/folderToShareWithUser" + And user "Alice" has created folder "/folderToShareWithGroup" + And user "Alice" has created folder "/folderToShareWithPublic" + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" + And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" + And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Brian" has accepted share "/fileToShareWithUser.txt" offered by user "Alice" + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Brian" has accepted share "/fileToShareWithGroup.txt" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + + + Scenario Outline: getting pending shares received from users + Given using OCS API version "" + When user "Brian" gets the pending user shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 1 file or folder should be included in the response + And folder "/Shares/folderToShareWithUser" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting pending shares received from groups + Given using OCS API version "" + When user "Brian" gets the pending group shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 1 file or folder should be included in the response + And folder "/Shares/folderToShareWithGroup" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFiltered.feature new file mode 100644 index 00000000000..ed35bfb1de7 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFiltered.feature @@ -0,0 +1,63 @@ +@api @files_sharing-app-required +Feature: get the received shares filtered by type (user, group etc) + As a user + I want to be able to know the shares that I have received of a particular type (user, group etc) + So that I can reduce the amount of data that has to be transferred to be just the data that I need + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/folderToShareWithUser" + And user "Alice" has created folder "/folderToShareWithGroup" + And user "Alice" has created folder "/folderToShareWithPublic" + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" + And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" + And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Brian" has accepted share "/folderToShareWithUser" offered by user "Alice" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Brian" has accepted share "/folderToShareWithGroup" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Brian" has accepted share "/fileToShareWithUser.txt" offered by user "Alice" + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Brian" has accepted share "/fileToShareWithGroup.txt" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + + + Scenario Outline: getting shares received from users + Given using OCS API version "" + When user "Brian" gets the user shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "/Shares/folderToShareWithUser" should be included in the response + And file "/Shares/fileToShareWithUser.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares received from groups + Given using OCS API version "" + When user "Brian" gets the group shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "/Shares/folderToShareWithGroup" should be included in the response + And folder "/Shares/fileToShareWithGroup.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFilteredEmpty.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFilteredEmpty.feature new file mode 100644 index 00000000000..e1cae806dc5 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFilteredEmpty.feature @@ -0,0 +1,94 @@ +@api @files_sharing-app-required +Feature: get the received shares filtered by type (user, group etc) + As a user + I want to be able to know the shares that I have received of a particular type (user, group etc) + So that I can reduce the amount of data that has to be transferred to be just the data that I need + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/folderToShareWithUser" + And user "Alice" has created folder "/folderToShareWithGroup" + And user "Alice" has created folder "/folderToShareWithPublic" + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" + And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" + And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" + + + Scenario Outline: getting shares received from users when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Brian" has accepted share "/folderToShareWithGroup" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Brian" has accepted share "/fileToShareWithGroup.txt" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Brian" gets the user shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares received from groups when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Brian" has accepted share "/folderToShareWithUser" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Brian" has accepted share "/fileToShareWithUser.txt" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Brian" gets the group shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares received from public links when there are none + # Note: public links are purposely created in this scenario + # users do not receive public links, so asking for a list of public links + # that are "shared with me" should always return an empty list. + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Brian" has accepted share "/folderToShareWithUser" offered by user "Alice" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Brian" has accepted share "/folderToShareWithGroup" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Brian" has accepted share "/fileToShareWithUser.txt" offered by user "Alice" + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Brian" has accepted share "/fileToShareWithGroup.txt" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Brian" gets the public link shares shared with him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFiltered.feature new file mode 100644 index 00000000000..9cc3c336cda --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFiltered.feature @@ -0,0 +1,93 @@ +@api @files_sharing-app-required +Feature: get shares filtered by type (user, group etc) + As a user + I want to be able to know the shares that I have made of a particular type (user, group etc) + So that I can reduce the amount of data that has to be transferred to be just the data that I need + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/folderToShareWithUser" + And user "Alice" has created folder "/folderToShareWithGroup" + And user "Alice" has created folder "/folderToShareWithPublic" + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" + And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" + And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Brian" has accepted share "/folderToShareWithUser" offered by user "Alice" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Brian" has accepted share "/folderToShareWithGroup" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Brian" has accepted share "/fileToShareWithUser.txt" offered by user "Alice" + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Brian" has accepted share "/fileToShareWithGroup.txt" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + + + Scenario Outline: getting shares shared to users + Given using OCS API version "" + When user "Alice" gets the user shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "/Shares/folderToShareWithUser" should be included in the response + And file "/Shares/fileToShareWithUser.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to groups + Given using OCS API version "" + When user "Alice" gets the group shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "/Shares/folderToShareWithGroup" should be included in the response + And folder "/Shares/fileToShareWithGroup.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to public links + Given using OCS API version "" + When user "Alice" gets the public link shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 2 files or folders should be included in the response + And folder "/folderToShareWithPublic" should be included in the response + And folder "/fileToShareWithPublic.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to users and groups + Given using OCS API version "" + When user "Alice" gets the user and group shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And exactly 4 files or folders should be included in the response + And folder "/Shares/folderToShareWithUser" should be included in the response + And file "/Shares/fileToShareWithUser.txt" should be included in the response + And folder "/Shares/folderToShareWithGroup" should be included in the response + And folder "/Shares/fileToShareWithGroup.txt" should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFilteredEmpty.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFilteredEmpty.feature new file mode 100644 index 00000000000..9baa881e47f --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFilteredEmpty.feature @@ -0,0 +1,83 @@ +@api @files_sharing-app-required +Feature: get shares filtered by type (user, group etc) + As a user + I want to be able to know the shares that I have made of a particular type (user, group etc) + So that I can reduce the amount of data that has to be transferred to be just the data that I need + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/folderToShareWithUser" + And user "Alice" has created folder "/folderToShareWithGroup" + And user "Alice" has created folder "/folderToShareWithPublic" + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShareWithUser.txt" + And user "Alice" has uploaded file with content "file to share with group" to "/fileToShareWithGroup.txt" + And user "Alice" has uploaded file with content "file to share with public" to "/fileToShareWithPublic.txt" + + + Scenario Outline: getting shares shared to users when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Brian" has accepted share "/folderToShareWithGroup" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Brian" has accepted share "/fileToShareWithGroup.txt" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Alice" gets the user shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to groups when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Brian" has accepted share "/folderToShareWithUser" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /folderToShareWithPublic | + | permissions | read | + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Brian" has accepted share "/fileToShareWithUser.txt" offered by user "Alice" + And user "Alice" has created a public link share with settings + | path | /fileToShareWithPublic.txt | + | permissions | read | + When user "Alice" gets the group shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: getting shares shared to public links when there are none + Given using OCS API version "" + And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian" + And user "Brian" has accepted share "/folderToShareWithUser" offered by user "Alice" + And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1" + And user "Brian" has accepted share "/folderToShareWithGroup" offered by user "Alice" + And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian" + And user "Brian" has accepted share "/fileToShareWithUser.txt" offered by user "Alice" + And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1" + And user "Brian" has accepted share "/fileToShareWithGroup.txt" offered by user "Alice" + When user "Alice" gets the public link shares shared by him using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And no files or folders should be included in the response + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares2/getWebDAVSharePermissions.feature b/tests/acceptance/features/coreApiShareOperationsToShares2/getWebDAVSharePermissions.feature new file mode 100644 index 00000000000..559f62dca8e --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares2/getWebDAVSharePermissions.feature @@ -0,0 +1,346 @@ +@api @files_sharing-app-required +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario Outline: Correct webdav share-permissions for owned file + Given using DAV path + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + When user "Alice" gets the following properties of file "/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "201" + And the single response should contain a property "ocs:share-permissions" with value "19" + Examples: + | dav-path | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: Correct webdav share-permissions for received file with edit and reshare permissions + Given using DAV path + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has shared file "/tmp.txt" with user "Brian" + And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" + When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "19" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared file with edit and reshare permissions + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has created a share with settings + | path | /tmp.txt | + | shareType | group | + | permissions | share,update,read | + | shareWith | grp1 | + And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" + When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "19" + Examples: + | dav-path | + | old | + | new | + + @issue-ocis-2213 + Scenario Outline: Correct webdav share-permissions for received file with edit permissions but no reshare permissions + Given using DAV path + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has shared file "tmp.txt" with user "Brian" + And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | update,read | + Then the HTTP status code should be "200" + And as user "Brian" file "/Shares/tmp.txt" should contain a property "ocs:share-permissions" with value "3" + Examples: + | dav-path | + | old | + | new | + + @issue-ocis-2213 + Scenario Outline: Correct webdav share-permissions for received group shared file with edit permissions but no reshare permissions + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has created a share with settings + | path | /tmp.txt | + | shareType | group | + | permissions | update,read | + | shareWith | grp1 | + And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" + When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "3" + Examples: + | dav-path | + | old | + | new | + + @issue-ocis-2213 + Scenario Outline: Correct webdav share-permissions for received file with reshare permissions but no edit permissions + Given using DAV path + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has shared file "tmp.txt" with user "Brian" + And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | share,read | + Then the HTTP status code should be "200" + And as user "Brian" file "/Shares/tmp.txt" should contain a property "ocs:share-permissions" with value "17" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared file with reshare permissions but no edit permissions + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "foo" to "/tmp.txt" + And user "Alice" has created a share with settings + | path | /tmp.txt | + | shareType | group | + | permissions | share,read | + | shareWith | grp1 | + And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" + When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "17" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for owned folder + Given using DAV path + And user "Alice" has created folder "/tmp" + When user "Alice" gets the following properties of folder "/" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "201" + And the single response should contain a property "ocs:share-permissions" with value "31" + Examples: + | dav-path | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: Correct webdav share-permissions for received folder with all permissions + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "31" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "31" + Examples: + | dav-path | + | old | + | new | + + @issue-ocis-2213 + Scenario Outline: Correct webdav share-permissions for received folder with all permissions but edit + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | share,delete,create,read | + Then the HTTP status code should be "200" + And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "29" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but edit + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + | permissions | share,delete,create,read | + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "29" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received folder with all permissions but create + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | share,delete,update,read | + Then the HTTP status code should be "200" + And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "27" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but create + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + | permissions | share,delete,update,read | + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "27" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received folder with all permissions but delete + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the HTTP status code should be "200" + And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "23" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but delete + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + | permissions | share,create,update,read | + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "23" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received folder with all permissions but share + Given using DAV path + And user "Alice" has created folder "/tmp" + And user "Alice" has shared file "/tmp" with user "Brian" + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | change | + Then the HTTP status code should be "200" + And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "15" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Correct webdav share-permissions for received group shared folder with all permissions but share + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/tmp" + And user "Alice" has created a share with settings + | path | tmp | + | shareType | group | + | shareWith | grp1 | + | permissions | change | + And user "Brian" has accepted share "/tmp" offered by user "Alice" + When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API + | propertyName | + | ocs:share-permissions | + Then the HTTP status code should be "200" + And the single response should contain a property "ocs:share-permissions" with value "15" + Examples: + | dav-path | + | old | + | new | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature b/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature new file mode 100644 index 00000000000..a29c1f9dfc5 --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature @@ -0,0 +1,156 @@ +@api @files_sharing-app-required +Feature: share access by ID + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: Get a share with a valid share ID + Given using OCS API version "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + And user "Alice" gets share with id "%last_share_id%" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/textfile0.txt | + | path | /textfile0.txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Get a share with an invalid share id + Given using OCS API version "" + When user "Alice" gets share with id "" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And the API should not return any data + Examples: + | ocs_api_version | share_id | http_status_code | + | 1 | 2333311 | 200 | + | 2 | 2333311 | 404 | + | 1 | helloshare | 200 | + | 2 | helloshare | 404 | + | 1 | $#@r3 | 200 | + | 2 | $#@r3 | 404 | + | 1 | 0 | 200 | + | 2 | 0 | 404 | + + + Scenario Outline: accept a share using the share Id + Given using OCS API version "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + And user "Brian" accepts share with ID "%last_share_id%" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should see the following elements + | /Shares/textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the accepted state + | path | + | /Shares/textfile0.txt | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: accept a share using the invalid share Id + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And using OCS API version "" + When user "Brian" accepts share with ID "" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And the API should not return any data + Examples: + | ocs_api_version | share_id | http_status_code | + | 1 | 2333311 | 200 | + | 2 | 2333311 | 404 | + | 1 | helloshare | 200 | + | 2 | helloshare | 404 | + | 1 | $#@r3 | 200 | + | 2 | $#@r3 | 404 | + | 1 | 0 | 200 | + | 2 | 0 | 404 | + + + Scenario Outline: accept a share using empty share Id + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And using OCS API version "" + When user "Brian" accepts share with ID "" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And the API should not return any data + Examples: + | ocs_api_version | http_status_code | ocs_status_code | + | 1 | 200 | 999 | + | 2 | 500 | 500 | + + + Scenario Outline: decline a share using the share Id + Given using OCS API version "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" declines share with ID "%last_share_id%" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should not see the following elements + | /Shares/textfile0.txt | + And the sharing API should report to user "Brian" that these shares are in the declined state + | path | + | | + Examples: + | ocs_api_version | ocs_status_code | declined_share_path | + | 1 | 100 | /Shares/textfile0.txt | + | 2 | 200 | /Shares/textfile0.txt | + + + Scenario Outline: decline a share using a invalid share Id + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And using OCS API version "" + When user "Brian" declines share with ID "" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And the API should not return any data + Examples: + | ocs_api_version | share_id | http_status_code | + | 1 | 2333311 | 200 | + | 2 | 2333311 | 404 | + | 1 | helloshare | 200 | + | 2 | helloshare | 404 | + | 1 | $#@r3 | 200 | + | 2 | $#@r3 | 404 | + | 1 | 0 | 200 | + | 2 | 0 | 404 | + + + Scenario Outline: decline a share using empty share Id + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And using OCS API version "" + When user "Brian" declines share with ID "" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And the API should not return any data + Examples: + | ocs_api_version | http_status_code | ocs_status_code | + | 1 | 200 | 999 | + | 2 | 500 | 500 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares2/uploadToShare.feature b/tests/acceptance/features/coreApiShareOperationsToShares2/uploadToShare.feature new file mode 100644 index 00000000000..4e48ddc3d5a --- /dev/null +++ b/tests/acceptance/features/coreApiShareOperationsToShares2/uploadToShare.feature @@ -0,0 +1,307 @@ +@api @files_sharing-app-required +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario: Uploading file to a user read-only share folder does not work + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | read | + | shareWith | Brian | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/FOLDER/textfile.txt" should not exist + + + Scenario Outline: Uploading file to a group read-only share folder does not work + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | read | + | shareWith | grp1 | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/FOLDER/textfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading file to a user upload-only share folder works + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | create | + | shareWith | Brian | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Brian" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading file to a group upload-only share folder works + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | create | + | shareWith | grp1 | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Brian" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + @smokeTest + Scenario Outline: Uploading file to a user read/write share folder works + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | change | + | shareWith | Brian | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading file to a group read/write share folder works + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + @smokeTest @skipOnGraph + Scenario Outline: Check quota of owners parent directory of a shared file + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And the quota of user "Brian" has been set to "0" + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/myfile.txt" + And user "Alice" has shared file "myfile.txt" with user "Brian" + And user "Brian" has accepted share "/myfile.txt" offered by user "Alice" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/myfile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the following headers should match these regular expressions for user "Brian" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/myfile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav-path | + | old | + | new | + + @skipOnGraph + Scenario Outline: Uploading to a user shared folder with read/write permission when the sharer has unsufficient quota does not work + Given using DAV path + And user "Brian" has been created with default attributes and small skeleton files + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | change | + | shareWith | Brian | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And the quota of user "Alice" has been set to "0" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/myfile.txt" using the WebDAV API + Then the HTTP status code should be "507" + And as "Alice" file "/FOLDER/myfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Uploading to a group shared folder with read/write permission when the sharer has unsufficient quota does not work + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And the quota of user "Alice" has been set to "0" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/myfile.txt" using the WebDAV API + Then the HTTP status code should be "507" + And as "Alice" file "/FOLDER/myfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + @skipOnGraph + Scenario Outline: Uploading to a user shared folder with upload-only permission when the sharer has insufficient quota does not work + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | create | + | shareWith | Brian | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And the quota of user "Alice" has been set to "0" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/myfile.txt" using the WebDAV API + Then the HTTP status code should be "507" + And as "Alice" file "/FOLDER/myfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + @skipOnGraph + Scenario Outline: Uploading to a group shared folder with upload-only permission when the sharer has insufficient quota does not work + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | group | + | permissions | create | + | shareWith | grp1 | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And the quota of user "Alice" has been set to "0" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/myfile.txt" using the WebDAV API + Then the HTTP status code should be "507" + And as "Alice" file "/FOLDER/myfile.txt" should not exist + Examples: + | dav-path | + | old | + | new | + + @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Uploading a file in to a shared folder without edit permissions + Given using new DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/READ_ONLY" + And user "Alice" has created a share with settings + | path | /READ_ONLY | + | shareType | user | + | permissions | read | + | shareWith | Brian | + And user "Brian" has accepted share "/READ_ONLY" offered by user "Alice" + When user "Brian" uploads the following chunks to "/Shares/READ_ONLY/myfile.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | hallo | + | 2 | welt | + Then the HTTP status code should be "403" + And as "Alice" file "/FOLDER/myfile.txt" should not exist + + + Scenario Outline: Sharer can download file uploaded with different permission by sharee to a shared folder + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | | + | shareWith | Brian | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file with content "some content" to "/Shares/FOLDER/textFile.txt" using the WebDAV API + And user "Alice" downloads file "/FOLDER/textFile.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded content should be "some content" + Examples: + | dav-path | permissions | + | old | change | + | new | create | + + + Scenario Outline: upload an empty file (size zero byte) to a shared folder + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/folder-to-share" + And user "Brian" has shared folder "/folder-to-share" with user "Alice" + And user "Alice" has accepted share "/folder-to-share" offered by user "Brian" + When user "Alice" uploads file "filesForUpload/zerobyte.txt" to "/Shares/folder-to-share/zerobyte.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/Shares/folder-to-share/zerobyte.txt" should exist + And the content of file "/Shares/folder-to-share/zerobyte.txt" for user "Alice" should be "" + Examples: + | dav_version | + | old | + | new | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiSharePublicLink1/accessToPublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink1/accessToPublicLinkShare.feature new file mode 100644 index 00000000000..5dd24d6924b --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink1/accessToPublicLinkShare.feature @@ -0,0 +1,59 @@ +@api @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-282 +Feature: accessing a public link share + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + + + Scenario: Access to the preview of password protected public link without providing the password is not allowed + Given the administrator has enabled DAV tech_preview + And user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "testavatar.jpg" + And user "Alice" has created a public link share with settings + | path | /testavatar.jpg | + | permissions | change | + | password | testpass1 | + When the public accesses the preview of file "testavatar.jpg" from the last shared public link using the sharing API + Then the HTTP status code should be "404" + + + Scenario: Access to the preview of public shared file without password + Given the administrator has enabled DAV tech_preview + And user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "testavatar.jpg" + And user "Alice" has created a public link share with settings + | path | /testavatar.jpg | + | permissions | change | + When the public accesses the preview of file "testavatar.jpg" from the last shared public link using the sharing API + Then the HTTP status code should be "200" + + + Scenario: Access to the preview of password protected public shared file inside a folder without providing the password is not allowed + Given the administrator has enabled DAV tech_preview + And user "Alice" has created folder "FOLDER" + And user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "FOLDER/testavatar.jpg" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "FOLDER/textfile0.txt" + And user "Alice" has created a public link share with settings + | path | /FOLDER | + | permissions | change | + | password | testpass1 | + When the public accesses the preview of the following files from the last shared public link using the sharing API + | path | + | testavatar.jpg | + | textfile0.txt | + Then the HTTP status code of responses on all endpoints should be "404" + + + Scenario: Access to the preview of public shared file inside a folder without password + Given the administrator has enabled DAV tech_preview + And user "Alice" has created folder "FOLDER" + And user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "FOLDER/testavatar.jpg" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "FOLDER/textfile0.txt" + And user "Alice" has created a public link share with settings + | path | /FOLDER | + | permissions | change | + When the public accesses the preview of the following files from the last shared public link using the sharing API + | path | + | testavatar.jpg | + | textfile0.txt | + Then the HTTP status code of responses on all endpoints should be "200" diff --git a/tests/acceptance/features/coreApiSharePublicLink1/changingPublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink1/changingPublicLinkShare.feature new file mode 100644 index 00000000000..d041b4f127f --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink1/changingPublicLinkShare.feature @@ -0,0 +1,270 @@ +@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-315 @issue-ocis-reva-316 + +Feature: changing a public link share + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + + + Scenario Outline: Public can or can-not delete file through publicly shared link depending on having delete permissions using the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | | + When the public deletes file "parent.txt" from the last public link share using the public WebDAV API + Then the HTTP status code should be "" + And as "Alice" file "PARENT/parent.txt" exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | permissions | http-status-code | should-or-not | public-webdav-api-version | + | read,update,create | 403 | should | old | + | read,update,create,delete | 204 | should not | old | + + @issue-ocis-reva-292 + Examples: + | permissions | http-status-code | should-or-not | public-webdav-api-version | + | read,update,create | 403 | should | new | + | read,update,create,delete | 204 | should not | new | + + + Scenario Outline: Public link share permissions work correctly for renaming and share permissions read,update,create with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create | + When the public renames file "parent.txt" to "newparent.txt" from the last public link share using the public WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/PARENT/parent.txt" should exist + And as "Alice" file "/PARENT/newparent.txt" should not exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-292 + Examples: + | public-webdav-api-version | + | new | + + @skipOnRansomwareProtection @issue-ransomware-208 + Scenario Outline: Public link share permissions work correctly for renaming and share permissions read,update,create,delete using the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public renames file "parent.txt" to "newparent.txt" from the last public link share using the public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/parent.txt" should not exist + And as "Alice" file "/PARENT/newparent.txt" should exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Public link share permissions work correctly for upload with share permissions read,update,create with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create | + When the public uploads file "lorem.txt" with content "test" using the public WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/PARENT/lorem.txt" should not exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-292 + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Public link share permissions work correctly for upload with share permissions read,update,create,delete with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public uploads file "lorem.txt" with content "test" using the public WebDAV API + Then the HTTP status code should be "201" + And the content of file "PARENT/lorem.txt" for user "Alice" should be "test" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Public cannot delete file through publicly shared link with password using an invalid password with public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | change | + | password | newpasswd | + When the public deletes file "parent.txt" from the last public link share using the password "invalid" and public WebDAV API + Then the HTTP status code should be "401" + And as "Alice" file "PARENT/parent.txt" should exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Public can delete file through publicly shared link with password using the valid password with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | change | + | password | newpasswd | + When the public deletes file "parent.txt" from the last public link share using the password "newpasswd" and public WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "PARENT/parent.txt" should not exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-292 + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Public tries to rename a file in a password protected share using an invalid password with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | change | + | password | newpasswd | + When the public renames file "parent.txt" to "newparent.txt" from the last public link share using the password "invalid" and public WebDAV API + Then the HTTP status code should be "401" + And as "Alice" file "/PARENT/newparent.txt" should not exist + And as "Alice" file "/PARENT/parent.txt" should exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + @skipOnRansomwareProtection @issue-ransomware-208 + Scenario Outline: Public tries to rename a file in a password protected share using the valid password with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | change | + | password | newpasswd | + When the public renames file "parent.txt" to "newparent.txt" from the last public link share using the password "newpasswd" and public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/newparent.txt" should exist + And as "Alice" file "/PARENT/parent.txt" should not exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Public tries to upload to a password protected public share using an invalid password with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | change | + | password | newpasswd | + When the public uploads file "lorem.txt" with password "invalid" and content "test" using the public WebDAV API + Then the HTTP status code should be "401" + And as "Alice" file "/PARENT/lorem.txt" should not exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Public tries to upload to a password protected public share using the valid password with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | change | + | password | newpasswd | + When the public uploads file "lorem.txt" with password "newpasswd" and content "test" using the public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/lorem.txt" should exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Public cannot rename a file in uploadwriteonly public link share with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | uploadwriteonly | + When the public renames file "parent.txt" to "newparent.txt" from the last public link share using the public WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/PARENT/parent.txt" should exist + And as "Alice" file "/PARENT/newparent.txt" should not exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-292 + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Public cannot delete a file in uploadwriteonly public link share with the public WebDAV API + Given user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | uploadwriteonly | + When the public deletes file "parent.txt" from the last public link share using the public WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "PARENT/parent.txt" should exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-292 + Examples: + | public-webdav-api-version | + | new | diff --git a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature new file mode 100644 index 00000000000..24667dd5347 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature @@ -0,0 +1,641 @@ +@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-315 @issue-ocis-reva-316 + +Feature: create a public link share + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: A new public link share of a file using the default permissions only grants read access using the public WebDAV API + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | randomfile.txt | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | file | + | mimetype | text/plain | + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | permissions | read | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + And the public should be able to download the last publicly shared file using the old public WebDAV API without a password and the content should be "Random data" + And the public should be able to download the last publicly shared file using the new public WebDAV API without a password and the content should be "Random data" + And the public upload to the last publicly shared file using the old public WebDAV API should fail with HTTP status code "403" + And the public upload to the last publicly shared file using the new public WebDAV API should fail with HTTP status code "403" + + @issue-ocis-reva-12 @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @notToImplementOnOCIS @issue-ocis-2079 + Scenario Outline: Creating a new public link share of a file with password using the old public WebDAV API + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | randomfile.txt | + | password | %public% | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | file | + | mimetype | text/plain | + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | permissions | read | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + And the public should be able to download the last publicly shared file using the old public WebDAV API with password "%public%" and the content should be "Random data" + And the HTTP status code should be "200" + And the public download of the last publicly shared file using the old public WebDAV API with password "%regular%" should fail with HTTP status code "401" + And the value of the item "//s:message" in the response should be "Cannot authenticate over ajax calls" + And the public download of the last publicly shared file using the old public WebDAV API without a password should fail with HTTP status code "401" + And the value of the item "//s:message" in the response should be "Cannot authenticate over ajax calls" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @issue-ocis-reva-199 + Scenario Outline: Creating a new public link share of a file with password using the new public WebDAV API + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | randomfile.txt | + | password | %public% | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | file | + | mimetype | text/plain | + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | permissions | read | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + And the public should be able to download the last publicly shared file using the new public WebDAV API with password "%public%" and the content should be "Random data" + And the HTTP status code should be "200" + And the public download of the last publicly shared file using the new public WebDAV API with password "%regular%" should fail with HTTP status code "401" + And the value of the item "//s:message" in the response should match "/Username or password was incorrect/" + And the public download of the last publicly shared file using the new public WebDAV API without a password should fail with HTTP status code "401" + And the value of the item "//s:message" in the response should match "/No 'Authorization: Basic' header found/" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Create a new public link share of a file with edit permissions + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | randomfile.txt | + | permissions | read,update,create,delete | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | file | + | mimetype | text/plain | + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | permissions | read,update | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + And the public should be able to download the last publicly shared file using the old public WebDAV API without a password and the content should be "Random data" + And the public should be able to download the last publicly shared file using the new public WebDAV API without a password and the content should be "Random data" + And uploading content to a public link shared file should work using the old public WebDAV API + And uploading content to a public link shared file should work using the new public WebDAV API + + @issue-ocis-2079 @issue-ocis-reva-292 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating a new public link share of a folder using the default permissions only grants read access and can be accessed with no password or any password using the public WebDAV API + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "Random data" to "/PARENT/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | PARENT | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | folder | + | mimetype | httpd/unix-directory | + | file_target | /PARENT | + | path | /PARENT | + | permissions | read | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + And the public should be able to download file "/randomfile.txt" from inside the last public link shared folder using the old public WebDAV API without password and the content should be "Random data" + And the public should be able to download file "/randomfile.txt" from inside the last public link shared folder using the new public WebDAV API without password and the content should be "Random data" + And the public upload to the last publicly shared folder using the old public WebDAV API should fail with HTTP status code "403" + And the public upload to the last publicly shared folder using the new public WebDAV API should fail with HTTP status code "403" + + @issue-ocis-reva-12 @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating a new public link share of a folder, with a password and accessing using the public WebDAV API + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "Random data" to "/PARENT/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | PARENT | + | password | %public% | + | permissions | change | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | folder | + | mimetype | httpd/unix-directory | + | file_target | /PARENT | + | path | /PARENT | + | permissions | change | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + And the public should be able to download file "/randomfile.txt" from inside the last public link shared folder using the old public WebDAV API with password "%public%" and the content should be "Random data" + And the public should be able to download file "/randomfile.txt" from inside the last public link shared folder using the new public WebDAV API with password "%public%" and the content should be "Random data" + But the public should not be able to download file "/randomfile.txt" from inside the last public link shared folder using the old public WebDAV API without a password + And the public should not be able to download file "/randomfile.txt" from inside the last public link shared folder using the old public WebDAV API with password "%regular%" + And the public should not be able to download file "/randomfile.txt" from inside the last public link shared folder using the new public WebDAV API without a password + And the public should not be able to download file "/randomfile.txt" from inside the last public link shared folder using the new public WebDAV API with password "%regular%" + @issue-ocis-2079 @issue-ocis-reva-292 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @issue-ocis-reva-294 + Scenario Outline: Getting the share information of public link share from the OCS API does not expose sensitive information + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | randomfile.txt | + | password | %public% | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | item_type | file | + | share_type | public_link | + | permissions | read | + | uid_owner | Alice | + | share_with | ***redacted*** | + | share_with_displayname | ***redacted*** | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Getting the share information of passwordless public-links hides credential placeholders + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | randomfile.txt | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | item_type | file | + | share_type | public_link | + | permissions | read | + | uid_owner | %username% | + And the fields of the last response should not include + | share_with | ANY_VALUE | + | share_with_displayname | ANY_VALUE | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating a link share with no specified permissions defaults to read permissions when public upload is disabled globally and accessing using the public WebDAV API + Given using OCS API version "" + And parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + And user "Alice" has created folder "/afolder" + When user "Alice" creates a public link share using the sharing API with settings + | path | /afolder | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | share_type | public_link | + | permissions | read | + And the public upload to the last publicly shared folder using the old public WebDAV API should fail with HTTP status code "403" + And the public upload to the last publicly shared folder using the new public WebDAV API should fail with HTTP status code "403" + + @issue-ocis-reva-41 @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating a public link share with read+create permissions is forbidden when public upload is disabled globally + Given using OCS API version "" + And parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + And user "Alice" has created folder "/afolder" + When user "Alice" creates a public link share using the sharing API with settings + | path | /afolder | + | permissions | read,create | + Then the OCS status code should be "" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 403 | + | 2 | 403 | + + + Scenario Outline: Creating a public link share with create permissions is forbidden when public upload is disabled globally + Given using OCS API version "" + And parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + And user "Alice" has created folder "/afolder" + When user "Alice" creates a public link share using the sharing API with settings + | path | /afolder | + | permissions | create | + Then the OCS status code should be "" + + @notToImplementOnOCIS @issue-ocis-2079 @issue-ocis-reva-41 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 403 | + | 2 | 403 | + + + Scenario Outline: Updating a public link share with read+create permissions is forbidden when public upload is disabled globally + Given using OCS API version "" + And user "Alice" has created folder "/afolder" + And user "Alice" has created a public link share with settings + | path | /afolder | + | permissions | read | + And parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + When user "Alice" tries to update the last public link share using the sharing API with + | permissions | read,create | + Then the OCS status code should be "" + + @notToImplementOnOCIS @issue-ocis-2079 @issue-ocis-reva-41 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 403 | + | 2 | 403 | + + @issue-ocis-reva-41 + Scenario Outline: Creating a link share with read+update+create permissions is forbidden when public upload is disabled globally + Given using OCS API version "" + And parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + And user "Alice" has created folder "/afolder" + When user "Alice" creates a public link share using the sharing API with settings + | path | /afolder | + | permissions | read,update,create | + Then the OCS status code should be "" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 403 | + | 2 | 403 | + + @issue-ocis-reva-41 @skipOnOcis + Scenario Outline: Creating a link share with update permissions defaults to read permissions when public upload disabled globally + Given using OCS API version "" + And parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + And user "Alice" has created folder "/afolder" + When user "Alice" creates a public link share using the sharing API with settings + | path | /afolder | + | permissions | read,update,create,delete | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the last response should be empty + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | + + + Scenario Outline: Creating a link share with edit permissions keeps it using the public WebDAV API + Given using OCS API version "" + And user "Alice" has created folder "/afolder" + When user "Alice" creates a public link share using the sharing API with settings + | path | /afolder | + | permissions | read,update,create,delete | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | share_type | public_link | + | permissions | read,update,create,delete | + And uploading a file should work using the old public WebDAV API + And uploading a file should work using the new public WebDAV API + + @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating a link share with upload permissions keeps it using the public WebDAV API + Given using OCS API version "" + And user "Alice" has created folder "/afolder" + When user "Alice" creates a public link share using the sharing API with settings + | path | /afolder | + | permissions | read,create | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | share_type | public_link | + | permissions | read,create | + And uploading a file should work using the old public WebDAV API + And uploading a file should work using the new public WebDAV API + + @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + @issue-ocis-reva-283 @notToImplementOnOCIS + Scenario Outline: Do not allow public sharing of the root on ownCloud10 + Given using OCS API version "" + When user "Alice" creates a public link share using the sharing API with settings + | path | / | + Then the OCS status code should be "" + And the HTTP status code should be "" + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | + + @issue-ocis-reva-283 @skipOnOcV10 + Scenario Outline: Allow public sharing of the root on OCIS when the default permission is read and access using the public WebDAV API + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | / | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | folder | + | mimetype | httpd/unix-directory | + | file_target | / | + | path | / | + | permissions | read | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + And the public should be able to download file "/randomfile.txt" from inside the last public link shared folder using the new public WebDAV API without password and the content should be "Random data" + And the public upload to the last publicly shared folder using the new public WebDAV API should fail with HTTP status code "403" + @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + Scenario Outline: user creates a public link share of a file with file name longer than 64 chars using the public WebDAV API + Given using OCS API version "" + And user "Alice" has uploaded file with content "long file" to "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | /aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download the last publicly shared file using the old public WebDAV API without a password and the content should be "long file" + And the public should be able to download the last publicly shared file using the new public WebDAV API without a password and the content should be "long file" + + @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + + Scenario Outline: user creates a public link share of a folder with folder name longer than 64 chars and access using the public WebDAV API + Given using OCS API version "" + And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" + And user "Alice" has uploaded file with content "Random data" to "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | /aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "/randomfile.txt" from inside the last public link shared folder using the old public WebDAV API without password and the content should be "Random data" + And the public should be able to download file "/randomfile.txt" from inside the last public link shared folder using the new public WebDAV API without password and the content should be "Random data" + + @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-41 + Scenario Outline: Create a public link with default expiration date set and max expiration date enforced and access using the public WebDAV API + Given using OCS API version "" + And parameter "shareapi_default_expire_date" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date" of app "core" has been set to "yes" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | randomfile.txt | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the fields of the last response to user "Alice" should include + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | item_type | file | + | share_type | public_link | + | permissions | read | + | uid_owner | %username% | + | expiration | +7 days | + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And the fields of the last response to user "Alice" should include + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | item_type | file | + | share_type | public_link | + | permissions | read | + | uid_owner | %username% | + | expiration | +7 days | + And the public should be able to download the last publicly shared file using the old public WebDAV API without a password and the content should be "Random data" + And the public should be able to download the last publicly shared file using the new public WebDAV API without a password and the content should be "Random data" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @issue-ocis-reva-199 + Scenario Outline: Delete a folder that has been publicly shared and try to access using the public WebDAV API + Given user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file with content "Random data" to "/PARENT/parent.txt" + And user "Alice" has created a public link share with settings + | path | PARENT | + | permissions | read | + When user "Alice" deletes folder "PARENT" using the WebDAV API + And the public download of file "/parent.txt" from inside the last public link shared folder using the public WebDAV API should fail with HTTP status code "404" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + @issue-ocis-reva-292 + Scenario Outline: try to download from a public share that has upload only permissions using the public webdav api + Given user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file with content "Random data" to "/PARENT/parent.txt" + And user "Alice" has created a public link share with settings + | path | PARENT | + | permissions | uploadwriteonly | + When the public downloads file "parent.txt" from inside the last public link shared folder using the public WebDAV API + Then the value of the item "//s:message" in the response should be "" + And the HTTP status code should be "404" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | response | + | old | | + + + Examples: + | public-webdav-api-version | response | + | new | File not found: parent.txt | + + + Scenario: Get the size of a file shared by public link + Given user "Alice" has uploaded file with content "This is a test file" to "test-file.txt" + And user "Alice" has created a public link share with settings + | path | test-file.txt | + | permissions | read | + When the public gets the size of the last shared public link using the WebDAV API + Then the HTTP status code should be "207" + And the size of the file should be "19" + + + Scenario Outline: Get the mtime of a file shared by public link + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API + When user "Alice" creates a public link share using the sharing API with settings + | path | file.txt | + | permissions | read | + Then the HTTP status code should be "200" + And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Get the mtime of a file inside a folder shared by public link + Given using DAV path + And user "Alice" has created folder "testFolder" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "testFolder/file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API + When user "Alice" creates a public link share using the sharing API with settings + | path | /testFolder | + | permissions | read | + Then the HTTP status code should be "200" + And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + @issue-37605 @skipOnOcV10 + Scenario: Get the mtime of a file inside a folder shared by public link using new webDAV version + Given user "Alice" has created folder "testFolder" + And user "Alice" has created a public link share with settings + | path | /testFolder | + | permissions | read,update,create,delete | + When the public uploads file "file.txt" to the last public link shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "testFolder/file.txt" should exist + And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT" + + @issue-37605 @skipOnOcV10 + Scenario: overwriting a file changes its mtime (new public webDAV API) + Given user "Alice" has created folder "testFolder" + When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "testFolder/file.txt" using the WebDAV API + And user "Alice" creates a public link share using the sharing API with settings + | path | /testFolder | + | permissions | read,update,create,delete | + And the public uploads file "file.txt" to the last public link shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/testFolder/file.txt" should exist + And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT" + + @notToImplementOnOCIS + Scenario Outline: Set multiple expiration dates, the expired date shouldn't affect the future expiration date + Given using OCS API version "" + And parameter "shareapi_enforce_expire_date" of app "core" has been set to "yes" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | /textfile0.txt | + | name | link1 | + | expireDateAsString | +6 days | + And user "Alice" creates a public link share using the sharing API with settings + | path | /textfile0.txt | + | name | link2 | + | expireDateAsString | +5 days | + And the administrator expires the last created public link share using the testing API + Then the HTTP status code should be "" + When user "Alice" gets all the shares from the file "textfile0.txt" using the sharing API + Then the HTTP status code should be "" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include + | name | link1 | + | expiration | +6 days | + But the fields of the last response should not include + | name | link2 | + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | diff --git a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareOc10Issue37605.feature b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareOc10Issue37605.feature new file mode 100644 index 00000000000..22fd35fbc80 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareOc10Issue37605.feature @@ -0,0 +1,31 @@ +@api @files_sharing-app-required @public_link_share-feature-required @notToImplementOnOCIS + +Feature: create a public link share + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "testFolder" + And user "Alice" has created a public link share with settings + | path | /testFolder | + | permissions | read,update,create,delete | + + @issue-37605 + Scenario: Get the mtime of a file inside a folder shared by public link using new webDAV version + When the public uploads file "file.txt" to the last public link shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "testFolder/file.txt" should exist + And as "Alice" the mtime of the file "testFolder/file.txt" should not be "Thu, 08 Aug 2019 04:18:13 GMT" +# And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + And the mtime of file "file.txt" in the last shared public link using the WebDAV API should not be "Thu, 08 Aug 2019 04:18:13 GMT" +# And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT" + + @issue-37605 + Scenario: overwriting a file changes its mtime (new public webDAV API) + Given user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "testFolder/file.txt" + When the public uploads file "file.txt" to the last public link shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/testFolder/file.txt" should exist + And as "Alice" the mtime of the file "testFolder/file.txt" should not be "Thu, 08 Aug 2019 04:18:13 GMT" +# And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + And the mtime of file "file.txt" in the last shared public link using the WebDAV API should not be "Thu, 08 Aug 2019 04:18:13 GMT" +# And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT" \ No newline at end of file diff --git a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareToShares.feature b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareToShares.feature new file mode 100644 index 00000000000..5b6be928858 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareToShares.feature @@ -0,0 +1,32 @@ +@api @files_sharing-app-required @public_link_share-feature-required +Feature: create a public link share when share_folder is set to Shares + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Creating a new public link share of a file gives the correct response + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + When user "Alice" creates a public link share using the sharing API with settings + | path | randomfile.txt | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | file | + | mimetype | text/plain | + | file_target | /randomfile.txt | + | path | /randomfile.txt | + | permissions | read | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiSharePublicLink1/deletePublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink1/deletePublicLinkShare.feature new file mode 100644 index 00000000000..61612e977dc --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink1/deletePublicLinkShare.feature @@ -0,0 +1,72 @@ +@api +Feature: delete a public link share + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @issue-product-60 + Scenario Outline: Deleting a public link of a file + Given using OCS API version "" + And user "Alice" has uploaded file with content "This is a test file" to "test-file.txt" + And user "Alice" has created a public link share with settings + | path | test-file.txt | + | name | sharedlink | + When user "Alice" deletes public link share named "sharedlink" in file "test-file.txt" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And as user "Alice" the file "test-file.txt" should not have any shares + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-product-60 @issue-ocis-reva-311 + Scenario Outline: Deleting a public link after renaming a file + Given using OCS API version "" + And user "Alice" has uploaded file with content "This is a test file" to "test-file.txt" + And user "Alice" has created a public link share with settings + | path | test-file.txt | + | name | sharedlink | + When user "Alice" moves file "/test-file.txt" to "/renamed-test-file.txt" using the WebDAV API + And user "Alice" deletes public link share named "sharedlink" in file "renamed-test-file.txt" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as user "Alice" the file "renamed-test-file.txt" should not have any shares + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-product-60 + Scenario Outline: Deleting a public link of a folder + Given using OCS API version "" + And user "Alice" has created folder "test-folder" + And user "Alice" has created a public link share with settings + | path | /test-folder | + | name | sharedlink | + When user "Alice" deletes public link share named "sharedlink" in folder "test-folder" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And as user "Alice" the folder "test-folder" should not have any shares + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-product-60 + Scenario Outline: Deleting a public link of a file in a folder + Given using OCS API version "" + And user "Alice" has created folder "test-folder" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/test-folder/testfile.txt" using the WebDAV API + And user "Alice" has created a public link share with settings + | path | /test-folder/testfile.txt | + | name | sharedlink | + And user "Alice" deletes public link share named "sharedlink" in file "/test-folder/testfile.txt" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And as user "Alice" the file "/test-folder/testfile.txt" should not have any shares + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + diff --git a/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature b/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature new file mode 100644 index 00000000000..95dfc7f4327 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature @@ -0,0 +1,190 @@ +@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-310 +Feature: copying from public link share + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + + + Scenario: Copy file within a public link folder new public WebDAV API + Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/testfile.txt" to "/copy1.txt" using the new public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/testfile.txt" should exist + And as "Alice" file "/PARENT/copy1.txt" should exist + And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data" + And the content of file "/PARENT/copy1.txt" for user "Alice" should be "some data" + + + Scenario: Copy folder within a public link folder new public WebDAV API + Given user "Alice" has created folder "/PARENT/testFolder" + And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies folder "/testFolder" to "/testFolder-copy" using the new public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" folder "/PARENT/testFolder" should exist + And as "Alice" folder "/PARENT/testFolder-copy" should exist + And the content of file "/PARENT/testFolder/testfile.txt" for user "Alice" should be "some data" + And the content of file "/PARENT/testFolder-copy/testfile.txt" for user "Alice" should be "some data" + + + Scenario: Copy file within a public link folder to a new folder + Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" + And user "Alice" has created folder "/PARENT/testFolder" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/testfile.txt" to "/testFolder/copy1.txt" using the new public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/testfile.txt" should exist + And as "Alice" file "/PARENT/testFolder/copy1.txt" should exist + And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data" + And the content of file "/PARENT/testFolder/copy1.txt" for user "Alice" should be "some data" + + + Scenario: Copy file within a public link folder to same file name as already existing one + Given user "Alice" has uploaded file with content "some data 0" to "/PARENT/testfile.txt" + And user "Alice" has uploaded file with content "some data 1" to "/PARENT/copy1.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/testfile.txt" to "/copy1.txt" using the new public WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/PARENT/testfile.txt" should exist + And as "Alice" file "/PARENT/copy1.txt" should exist + And the content of file "/PARENT/copy1.txt" for user "Alice" should be "some data 0" + + @skipOnOcV10 @issue-ocis-reva-373 @issue-37683 + Scenario: Copy folder within a public link folder to the same folder name as an already existing file + Given user "Alice" has created folder "/PARENT/testFolder" + And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt" + And user "Alice" has uploaded file with content "some data 1" to "/PARENT/copy1.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies folder "/testFolder" to "/copy1.txt" using the new public WebDAV API + Then the HTTP status code should be "403" + And as "Alice" folder "/PARENT/testFolder" should exist + And as "Alice" folder "/PARENT/copy1.txt" should exist + And as "Alice" file "/PARENT/copy1.txt/testfile.txt" should not exist + And the content of file "/PARENT/testFolder/testfile.txt" for user "Alice" should be "some data" + + + Scenario: Copy file within a public link folder and delete file + Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/testfile.txt" to "/copy1.txt" using the new public WebDAV API + And user "Alice" deletes file "/PARENT/copy1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/PARENT/copy1.txt" should not exist + + @skipOnOcV10 @issue-ocis-reva-373 @issue-37683 + Scenario: Copy file within a public link folder to a file with name same as an existing folder + Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" + And user "Alice" has created folder "/PARENT/new-folder" + And user "Alice" has uploaded file with content "some data 1" to "/PARENT/new-folder/testfile1.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/testfile.txt" to "/new-folder" using the new public WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/PARENT/testfile.txt" should exist + And as "Alice" folder "/PARENT/new-folder" should exist + And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data" + And the content of file "/PARENT/new-folder/testfile.txt" for user "Alice" should be "some data" + + + Scenario Outline: Copy file with special characters in it's name within a public link folder + Given user "Alice" has uploaded file with content "some data" to "/PARENT/" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/" to "/copy1.txt" using the new public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/" should exist + And as "Alice" file "/PARENT/copy1.txt" should exist + And the content of file "/PARENT/" for user "Alice" should be "some data" + And the content of file "/PARENT/copy1.txt" for user "Alice" should be "some data" + Examples: + | file-name | + | नेपाली.txt | + | strängé file.txt | + | C++ file.cpp | + | sample,1.txt | + + + Scenario Outline: Copy file within a public link folder to a file with special characters in it's name + Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/testfile.txt" to "/" using the new public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/testfile.txt" should exist + And as "Alice" file "/PARENT/" should exist + And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data" + And the content of file "/PARENT/" for user "Alice" should be "some data" + Examples: + | destination-file-name | + | नेपाली.txt | + | strängé file.txt | + | C++ file.cpp | + | sample,1.txt | + + + Scenario Outline: Copy file within a public link folder into a folder with special characters + Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" + And user "Alice" has created folder "/PARENT/" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/testfile.txt" to "//copy1.txt" using the new public WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/testfile.txt" should exist + And as "Alice" file "/PARENT//copy1.txt" should exist + And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data" + And the content of file "/PARENT//copy1.txt" for user "Alice" should be "some data" + Examples: + | destination-folder-name | + | नेपाली.txt | + | strängé file.txt | + | C++ file.cpp | + | sample,1.txt | + + @issue-ocis-reva-368 + Scenario Outline: Copy file within a public link folder to a file with unusual destination names + Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/testfile.txt" to "/" using the new public WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/PARENT/testfile.txt" should exist + And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data" + Examples: + | destination-file-name | + | testfile.txt | + | | + + @issue-ocis-reva-368 + Scenario Outline: Copy folder within a public link folder to a folder with unusual destination names + Given user "Alice" has created folder "/PARENT/testFolder" + And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies folder "/testFolder" to "/" using the new public WebDAV API + Then the HTTP status code should be "403" + And as "Alice" folder "/PARENT/testFolder" should exist + And the content of file "/PARENT/testFolder/testfile.txt" for user "Alice" should be "some data" + Examples: + | destination-file-name | + | testFolder | + | | diff --git a/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLinkOc10Issue37683.feature b/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLinkOc10Issue37683.feature new file mode 100644 index 00000000000..cb5f4e005d4 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLinkOc10Issue37683.feature @@ -0,0 +1,37 @@ +@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-310 @notToImplementOnOCIS +Feature: copying from public link share + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/PARENT" + + @issue-ocis-reva-373 @issue-37683 @skipOnLDAP @issue-user_ldap-702 + Scenario: Copy folder within a public link folder to the same folder name as an already existing file + Given user "Alice" has created folder "/PARENT/testFolder" + And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt" + And user "Alice" has uploaded file with content "some data 1" to "/PARENT/copy1.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies folder "/testFolder" to "/copy1.txt" using the new public WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/PARENT/testFolder" should exist + And as "Alice" folder "/PARENT/copy1.txt" should exist + And as "Alice" file "/PARENT/copy1.txt/testfile.txt" should exist + And the content of file "/PARENT/copy1.txt/testfile.txt" for user "Alice" should be "some data" + And the content of file "/PARENT/testFolder/testfile.txt" for user "Alice" should be "some data" + + @issue-ocis-reva-373 @issue-37683 + Scenario: Copy file within a public link folder to a file with name same as an existing folder + Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" + And user "Alice" has created folder "/PARENT/new-folder" + And user "Alice" has uploaded file with content "some data 1" to "/PARENT/new-folder/testfile1.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + When the public copies file "/testfile.txt" to "/new-folder" using the new public WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/PARENT/testfile.txt" should exist + And as "Alice" file "/PARENT/new-folder" should exist + And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data" + And the content of file "/PARENT/new-folder" for user "Alice" should be "some data" diff --git a/tests/acceptance/features/coreApiSharePublicLink2/multilinkSharing.feature b/tests/acceptance/features/coreApiSharePublicLink2/multilinkSharing.feature new file mode 100644 index 00000000000..1fb94635f37 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink2/multilinkSharing.feature @@ -0,0 +1,245 @@ +@api @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-288 @issue-ocis-reva-252 +Feature: multilinksharing + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: Creating three public shares of a folder + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + | password | %public% | + | expireDate | +3 days | + | publicUpload | true | + | permissions | change | + | name | sharedlink1 | + And user "Alice" has created a public link share with settings + | path | FOLDER | + | password | %public% | + | expireDate | +3 days | + | publicUpload | true | + | permissions | change | + | name | sharedlink2 | + And user "Alice" has created a public link share with settings + | path | FOLDER | + | password | %public% | + | expireDate | +3 days | + | publicUpload | true | + | permissions | change | + | name | sharedlink3 | + When user "Alice" updates the last public link share using the sharing API with + | permissions | read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as user "Alice" the public shares of folder "/FOLDER" should be + | path | permissions | name | + | /FOLDER | 15 | sharedlink2 | + | /FOLDER | 15 | sharedlink1 | + | /FOLDER | 1 | sharedlink3 | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating three public shares of a file + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink1 | + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink2 | + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink3 | + When user "Alice" updates the last public link share using the sharing API with + | permissions | read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as user "Alice" the public shares of file "/textfile0.txt" should be + | path | permissions | name | + | /textfile0.txt | 1 | sharedlink2 | + | /textfile0.txt | 1 | sharedlink1 | + | /textfile0.txt | 1 | sharedlink3 | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Check that updating password doesn't remove name of links + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + | password | %public% | + | expireDate | +3 days | + | publicUpload | true | + | permissions | change | + | name | sharedlink1 | + And user "Alice" has created a public link share with settings + | path | FOLDER | + | password | %public% | + | expireDate | +3 days | + | publicUpload | true | + | permissions | change | + | name | sharedlink2 | + When user "Alice" updates the last public link share using the sharing API with + | password | %alt1% | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as user "Alice" the public shares of folder "/FOLDER" should be + | path | permissions | name | + | /FOLDER | 15 | sharedlink2 | + | /FOLDER | 15 | sharedlink1 | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Deleting a file deletes also its public links + Given using OCS API version "1" + And using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink1 | + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink2 | + And user "Alice" has deleted file "/textfile0.txt" + And the HTTP status code should be "204" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as user "Alice" the file "/textfile0.txt" should not have any shares + Examples: + | dav-path | + | old | + | new | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | + | spaces | + + + Scenario Outline: Deleting one public link share of a file doesn't affect the rest + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink1 | + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink2 | + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink3 | + When user "Alice" deletes public link share named "sharedlink2" in file "/textfile0.txt" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as user "Alice" the public shares of file "/textfile0.txt" should be + | path | permissions | name | + | /textfile0.txt | 1 | sharedlink1 | + | /textfile0.txt | 1 | sharedlink3 | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Overwriting a file doesn't remove its public shares + Given using OCS API version "1" + And using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink1 | + And user "Alice" has created a public link share with settings + | path | textfile0.txt | + | password | %public% | + | expireDate | +3 days | + | permissions | read | + | name | sharedlink2 | + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Alice" the public shares of file "/textfile0.txt" should be + | path | permissions | name | + | /textfile0.txt | 1 | sharedlink1 | + | /textfile0.txt | 1 | sharedlink2 | + Examples: + | dav-path | + | old | + | new | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | + | spaces | + + @issue-ocis-reva-335 + Scenario Outline: Renaming a folder doesn't remove its public shares + Given using OCS API version "1" + And using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + | password | %public% | + | expireDate | +3 days | + | publicUpload | true | + | permissions | change | + | name | sharedlink1 | + And user "Alice" has created a public link share with settings + | path | FOLDER | + | password | %public% | + | expireDate | +3 days | + | publicUpload | true | + | permissions | change | + | name | sharedlink2 | + When user "Alice" moves folder "/FOLDER" to "/FOLDER_RENAMED" using the WebDAV API + Then the HTTP status code should be "201" + And as user "Alice" the public shares of file "/FOLDER_RENAMED" should be + | path | permissions | name | + | /FOLDER_RENAMED | 15 | sharedlink1 | + | /FOLDER_RENAMED | 15 | sharedlink2 | + Examples: + | dav-path | + | old | + | new | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | + | spaces | diff --git a/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToRoot.feature b/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToRoot.feature new file mode 100644 index 00000000000..6af5feb6b95 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToRoot.feature @@ -0,0 +1,181 @@ +@api @files_sharing-app-required @public_link_share-feature-required @notToImplementOnOCIS +Feature: reshare as public link + As a user + I want to create public link shares from files/folders shared with me + So that I can give controlled access to others + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: creating a public link from a share with read permission only is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "read" + When user "Brian" creates a public link share using the sharing API with settings + | path | /test | + | publicUpload | false | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: creating a public link from a share with share+read only permissions is allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has uploaded file with content "some content" to "/test/file.txt" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + When user "Brian" creates a public link share using the sharing API with settings + | path | /test | + | publicUpload | false | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the old public WebDAV API without password and the content should be "some content" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the new public WebDAV API without password and the content should be "some content" + But uploading a file should not work using the old public WebDAV API + But uploading a file should not work using the new public WebDAV API + + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + Scenario Outline: creating an upload public link from a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + When user "Brian" creates a public link share using the sharing API with settings + | path | /test | + | permissions | read,update,create,delete | + | publicUpload | true | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: creating a public link from a share with read+write permissions only is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "change" + When user "Brian" creates a public link share using the sharing API with settings + | path | /test | + | publicUpload | true | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: creating a public link from a share with share+read+write permissions is allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has uploaded file with content "some content" to "/test/file.txt" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + When user "Brian" creates a public link share using the sharing API with settings + | path | /test | + | publicUpload | false | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the old public WebDAV API without password and the content should be "some content" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the new public WebDAV API without password and the content should be "some content" + But uploading a file should not work using the old public WebDAV API + But uploading a file should not work using the new public WebDAV API + + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + Scenario Outline: creating an upload public link from a share with share+read+write permissions is allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has uploaded file with content "some content" to "/test/file.txt" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + When user "Brian" creates a public link share using the sharing API with settings + | path | /test | + | permissions | read,update,create,delete | + | publicUpload | true | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the old public WebDAV API without password and the content should be "some content" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the new public WebDAV API without password and the content should be "some content" + And uploading a file should work using the old public WebDAV API + And uploading a file should work using the new public WebDAV API + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: creating an upload public link from a sub-folder of a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + When user "Brian" creates a public link share using the sharing API with settings + | path | /test/sub | + | permissions | read,update,create,delete | + | publicUpload | true | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: increasing permissions of a public link of a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has created a public link share with settings + | path | /test | + | permissions | read | + | publicUpload | false | + When user "Brian" updates the last public link share using the sharing API with + | permissions | read,update,create,delete | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And uploading a file should not work using the old public WebDAV API + And uploading a file should not work using the new public WebDAV API + + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: increasing permissions of a public link from a sub-folder of a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has created a public link share with settings + | path | /test/sub | + | permissions | read | + | publicUpload | false | + And uploading a file should not work using the old public WebDAV API + And uploading a file should not work using the new public WebDAV API + When user "Brian" updates the last public link share using the sharing API with + | permissions | read,update,create,delete | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And uploading a file should not work using the old public WebDAV API + And uploading a file should not work using the new public WebDAV API + + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | diff --git a/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature b/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature new file mode 100644 index 00000000000..135a24ce1bb --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature @@ -0,0 +1,184 @@ +@api @files_sharing-app-required @public_link_share-feature-required +Feature: reshare as public link + As a user + I want to create public link shares from files/folders shared with me + So that I can give controlled access to others + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + + + Scenario Outline: creating a public link from a share with read permission only is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "read" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test | + | publicUpload | false | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: creating a public link from a share with share+read only permissions is allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has uploaded file with content "some content" to "/test/file.txt" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test | + | publicUpload | false | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the new public WebDAV API + And the downloaded content should be "some content" + But uploading a file should not work using the new public WebDAV API + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: creating an upload public link from a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test | + | permissions | read,update,create,delete | + | publicUpload | true | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: creating a public link from a share with read+write permissions only is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "change" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test | + | publicUpload | true | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: creating a public link from a share with share+read+write permissions is allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has uploaded file with content "some content" to "/test/file.txt" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test | + | publicUpload | false | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the new public WebDAV API + And the downloaded content should be "some content" + But uploading a file should not work using the new public WebDAV API + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: creating an upload public link from a share with share+read+write permissions is allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has uploaded file with content "some content" to "/test/file.txt" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test | + | permissions | read,update,create,delete | + | publicUpload | true | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the new public WebDAV API + And the downloaded content should be "some content" + And uploading a file should work using the new public WebDAV API + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: creating an upload public link from a sub-folder of a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test/sub | + | permissions | read,update,create,delete | + | publicUpload | true | + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: increasing permissions of a public link of a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + And user "Brian" has created a public link share with settings + | path | /Shares/test | + | permissions | read | + | publicUpload | false | + When user "Brian" updates the last public link share using the sharing API with + | permissions | read,update,create,delete | + Then the OCS status code should be "404" or "403" + And the HTTP status code should be "" or "" + And uploading a file should not work using the new public WebDAV API + Examples: + | ocs_api_version | http_status_code1 | http_status_code2 | + | 1 | 200 | 200 | + | 2 | 404 | 403 | + + + Scenario Outline: increasing permissions of a public link from a sub-folder of a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + And user "Brian" has created a public link share with settings + | path | /Shares/test/sub | + | permissions | read | + | publicUpload | false | + And uploading a file should not work using the new public WebDAV API + When user "Brian" updates the last public link share using the sharing API with + | permissions | read,update,create,delete | + Then the OCS status code should be "404" or "403" + And the HTTP status code should be "" or "" + And uploading a file should not work using the new public WebDAV API + Examples: + | ocs_api_version | http_status_code1 | http_status_code2 | + | 1 | 200 | 200 | + | 2 | 404 | 403 | diff --git a/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesOldDav.feature b/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesOldDav.feature new file mode 100644 index 00000000000..7b478454fb1 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesOldDav.feature @@ -0,0 +1,117 @@ +@api @files_sharing-app-required @public_link_share-feature-required @notToImplementOnOCIS @issue-ocis-2079 +Feature: reshare as public link + As a user + I want to create public link shares from files/folders shared with me + So that I can give controlled access to others + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + + + Scenario Outline: creating a public link from a share with share+read only permissions is allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has uploaded file with content "some content" to "/test/file.txt" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test | + | publicUpload | false | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the old public WebDAV API + And the downloaded content should be "some content" + But uploading a file should not work using the old public WebDAV API + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: creating a public link from a share with share+read+write permissions is allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has uploaded file with content "some content" to "/test/file.txt" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test | + | publicUpload | false | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the old public WebDAV API + And the downloaded content should be "some content" + But uploading a file should not work using the old public WebDAV API + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: creating an upload public link from a share with share+read+write permissions is allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has uploaded file with content "some content" to "/test/file.txt" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + And user "Brian" has accepted share "/test" offered by user "Alice" + When user "Brian" creates a public link share using the sharing API with settings + | path | /Shares/test | + | permissions | read,update,create,delete | + | publicUpload | true | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download file "file.txt" from inside the last public link shared folder using the old public WebDAV API + And the downloaded content should be "some content" + And uploading a file should work using the old public WebDAV API + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: increasing permissions of a public link of a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + And user "Brian" has created a public link share with settings + | path | /Shares/test | + | permissions | read | + | publicUpload | false | + When user "Brian" updates the last public link share using the sharing API with + | permissions | read,update,create,delete | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And uploading a file should not work using the old public WebDAV API + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: increasing permissions of a public link from a sub-folder of a share with share+read only permissions is not allowed + Given using OCS API version "" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + And user "Brian" has created a public link share with settings + | path | /Shares/test/sub | + | permissions | read | + | publicUpload | false | + And uploading a file should not work using the old public WebDAV API + When user "Brian" updates the last public link share using the sharing API with + | permissions | read,update,create,delete | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And uploading a file should not work using the old public WebDAV API + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | diff --git a/tests/acceptance/features/coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature b/tests/acceptance/features/coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature new file mode 100644 index 00000000000..47aea454066 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature @@ -0,0 +1,110 @@ +@api @files_sharing-app-required @notToImplementOnOcis +Feature: public share sharers groups setting + As an admin + I should be able to allow only certain groups to create public links + So that random links are not generated on my file system + + Background: + Given group "grp1" has been created + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "file to share with user" to "/fileToShare.txt" + + + Scenario: users present in public share shares groups can create new public link shares + Given parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes" + And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1"]' + And user "Alice" has been added to group "grp1" + When user "Alice" creates a public link share using the sharing API with settings + | path | fileToShare.txt | + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | file | + | mimetype | text/plain | + | file_target | /fileToShare.txt | + | path | /fileToShare.txt | + | permissions | read | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + + + Scenario: users not present in public share shares groups cannot create a new public link share + Given parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes" + And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1"]' + When user "Alice" creates a public link share using the sharing API with settings + | path | fileToShare.txt | + Then the OCS status code should be "403" + And the HTTP status code should be "200" + And the OCS status message should be "Public link creation is only possible for certain groups" + + + Scenario: existing links can still be updated by sharers even if they are not present in public share sharers groups + Given user "Alice" has created a public link share with settings + | path | /fileToShare.txt | + | permissions | read | + And parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes" + And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1"]' + When user "Alice" updates the last public link share using the sharing API with + | expireDate | +3 days | + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And the fields of the last response to user "Alice" should include + | expiration | +3 days | + + + Scenario: existing links can still be deleted by sharers even if they are not present in public share sharers groups + Given user "Alice" has created a public link share with settings + | path | /fileToShare.txt | + | permissions | read | + | name | shared-link | + And parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes" + And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1"]' + When user "Alice" deletes public link share named "shared-link" in file "fileToShare.txt" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "100" + And as user "Alice" the file "fileToShare.txt" should not have any shares + + + Scenario: creating a new link share is not restricted if no groups are inside the allowed public share sharers groups even if allowlist is enabled + Given parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes" + When user "Alice" creates a public link share using the sharing API with settings + | path | fileToShare.txt | + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | item_type | file | + | mimetype | text/plain | + | file_target | /fileToShare.txt | + | path | /fileToShare.txt | + | permissions | read | + | share_type | public_link | + | displayname_file_owner | %displayname% | + | displayname_owner | %displayname% | + | uid_file_owner | %username% | + | uid_owner | %username% | + | name | | + + + Scenario: multiple groups can be added to public share sharers groups allow list + Given parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has uploaded file with content "file to share with user" to "/fileToShare.txt" + And user "Carol" has uploaded file with content "file to share with user" to "/fileToShare.txt" + And group "grp2" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp2" + And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1", "grp2"]' + When user "Alice" creates a public link share using the sharing API with settings + | path | fileToShare.txt | + And user "Brian" creates a public link share using the sharing API with settings + | path | fileToShare.txt | + And user "Carol" creates a public link share using the sharing API with settings + | path | fileToShare.txt | + Then the HTTP status code of responses on all endpoints should be "200" + And the OCS status code of responses on each endpoint should be "100, 100, 403" respectively + And the OCS status message should be "Public link creation is only possible for certain groups" diff --git a/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature new file mode 100644 index 00000000000..f1dc0b51f57 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature @@ -0,0 +1,612 @@ +@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-252 +Feature: update a public link share + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @issue-37653 @skipOnOcV10 + Scenario Outline: API responds with a full set of parameters when owner changes the expireDate of a public share + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + When user "Alice" updates the last public link share using the sharing API with + | expireDate | +3 days | + Then the OCS status code should be "" + And the OCS status message should be "Ok" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | share_type | public_link | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | read | + | stime | A_NUMBER | + | parent | | + | expiration | A_STRING | + | token | A_STRING | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | additional_info_owner | | + | additional_info_file_owner | | + | item_type | folder | + | item_source | A_STRING | + | path | /FOLDER | + | mimetype | httpd/unix-directory | + | storage_id | A_STRING | + | storage | A_NUMBER | + | file_source | A_STRING | + | file_target | /FOLDER | + | mail_send | 0 | + | name | | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @smokeTest @issue-ocis-reva-336 + Scenario Outline: Creating a new public link share, updating its expiration date and getting its info + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + And user "Alice" has updated the last public link share with + | expireDate | +3 days | + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | public_link | + | file_source | A_STRING | + | file_target | /FOLDER | + | permissions | read | + | stime | A_NUMBER | + | expiration | +3 days | + | token | A_TOKEN | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | url | AN_URL | + | mimetype | httpd/unix-directory | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @notToImplementOnOCIS @issue-39820 + Scenario Outline: API responds with a full set of parameters when owner renames the folder with a public link (bug demonstration) + Given using OCS API version "" + And using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + And user "Alice" has moved folder "/FOLDER" to "/RENAMED_FOLDER" + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | share_type | public_link | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | read | + | stime | A_NUMBER | + | parent | | + | expiration | | + | token | A_STRING | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | additional_info_owner | | + | additional_info_file_owner | | + | item_type | folder | + | item_source | A_STRING | + | path | /RENAMED_FOLDER | + | mimetype | httpd/unix-directory | + | storage_id | A_STRING | + | storage | A_STRING | + | file_source | A_STRING | + # uncomment the following line and remove the next one after the issue has been fixed + # | file_target | /RENAMED_FOLDER | + | file_target | /FOLDER | + | mail_send | 0 | + | name | | + Examples: + | dav-path | ocs_api_version | ocs_status_code | + | old | 1 | 100 | + | old | 2 | 200 | + | new | 1 | 100 | + | new | 2 | 200 | + + + Scenario Outline: Creating a new public link share with password and adding an expiration date using public API + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + And user "Alice" has created a public link share with settings + | path | randomfile.txt | + | password | %public% | + When user "Alice" updates the last public link share using the sharing API with + | expireDate | +3 days | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download the last publicly shared file using the old public WebDAV API with password "%public%" and the content should be "Random data" + And the public should be able to download the last publicly shared file using the new public WebDAV API with password "%public%" and the content should be "Random data" + + @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Creating a new public link share with password and removing (updating) it to make the resources accessible without password using public API + Given using OCS API version "" + And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt" + And user "Alice" has created a public link share with settings + | path | randomfile.txt | + | password | %public% | + When user "Alice" updates the last public link share using the sharing API with + #removing password is basically making password empty + | password | %remove% | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the public should be able to download the last publicly shared file using the old public WebDAV API without a password and the content should be "Random data" + And the public should be able to download the last publicly shared file using the new public WebDAV API without a password and the content should be "Random data" + + @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-336 + Scenario Outline: Creating a new public link share, updating its expiration date and getting its info (ocis Bug demonstration) + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + And user "Alice" has updated the last public link share with + | expireDate | +3 days | + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | public_link | + | file_source | A_STRING | + | file_target | /FOLDER | + | permissions | read | + | stime | A_NUMBER | + | expiration | +3 days | + | token | A_TOKEN | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | url | AN_URL | + | mimetype | httpd/unix-directory | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-336 + Scenario Outline: Creating a new public link share, updating its password and getting its info + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + And user "Alice" has updated the last public link share with + | password | %public% | + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | public_link | + | file_source | A_STRING | + | file_target | /FOLDER | + | permissions | read | + | stime | A_NUMBER | + | token | A_TOKEN | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | url | AN_URL | + | mimetype | httpd/unix-directory | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-336 + Scenario Outline: Creating a new public link share, updating its permissions and getting its info + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + And user "Alice" has updated the last public link share with + | permissions | read,update,create,delete | + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | public_link | + | file_source | A_STRING | + | file_target | /FOLDER | + | permissions | read,update,create,delete | + | stime | A_NUMBER | + | token | A_TOKEN | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | url | AN_URL | + | mimetype | httpd/unix-directory | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-336 + Scenario Outline: Creating a new public link share, updating its permissions to view download and upload and getting its info + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + And user "Alice" has updated the last public link share with + | permissions | read,update,create,delete | + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | public_link | + | file_source | A_STRING | + | file_target | /FOLDER | + | permissions | read,update,create,delete | + | stime | A_NUMBER | + | token | A_TOKEN | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | url | AN_URL | + | mimetype | httpd/unix-directory | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-336 + Scenario Outline: Creating a new public link share, updating publicUpload option and getting its info + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + And user "Alice" has updated the last public link share with + | publicUpload | true | + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | public_link | + | file_source | A_STRING | + | file_target | /FOLDER | + | permissions | read,update,create,delete | + | stime | A_NUMBER | + | token | A_TOKEN | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | url | AN_URL | + | mimetype | httpd/unix-directory | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Adding public upload to a read only shared folder as recipient is not allowed using the public API + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + And user "Brian" has created a public link share with settings + | path | /Shares/test | + | publicUpload | false | + When user "Brian" updates the last public link share using the sharing API with + | publicUpload | true | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And uploading a file should not work using the old public WebDAV API + And uploading a file should not work using the new public WebDAV API + + @issue-ocis-2079 + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + Scenario Outline: Adding public upload to a shared folder as recipient is allowed with permissions using the public API + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + And user "Brian" has accepted share "/test" offered by user "Alice" + And user "Brian" has created a public link share with settings + | path | /Shares/test | + | publicUpload | false | + When user "Brian" updates the last public link share using the sharing API with + | publicUpload | true | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And uploading a file should work using the old public WebDAV API + And uploading a file should work using the new public WebDAV API + + @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Adding public link with all permissions to a read only shared folder as recipient is not allowed using the public API + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/test" offered by user "Alice" + And user "Brian" has created a public link share with settings + | path | /Shares/test | + | permissions | read | + When user "Brian" updates the last public link share using the sharing API with + | permissions | read,update,create,delete | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And uploading a file should not work using the old public WebDAV API + And uploading a file should not work using the new public WebDAV API + + @issue-ocis-2079 + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: Adding public link with all permissions to a read only shared folder as recipient is allowed with permissions using the public API + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + And user "Brian" has accepted share "/test" offered by user "Alice" + And user "Brian" has created a public link share with settings + | path | /Shares/test | + | permissions | read | + When user "Brian" updates the last public link share using the sharing API with + | permissions | read,update,create,delete | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And uploading a file should work using the old public WebDAV API + And uploading a file should work using the new public WebDAV API + + @issue-ocis-2079 + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Updating share permissions from change to read restricts public from deleting files using the public API + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/CHILD/child.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read,update,create,delete | + And user "Alice" has updated the last public link share with + | permissions | read | + When the public deletes file "CHILD/child.txt" from the last public link share using the old public WebDAV API + And the public deletes file "CHILD/child.txt" from the last public link share using the new public WebDAV API + And the HTTP status code of responses on all endpoints should be "403" + And as "Alice" file "PARENT/CHILD/child.txt" should exist + + @issue-ocis-2079 @issue-ocis-reva-292 + Examples: + | ocs_api_version | + | 1 | + | 2 | + + + Scenario Outline: Updating share permissions from read to change allows public to delete files using the public API + Given using OCS API version "" + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/CHILD/child.txt" + And user "Alice" has created a public link share with settings + | path | /PARENT | + | permissions | read | + And user "Alice" has updated the last public link share with + | permissions | read,update,create,delete | + When the public deletes file "CHILD/child.txt" from the last public link share using the public WebDAV API + And the public deletes file "parent.txt" from the last public link share using the public WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" file "PARENT/CHILD/child.txt" should not exist + And as "Alice" file "PARENT/parent.txt" should not exist + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | ocs_api_version | public-webdav-api-version | + | 1 | old | + | 2 | old | + + + Examples: + | ocs_api_version | public-webdav-api-version | + | 1 | new | + | 2 | new | + + @skipOnOcV10 + Scenario Outline: API responds with a full set of parameters when owner renames the folder with a public link in ocis + Given using OCS API version "" + And using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + And user "Alice" has moved folder "/FOLDER" to "/RENAMED_FOLDER" + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | share_type | public_link | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | read | + | stime | A_NUMBER | + | parent | | + | expiration | | + | token | A_STRING | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | item_type | folder | + | item_source | A_STRING | + | path | /RENAMED_FOLDER | + | mimetype | httpd/unix-directory | + | storage_id | A_STRING | + | storage | A_STRING | + | file_source | A_STRING | + | file_target | /RENAMED_FOLDER | + | mail_send | 0 | + | name | | + Examples: + | dav-path | ocs_api_version | ocs_status_code | + | old | 1 | 100 | + | old | 2 | 200 | + | new | 1 | 100 | + | new | 2 | 200 | + + @personalSpace + Examples: + | dav-path | ocs_api_version | ocs_status_code | + | spaces | 1 | 100 | + | spaces | 2 | 200 | + + @notToImplementOnOCIS @issue-39820 + Scenario Outline: API responds with a full set of parameters when owner renames the file with a public link (bug demonstration) + Given using OCS API version "" + And using DAV path + And user "Alice" has uploaded file with content "some content" to "/lorem.txt" + And user "Alice" has created a public link share with settings + | path | lorem.txt | + And user "Alice" has moved file "/lorem.txt" to "/new-lorem.txt" + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | share_type | public_link | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | read | + | stime | A_NUMBER | + | parent | | + | expiration | | + | token | A_STRING | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | additional_info_owner | | + | additional_info_file_owner | | + | item_type | file | + | item_source | A_STRING | + | path | /new-lorem.txt | + | mimetype | text/plain | + | storage_id | A_STRING | + | storage | A_STRING | + | file_source | A_STRING | + # uncomment the following line and remove the next one after the issue has been fixed + # | file_target | /new-lorem.txt | + | file_target | /lorem.txt | + | mail_send | 0 | + | name | | + Examples: + | dav-path | ocs_api_version | ocs_status_code | + | old | 1 | 100 | + | old | 2 | 200 | + | new | 1 | 100 | + | new | 2 | 200 | + + @skipOnOcV10 + Scenario Outline: API responds with a full set of parameters when owner renames the file with a public link in ocis + Given using OCS API version "" + And using DAV path + And user "Alice" has uploaded file with content "some content" to "/lorem.txt" + And user "Alice" has created a public link share with settings + | path | lorem.txt | + And user "Alice" has moved file "/lorem.txt" to "/new-lorem.txt" + When user "Alice" gets the info of the last public link share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | share_type | public_link | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | read | + | stime | A_NUMBER | + | parent | | + | expiration | | + | token | A_STRING | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | item_type | file | + | item_source | A_STRING | + | path | /new-lorem.txt | + | mimetype | text/plain | + | storage_id | A_STRING | + | storage | A_STRING | + | file_source | A_STRING | + | file_target | /new-lorem.txt | + | mail_send | 0 | + | name | | + Examples: + | dav-path | ocs_api_version | ocs_status_code | + | old | 1 | 100 | + | old | 2 | 200 | + | new | 1 | 100 | + | new | 2 | 200 | + + @personalSpace + Examples: + | dav-path | ocs_api_version | ocs_status_code | + | spaces | 1 | 100 | + | spaces | 2 | 200 | diff --git a/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShareOc10Issue37653.feature b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShareOc10Issue37653.feature new file mode 100644 index 00000000000..bea3766b622 --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShareOc10Issue37653.feature @@ -0,0 +1,47 @@ +@api @files_sharing-app-required @public_link_share-feature-required @notToImplementOnOCIS +Feature: update a public link share + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @issue-37653 + Scenario Outline: API responds with a full set of parameters when owner changes the expireDate of a public share + Given using OCS API version "" + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share with settings + | path | FOLDER | + When user "Alice" updates the last public link share using the sharing API with + | expireDate | +3 days | + Then the OCS status code should be "" + And the OCS status message should be "" + #And the OCS status message should be "Ok" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include + | id | A_STRING | + | share_type | public_link | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | read | + | stime | A_NUMBER | + | parent | | + | expiration | A_STRING | + | token | A_STRING | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | additional_info_owner | | + | additional_info_file_owner | | + | item_type | folder | + | item_source | A_STRING | + | path | /FOLDER | + | mimetype | httpd/unix-directory | + | storage_id | A_STRING | + | storage | A_NUMBER | + | file_source | A_STRING | + | file_target | /FOLDER | + | mail_send | 0 | + | name | | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature new file mode 100644 index 00000000000..bedf7e7199c --- /dev/null +++ b/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature @@ -0,0 +1,284 @@ +@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-315 @issue-ocis-reva-316 + +Feature: upload to a public link share + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + + @smokeTest @notToImplementOnOCIS @issue-ocis-2079 + Scenario: Uploading same file to a public upload-only share multiple times via old API + # The old API needs to have the header OC-Autorename: 1 set to do the autorename + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | create | + When the public uploads file "test.txt" with content "test" using the old public WebDAV API + And the public uploads file "test.txt" with content "test2" with auto-rename mode using the old public WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/FOLDER/test.txt" for user "Alice" should be "test" + And the content of file "/FOLDER/test (2).txt" for user "Alice" should be "test2" + + @smokeTest @issue-ocis-reva-286 + Scenario: Uploading same file to a public upload-only share multiple times via new API + # The new API does the autorename automatically in upload-only folders + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | create | + When the public uploads file "test.txt" with content "test" using the new public WebDAV API + And the public uploads file "test.txt" with content "test2" using the new public WebDAV API + Then the HTTP status code of responses on all endpoints should be "201" + And the following headers should match these regular expressions + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/FOLDER/test.txt" for user "Alice" should be "test" + And the content of file "/FOLDER/test (2).txt" for user "Alice" should be "test2" + + + Scenario Outline: Uploading file to a public upload-only share using public API that was deleted does not work + Given using DAV path + And user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | create | + And user "Alice" has deleted folder "/FOLDER" + When the public uploads file "test.txt" with content "test" using the public WebDAV API + And the HTTP status code should be "404" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | dav-path | public-webdav-api-version | + | old | old | + | new | old | + + @issue-ocis-reva-290 + Examples: + | dav-path | public-webdav-api-version | + | old | new | + | new | new | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | public-webdav-api-version | + | spaces | new | + + + Scenario Outline: Uploading file to a public read-only share folder with public API does not work + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | read | + When the public uploads file "test.txt" with content "test" using the public WebDAV API + And the HTTP status code should be "403" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-292 + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Uploading to a public upload-only share with public API + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | create | + When the public uploads file "test.txt" with content "test-file" using the public WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file" + And the following headers should match these regular expressions + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Uploading to a public upload-only share with password with public API + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | password | %public% | + | permissions | create | + When the public uploads file "test.txt" with password "%public%" and content "test-file" using the public WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Uploading to a public read/write share with password with public API + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | password | %public% | + | permissions | change | + When the public uploads file "test.txt" with password "%public%" and content "test-file" using the public WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Uploading file to a public shared folder with read/write permission when the sharer has insufficient quota does not work with public API + When user "Alice" creates a public link share using the sharing API with settings + | path | FOLDER | + | permissions | change | + And the quota of user "Alice" has been set to "0" + When the public uploads file "test.txt" with content "test-file" using the public WebDAV API + Then the HTTP status code should be "507" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-195 + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Uploading file to a public shared folder with upload-only permission when the sharer has insufficient quota does not work with public API + When user "Alice" creates a public link share using the sharing API with settings + | path | FOLDER | + | permissions | create | + And the quota of user "Alice" has been set to "0" + When the public uploads file "test.txt" with content "test-file" using the public WebDAV API + Then the HTTP status code should be "507" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-195 + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Uploading file to a public shared folder does not work when allow public uploads has been disabled after sharing the folder with public API + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | create | + And parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + When the public uploads file "test.txt" with content "test-file" using the public WebDAV API + Then the HTTP status code should be "403" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + | new | + + + Scenario Outline: Uploading file to a public shared folder does not work when allow public uploads has been disabled before sharing and again enabled after sharing the folder with public API + Given parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + And user "Alice" has created a public link share with settings + | path | FOLDER | + And parameter "shareapi_allow_public_upload" of app "core" has been set to "yes" + When the public uploads file "test.txt" with content "test-file" using the public WebDAV API + And the HTTP status code should be "403" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-41 + Examples: + | public-webdav-api-version | + | new | + + + Scenario Outline: Uploading file to a public shared folder works when allow public uploads has been disabled and again enabled after sharing the folder with public API + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | create | + And parameter "shareapi_allow_public_upload" of app "core" has been set to "no" + And parameter "shareapi_allow_public_upload" of app "core" has been set to "yes" + When the public uploads file "test.txt" with content "test-file" using the public WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + @issue-ocis-reva-41 + Examples: + | public-webdav-api-version | + | new | + + @smokeTest + Scenario Outline: Uploading to a public upload-write and no edit and no overwrite share with public API + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | uploadwriteonly | + When the public uploads file "test.txt" with content "test-file" using the public WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file" + + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | public-webdav-api-version | + | old | + + + Examples: + | public-webdav-api-version | + | new | + + @smokeTest @notToImplementOnOCIS @issue-ocis-2079 + Scenario: Uploading same file to a public upload-write and no edit and no overwrite share multiple times with old public API + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | uploadwriteonly | + When the public uploads file "test.txt" with content "test" using the old public WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + When the public uploads file "test.txt" with content "test2" using the old public WebDAV API + # Uncomment these once the issue is fixed + # Then the HTTP status code should be "201" + # And the content of file "/FOLDER/test.txt" for user "Alice" should be "test" + # And the content of file "/FOLDER/test (2).txt" for user "Alice" should be "test2" + Then the HTTP status code should be "403" + And the content of file "/FOLDER/test.txt" for user "Alice" should be "test" + + @smokeTest @issue-ocis-reva-286 + Scenario: Uploading same file to a public upload-write and no edit and no overwrite share multiple times with new public API + Given user "Alice" has created a public link share with settings + | path | FOLDER | + | permissions | uploadwriteonly | + When the public uploads file "test.txt" with content "test" using the new public WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + When the public uploads file "test.txt" with content "test2" using the new public WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/test.txt" for user "Alice" should be "test" + And the content of file "/FOLDER/test (2).txt" for user "Alice" should be "test2" diff --git a/tests/acceptance/features/coreApiShareReshareToRoot1/reShare.feature b/tests/acceptance/features/coreApiShareReshareToRoot1/reShare.feature new file mode 100644 index 00000000000..f6fd4c8614b --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToRoot1/reShare.feature @@ -0,0 +1,275 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + + @smokeTest + Scenario Outline: User is not allowed to reshare file when reshare permission is not given + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update" + When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions "read,update" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" file "/textfile0.txt" should not exist + But as "Brian" file "/textfile0.txt" should exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: User is not allowed to reshare folder when reshare permission is not given + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,update" + When user "Brian" shares folder "/FOLDER" with user "Carol" with permissions "read,update" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/FOLDER" should not exist + But as "Brian" folder "/FOLDER" should exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @smokeTest + Scenario Outline: User is allowed to reshare file with the same permissions + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,read" + When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" file "/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is allowed to reshare folder with the same permissions + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,read" + When user "Brian" shares folder "/FOLDER" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" folder "/FOLDER" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is allowed to reshare file with less permissions + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,update,read" + When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" file "/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is allowed to reshare folder with less permissions + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,update,read" + When user "Brian" shares folder "/FOLDER" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" folder "/FOLDER" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is not allowed to reshare file and set more permissions bits + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions + When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" file "/textfile0.txt" should not exist + But as "Brian" file "/textfile0.txt" should exist + Examples: + | ocs_api_version | http_status_code | received_permissions | reshare_permissions | + # passing on more bits including reshare + | 1 | 200 | 17 | 19 | + | 2 | 404 | 17 | 19 | + | 1 | 200 | 17 | 23 | + | 2 | 404 | 17 | 23 | + | 1 | 200 | 17 | 31 | + | 2 | 404 | 17 | 31 | + # passing on more bits but not reshare + | 1 | 200 | 17 | 3 | + | 2 | 404 | 17 | 3 | + | 1 | 200 | 17 | 7 | + | 2 | 404 | 17 | 7 | + | 1 | 200 | 17 | 15 | + | 2 | 404 | 17 | 15 | + + + Scenario Outline: User is allowed to reshare file and set create (4) or delete (8) permissions bits, which get ignored + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions + When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Brian" sharing with user "Carol" should include + | share_with | %username% | + | file_target | /textfile0.txt | + | path | /textfile0.txt | + | permissions | | + | uid_owner | %username% | + And as "Carol" file "/textfile0.txt" should exist + # The receiver of the reshare can always delete their received share, even though they do not have delete permission + And user "Carol" should be able to delete file "/textfile0.txt" + # But the upstream sharers will still have the file + But as "Brian" file "/textfile0.txt" should exist + And as "Alice" file "/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | received_permissions | reshare_permissions | granted_permissions | + | 1 | 100 | 19 | 23 | 19 | + | 2 | 200 | 19 | 23 | 19 | + | 1 | 100 | 19 | 31 | 19 | + | 2 | 200 | 19 | 31 | 19 | + | 1 | 100 | 19 | 7 | 3 | + | 2 | 200 | 19 | 7 | 3 | + | 1 | 100 | 19 | 15 | 3 | + | 2 | 200 | 19 | 15 | 3 | + | 1 | 100 | 17 | 21 | 17 | + | 2 | 200 | 17 | 21 | 17 | + | 1 | 100 | 17 | 5 | 1 | + | 2 | 200 | 17 | 5 | 1 | + | 1 | 100 | 17 | 25 | 17 | + | 2 | 200 | 17 | 25 | 17 | + | 1 | 100 | 17 | 9 | 1 | + | 2 | 200 | 17 | 9 | 1 | + + + Scenario Outline: User is not allowed to reshare folder and set more permissions bits + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions + When user "Brian" shares folder "/PARENT" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/PARENT" should not exist + But as "Brian" folder "/PARENT" should exist + Examples: + | ocs_api_version | http_status_code | received_permissions | reshare_permissions | + # try to pass on more bits including reshare + | 1 | 200 | 17 | 19 | + | 2 | 404 | 17 | 19 | + | 1 | 200 | 17 | 21 | + | 2 | 404 | 17 | 21 | + | 1 | 200 | 17 | 23 | + | 2 | 404 | 17 | 23 | + | 1 | 200 | 17 | 31 | + | 2 | 404 | 17 | 31 | + | 1 | 200 | 19 | 23 | + | 2 | 404 | 19 | 23 | + | 1 | 200 | 19 | 31 | + | 2 | 404 | 19 | 31 | + # try to pass on more bits but not reshare + | 1 | 200 | 17 | 3 | + | 2 | 404 | 17 | 3 | + | 1 | 200 | 17 | 5 | + | 2 | 404 | 17 | 5 | + | 1 | 200 | 17 | 7 | + | 2 | 404 | 17 | 7 | + | 1 | 200 | 17 | 15 | + | 2 | 404 | 17 | 15 | + | 1 | 200 | 19 | 7 | + | 2 | 404 | 19 | 7 | + | 1 | 200 | 19 | 15 | + | 2 | 404 | 19 | 15 | + + + Scenario Outline: User is not allowed to reshare folder and add delete permission bit (8) + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions + When user "Brian" shares folder "/PARENT" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/PARENT" should not exist + But as "Brian" folder "/PARENT" should exist + Examples: + | ocs_api_version | http_status_code | received_permissions | reshare_permissions | + # try to pass on extra delete (including reshare) + | 1 | 200 | 17 | 25 | + | 2 | 404 | 17 | 25 | + | 1 | 200 | 19 | 27 | + | 2 | 404 | 19 | 27 | + | 1 | 200 | 23 | 31 | + | 2 | 404 | 23 | 31 | + # try to pass on extra delete (but not reshare) + | 1 | 200 | 17 | 9 | + | 2 | 404 | 17 | 9 | + | 1 | 200 | 19 | 11 | + | 2 | 404 | 19 | 11 | + | 1 | 200 | 23 | 15 | + | 2 | 404 | 23 | 15 | + + + Scenario Outline: Reshare a file with same name as a deleted file + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has deleted file "textfile0.txt" + And user "Alice" has uploaded file with content "ownCloud new test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the content of file "/textfile0.txt" for user "Brian" should be "ownCloud new test text file 0" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Reshare a folder with same name as a deleted folder + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Alice" has deleted folder "PARENT" + And user "Alice" has created folder "/PARENT" + When user "Alice" shares folder "PARENT" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" folder "/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Reshare a folder with same name as a deleted file + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has deleted file "textfile0.txt" + And user "Alice" has created folder "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" folder "/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareChain.feature b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareChain.feature new file mode 100644 index 00000000000..61b3262b34b --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareChain.feature @@ -0,0 +1,22 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: resharing can be done on a reshared resource + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario: Reshared files can be still accessed if a user in the middle removes it. + Given user "Carol" has been created with default attributes and without skeleton files + And user "David" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has moved file "/textfile0.txt" to "/textfile0_shared.txt" + And user "Brian" has shared file "textfile0_shared.txt" with user "Carol" + And user "Carol" has shared file "textfile0_shared.txt" with user "David" + When user "Brian" deletes file "/textfile0_shared.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textfile0_shared.txt" for user "Carol" should be "ownCloud test text file 0" + And the content of file "/textfile0_shared.txt" for user "David" should be "ownCloud test text file 0" diff --git a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareDisabled.feature b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareDisabled.feature new file mode 100644 index 00000000000..832fe19a976 --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareDisabled.feature @@ -0,0 +1,38 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: resharing can be disabled + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario Outline: resharing a file is not allowed when allow resharing has been disabled + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,update,read" + And parameter "shareapi_allow_resharing" of app "core" has been set to "no" + When user "Brian" shares file "/textfile0.txt" with user "Carol" with permissions "share,update,read" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" file "/textfile0.txt" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: ordinary sharing is allowed when allow resharing has been disabled + Given using OCS API version "" + And parameter "shareapi_allow_resharing" of app "core" has been set to "no" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares file "/textfile0.txt" with user "Brian" with permissions "share,update,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" file "/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareSubfolder.feature b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareSubfolder.feature new file mode 100644 index 00000000000..69afb8c8926 --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareSubfolder.feature @@ -0,0 +1,143 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: a subfolder of a received share can be reshared + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario Outline: User is allowed to reshare a sub-folder with the same permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read" + When user "Brian" shares folder "/TMP/SUB" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" folder "/SUB" should exist + And as "Brian" folder "/TMP/SUB" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is not allowed to reshare a sub-folder with more permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions + When user "Brian" shares folder "/TMP/SUB" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/SUB" should not exist + But as "Brian" folder "/TMP/SUB" should exist + Examples: + | ocs_api_version | http_status_code | received_permissions | reshare_permissions | + # try to pass on more bits including reshare + | 1 | 200 | 17 | 19 | + | 2 | 404 | 17 | 19 | + | 1 | 200 | 17 | 21 | + | 2 | 404 | 17 | 21 | + | 1 | 200 | 17 | 23 | + | 2 | 404 | 17 | 23 | + | 1 | 200 | 17 | 31 | + | 2 | 404 | 17 | 31 | + | 1 | 200 | 19 | 23 | + | 2 | 404 | 19 | 23 | + | 1 | 200 | 19 | 31 | + | 2 | 404 | 19 | 31 | + # try to pass on more bits but not reshare + | 1 | 200 | 17 | 3 | + | 2 | 404 | 17 | 3 | + | 1 | 200 | 17 | 5 | + | 2 | 404 | 17 | 5 | + | 1 | 200 | 17 | 7 | + | 2 | 404 | 17 | 7 | + | 1 | 200 | 17 | 15 | + | 2 | 404 | 17 | 15 | + | 1 | 200 | 19 | 7 | + | 2 | 404 | 19 | 7 | + | 1 | 200 | 19 | 15 | + | 2 | 404 | 19 | 15 | + # try to pass on extra delete (including reshare) + | 1 | 200 | 17 | 25 | + | 2 | 404 | 17 | 25 | + | 1 | 200 | 19 | 27 | + | 2 | 404 | 19 | 27 | + | 1 | 200 | 23 | 31 | + | 2 | 404 | 23 | 31 | + # try to pass on extra delete (but not reshare) + | 1 | 200 | 17 | 9 | + | 2 | 404 | 17 | 9 | + | 1 | 200 | 19 | 11 | + | 2 | 404 | 19 | 11 | + | 1 | 200 | 23 | 15 | + | 2 | 404 | 23 | 15 | + + + Scenario Outline: User is allowed to update reshare of a sub-folder with less permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has shared folder "/TMP/SUB" with user "Carol" with permissions "share,create,update,read" + When user "Brian" updates the last share using the sharing API with + | permissions | share,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" folder "/SUB" should exist + But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt" + And as "Brian" folder "/TMP/SUB" should exist + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/SUB/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is allowed to update reshare of a sub-folder to the maximum allowed permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has shared folder "/TMP/SUB" with user "Carol" with permissions "share,read" + When user "Brian" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" folder "/SUB" should exist + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt" + And as "Brian" folder "/TMP/SUB" should exist + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/SUB/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is not allowed to update reshare of a sub-folder with more permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read" + And user "Brian" has shared folder "/TMP/SUB" with user "Carol" with permissions "share,read" + When user "Brian" updates the last share using the sharing API with + | permissions | all | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/SUB" should exist + But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt" + And as "Brian" folder "/TMP/SUB" should exist + But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "/TMP/SUB/textfile.txt" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot2/reShareWhenShareWithOnlyMembershipGroups.feature b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareWhenShareWithOnlyMembershipGroups.feature new file mode 100644 index 00000000000..6f8986adb9a --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToRoot2/reShareWhenShareWithOnlyMembershipGroups.feature @@ -0,0 +1,44 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: resharing a resource with an expiration date + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: User should not be able to re-share a folder to a group which he/she is not member of when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/PARENT" + And user "Alice" has shared folder "/PARENT" with user "Brian" + When user "Brian" shares folder "/PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Carol" folder "/PARENT" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | + + + Scenario Outline: User should not be able to re-share a file to a group which he/she is not member of when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + When user "Brian" shares folder "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Carol" folder "/textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot3/reShareUpdate.feature b/tests/acceptance/features/coreApiShareReshareToRoot3/reShareUpdate.feature new file mode 100644 index 00000000000..b53231e3fe6 --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToRoot3/reShareUpdate.feature @@ -0,0 +1,142 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + + + Scenario Outline: Update of reshare can reduce permissions + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,create,update,read" + When user "Brian" updates the last share using the sharing API with + | permissions | share,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Update of reshare can increase permissions to the maximum allowed + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,read" + When user "Brian" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Do not allow update of reshare to exceed permissions + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read" + And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,read" + When user "Brian" updates the last share using the sharing API with + | permissions | all | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: Update of user reshare by the original share owner can increase permissions up to the permissions of the top-level share + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,read" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Update of user reshare by the original share owner can increase permissions to more than the permissions of the top-level share + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read" + And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,read" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Update of group reshare by the original share owner can increase permissions up to permissions of the top-level share + Given using OCS API version "" + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has shared folder "/TMP" with group "grp1" with permissions "share,read" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Update of group reshare by the original share owner can increase permissions to more than the permissions of the top-level share + Given using OCS API version "" + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read" + And user "Brian" has shared folder "/TMP" with group "grp1" with permissions "share,read" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: After losing share permissions user can still delete a previously reshared share + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has shared folder "/TMP" with user "Carol" with permissions "share,create,update,read" + And user "Alice" has updated the last share of "Alice" with + | permissions | create,update,read | + When user "Brian" deletes the last share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should not have any received shares + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToRoot3/reShareWithExpiryDate.feature b/tests/acceptance/features/coreApiShareReshareToRoot3/reShareWithExpiryDate.feature new file mode 100644 index 00000000000..fb7dd11c42d --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToRoot3/reShareWithExpiryDate.feature @@ -0,0 +1,416 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: resharing a resource with an expiration date + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + + + Scenario Outline: User should be able to set expiration while resharing a file with user + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +3 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | +3 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +3 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-194 + Scenario Outline: User should be able to set expiration while resharing a file with group + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + | expireDate | +3 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | +3 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +3 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: resharing with user using the sharing API with expire days set and combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | yes | +30 days | 100 | + | 2 | yes | yes | +30 days | 200 | + | 1 | no | yes | | 100 | + | 2 | no | yes | | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing with group using the sharing API with expire days set and combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | yes | +30 days | 100 | + | 2 | yes | yes | +30 days | 200 | + | 1 | no | yes | | 100 | + | 2 | no | yes | | 200 | + + + Scenario Outline: resharing with user using the sharing API without expire days set and with combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | yes | +7 days | 100 | + | 2 | yes | yes | +7 days | 200 | + | 1 | no | yes | | 100 | + | 2 | no | yes | | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing with group using the sharing API without expire days set and with combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | yes | +7 days | 100 | + | 2 | yes | yes | +7 days | 200 | + | 1 | no | yes | | 100 | + | 2 | no | yes | | 200 | + + + Scenario Outline: resharing with user using the sharing API with expire days set and with combinations of default/enforce expire date enabled and specify expire date in share + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +20 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +20 days | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | ocs_status_code | + | 1 | yes | yes | 100 | + | 2 | yes | yes | 200 | + | 1 | no | yes | 100 | + | 2 | no | yes | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing with group using the sharing API with expire days set and with combinations of default/enforce expire date enabled and specify expire date in share + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + | expireDate | +20 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +20 days | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | ocs_status_code | + | 1 | yes | yes | 100 | + | 2 | yes | yes | 200 | + | 1 | no | yes | 100 | + | 2 | no | yes | 200 | + + + Scenario Outline: Setting default expiry date and enforcement after the share is created + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has shared file "/textfile0.txt" with user "Carol" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "4" + When user "Brian" gets the info of the last share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | ocs_status_code | + | 1 | yes | yes | 100 | + | 2 | yes | yes | 200 | + | 1 | no | yes | 100 | + | 2 | no | yes | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing group share with user using the sharing API with default expire date set and with combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | yes | +30 days | 100 | + | 2 | yes | yes | +30 days | 200 | + | 1 | no | yes | | 100 | + | 2 | no | yes | | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing group share with user using the sharing API with default expire date set and specifying expiration on share and with combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +20 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | yes | +20 days | 100 | + | 2 | yes | yes | +20 days | 200 | + | 1 | no | yes | +20 days | 100 | + | 2 | no | yes | +20 days | 200 | + + + Scenario Outline: resharing using the sharing API with default expire date set but not enforced + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | ocs_status_code | + | 1 | yes | no | 100 | + | 2 | yes | no | 200 | + | 1 | no | no | 100 | + | 2 | no | no | 200 | + + @issue-37013 + Scenario Outline: reshare extends the received expiry date up to the default by default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + | expireDate | +20 days | + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Alice" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | actual-expire-date | ocs_status_code | + | 1 | yes | yes | +30 days | 100 | + | 2 | yes | yes | +30 days | 200 | + | 1 | yes | no | | 100 | + | 2 | yes | no | | 200 | + | 1 | no | no | | 100 | + | 2 | no | no | | 200 | + + @issue-37013 + Scenario Outline: reshare can extend the received expiry date further into the future + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "no" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + | expireDate | +20 days | + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +40 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Alice" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +40 days | + Examples: + | ocs_api_version | default-expire-date | ocs_status_code | + | 1 | yes | 100 | + | 2 | yes | 200 | + | 1 | no | 100 | + | 2 | no | 200 | + + @issue-37013 + Scenario Outline: reshare cannot extend the received expiry date past the default when the default is enforced + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + | expireDate | +20 days | + When user "Brian" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +40 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the information of the last share of user "Alice" should include + | expiration | +20 days | + Examples: + | ocs_api_version | default-expire-date | http_status_code | + | 1 | yes | 200 | + | 2 | yes | 404 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature b/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature new file mode 100644 index 00000000000..17b615b79f3 --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature @@ -0,0 +1,303 @@ +@api @files_sharing-app-required @issue-ocis-1328 +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + + @smokeTest + Scenario Outline: User is not allowed to reshare file when reshare permission is not given + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "read,update" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" file "/Shares/textfile0.txt" should not exist + And the sharing API should report to user "Carol" that no shares are in the pending state + But as "Brian" file "/Shares/textfile0.txt" should exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: User is not allowed to reshare folder when reshare permission is not given + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,update" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "read,update" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/Shares/FOLDER" should not exist + And the sharing API should report to user "Carol" that no shares are in the pending state + But as "Brian" folder "/Shares/FOLDER" should exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @smokeTest + Scenario Outline: User is allowed to reshare file with the same permissions + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And as "Carol" file "/Shares/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is allowed to reshare folder with the same permissions + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to accept pending share "/FOLDER" offered by user "Brian" + And as "Carol" folder "/Shares/FOLDER" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is allowed to reshare file with less permissions + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,update,read" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And as "Carol" file "/Shares/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is allowed to reshare folder with less permissions + Given using OCS API version "" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,update,read" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to accept pending share "/FOLDER" offered by user "Brian" + And as "Carol" folder "/Shares/FOLDER" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: User is not allowed to reshare file and set more permissions bits + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" file "/Shares/textfile0.txt" should not exist + And the sharing API should report to user "Carol" that no shares are in the pending state + But as "Brian" file "/Shares/textfile0.txt" should exist + Examples: + | ocs_api_version | http_status_code | received_permissions | reshare_permissions | + # passing on more bits including reshare + | 1 | 200 | 17 | 19 | + | 2 | 404 | 17 | 19 | + | 1 | 200 | 17 | 23 | + | 2 | 404 | 17 | 23 | + | 1 | 200 | 17 | 31 | + | 2 | 404 | 17 | 31 | + # passing on more bits but not reshare + | 1 | 200 | 17 | 3 | + | 2 | 404 | 17 | 3 | + | 1 | 200 | 17 | 7 | + | 2 | 404 | 17 | 7 | + | 1 | 200 | 17 | 15 | + | 2 | 404 | 17 | 15 | + + + Scenario Outline: User is allowed to reshare file and set create (4) or delete (8) permissions bits, which get ignored + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the fields of the last response to user "Brian" sharing with user "Carol" should include + | share_with | %username% | + | file_target | /Shares/textfile0.txt | + | path | /Shares/textfile0.txt | + | permissions | | + | uid_owner | %username% | + And as "Carol" file "/Shares/textfile0.txt" should exist + # The receiver of the reshare can always delete their received share, even though they do not have delete permission + And user "Carol" should be able to delete file "/Shares/textfile0.txt" + # But the upstream sharers will still have the file + But as "Brian" file "/Shares/textfile0.txt" should exist + And as "Alice" file "/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | received_permissions | reshare_permissions | granted_permissions | + | 1 | 100 | 19 | 23 | 19 | + | 2 | 200 | 19 | 23 | 19 | + | 1 | 100 | 19 | 31 | 19 | + | 2 | 200 | 19 | 31 | 19 | + | 1 | 100 | 19 | 7 | 3 | + | 2 | 200 | 19 | 7 | 3 | + | 1 | 100 | 19 | 15 | 3 | + | 2 | 200 | 19 | 15 | 3 | + | 1 | 100 | 17 | 21 | 17 | + | 2 | 200 | 17 | 21 | 17 | + | 1 | 100 | 17 | 5 | 1 | + | 2 | 200 | 17 | 5 | 1 | + | 1 | 100 | 17 | 25 | 17 | + | 2 | 200 | 17 | 25 | 17 | + | 1 | 100 | 17 | 9 | 1 | + | 2 | 200 | 17 | 9 | 1 | + + + Scenario Outline: User is not allowed to reshare folder and set more permissions bits + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/Shares/PARENT" should not exist + And the sharing API should report to user "Carol" that no shares are in the pending state + But as "Brian" folder "/Shares/PARENT" should exist + Examples: + | ocs_api_version | http_status_code | received_permissions | reshare_permissions | + # try to pass on more bits including reshare + | 1 | 200 | 17 | 19 | + | 2 | 404 | 17 | 19 | + | 1 | 200 | 17 | 21 | + | 2 | 404 | 17 | 21 | + | 1 | 200 | 17 | 23 | + | 2 | 404 | 17 | 23 | + | 1 | 200 | 17 | 31 | + | 2 | 404 | 17 | 31 | + | 1 | 200 | 19 | 23 | + | 2 | 404 | 19 | 23 | + | 1 | 200 | 19 | 31 | + | 2 | 404 | 19 | 31 | + # try to pass on more bits but not reshare + | 1 | 200 | 17 | 3 | + | 2 | 404 | 17 | 3 | + | 1 | 200 | 17 | 5 | + | 2 | 404 | 17 | 5 | + | 1 | 200 | 17 | 7 | + | 2 | 404 | 17 | 7 | + | 1 | 200 | 17 | 15 | + | 2 | 404 | 17 | 15 | + | 1 | 200 | 19 | 7 | + | 2 | 404 | 19 | 7 | + | 1 | 200 | 19 | 15 | + | 2 | 404 | 19 | 15 | + + + Scenario Outline: User is not allowed to reshare folder and add delete permission bit (8) + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/Shares/PARENT" should not exist + And the sharing API should report to user "Carol" that no shares are in the pending state + But as "Brian" folder "/Shares/PARENT" should exist + Examples: + | ocs_api_version | http_status_code | received_permissions | reshare_permissions | + # try to pass on extra delete (including reshare) + | 1 | 200 | 17 | 25 | + | 2 | 404 | 17 | 25 | + | 1 | 200 | 19 | 27 | + | 2 | 404 | 19 | 27 | + | 1 | 200 | 23 | 31 | + | 2 | 404 | 23 | 31 | + # try to pass on extra delete (but not reshare) + | 1 | 200 | 17 | 9 | + | 2 | 404 | 17 | 9 | + | 1 | 200 | 19 | 11 | + | 2 | 404 | 19 | 11 | + | 1 | 200 | 23 | 15 | + | 2 | 404 | 23 | 15 | + + + Scenario Outline: Reshare a file with same name as a deleted file + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Alice" has deleted file "textfile0.txt" + And user "Alice" has uploaded file with content "ownCloud new test text file 0" to "/textfile0.txt" + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "/textfile0.txt" offered by user "Alice" + And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud new test text file 0" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Reshare a folder with same name as a deleted folder + Given using OCS API version "" + And user "Alice" has created folder "/PARENT" + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Alice" has deleted folder "PARENT" + And user "Alice" has created folder "/PARENT" + When user "Alice" shares folder "PARENT" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "/PARENT" offered by user "Alice" + And as "Brian" folder "/Shares/PARENT" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Reshare a folder with same name as a deleted file + Given using OCS API version "" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Alice" has deleted file "/textfile0.txt" + And user "Alice" has created folder "/textfile0.txt" + When user "Alice" shares folder "textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "/textfile0.txt" offered by user "Alice" + And as "Brian" folder "/Shares/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareChain.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareChain.feature new file mode 100644 index 00000000000..62cbc474a7a --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToShares2/reShareChain.feature @@ -0,0 +1,45 @@ +@api @files_sharing-app-required @issue-ocis-2141 +Feature: resharing can be done on a reshared resource + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + | David | + + @notToImplementOnOCIS + Scenario Outline: Reshared files can be still accessed if a user in the middle removes it. + Given user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Brian" has moved file "/Shares/textfile0.txt" to "/textfile0_shared.txt" + And user "Brian" has shared file "/textfile0_shared.txt" with user "Carol" + And user "Carol" has accepted share "" offered by user "Brian" + And user "Carol" has shared file "/Shares/textfile0_shared.txt" with user "David" + And user "David" has accepted share "" offered by user "Carol" + When user "Brian" deletes file "/textfile0_shared.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/Shares/textfile0_shared.txt" for user "Carol" should be "ownCloud test text file 0" + And the content of file "/Shares/textfile0_shared.txt" for user "David" should be "ownCloud test text file 0" + Examples: + | pending_share_path | + | /textfile0_shared.txt | + | /textfile0_shared.txt | + + @skipOnOcV10 + Scenario: Reshared files can be still accessed if a user in the middle removes it. + Given user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Brian" has shared file "/Shares/textfile0.txt" with user "Carol" + And user "Carol" has accepted share "/textfile0.txt" offered by user "Brian" + And user "Carol" has shared file "/Shares/textfile0.txt" with user "David" + And user "David" has accepted share "/textfile0.txt" offered by user "Carol" + When user "Brian" deletes file "/Shares/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/Shares/textfile0.txt" for user "Carol" should be "ownCloud test text file 0" + And the content of file "/Shares/textfile0.txt" for user "David" should be "ownCloud test text file 0" diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareDisabled.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareDisabled.feature new file mode 100644 index 00000000000..1749f5f2b8e --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToShares2/reShareDisabled.feature @@ -0,0 +1,42 @@ +@api @files_sharing-app-required @issue-ocis-1328 +Feature: resharing can be disabled + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + + @smokeTest @skipOnOcis + Scenario Outline: resharing a file is not allowed when allow resharing has been disabled + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,update,read" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And parameter "shareapi_allow_resharing" of app "core" has been set to "no" + When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "share,update,read" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" file "/Shares/textfile0.txt" should not exist + And the sharing API should report to user "Carol" that no shares are in the pending state + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: ordinary sharing is allowed when allow resharing has been disabled + Given using OCS API version "" + And parameter "shareapi_allow_resharing" of app "core" has been set to "no" + When user "Alice" shares file "/textfile0.txt" with user "Brian" with permissions "share,update,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "/textfile0.txt" offered by user "Alice" + And as "Brian" file "/Shares/textfile0.txt" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature new file mode 100644 index 00000000000..326aaf8e13e --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature @@ -0,0 +1,155 @@ +@api @files_sharing-app-required @issue-ocis-1328 +Feature: a subfolder of a received share can be reshared + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest @issue-ocis-2214 + Scenario Outline: User is allowed to reshare a sub-folder with the same permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to accept pending share "" offered by user "Brian" + And as "Carol" folder "/Shares/SUB" should exist + And as "Brian" folder "/Shares/TMP/SUB" should exist + Examples: + | ocs_api_version | ocs_status_code | pending_sub_share_path | + | 1 | 100 | /SUB | + | 2 | 200 | /SUB | + + + Scenario Outline: User is not allowed to reshare a sub-folder with more permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions + And user "Brian" has accepted share "/TMP" offered by user "Alice" + When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/Shares/SUB" should not exist + And the sharing API should report to user "Carol" that no shares are in the pending state + And as "Brian" folder "/Shares/TMP/SUB" should exist + Examples: + | ocs_api_version | http_status_code | received_permissions | reshare_permissions | + # try to pass on more bits including reshare + | 1 | 200 | 17 | 19 | + | 2 | 404 | 17 | 19 | + | 1 | 200 | 17 | 21 | + | 2 | 404 | 17 | 21 | + | 1 | 200 | 17 | 23 | + | 2 | 404 | 17 | 23 | + | 1 | 200 | 17 | 31 | + | 2 | 404 | 17 | 31 | + | 1 | 200 | 19 | 23 | + | 2 | 404 | 19 | 23 | + | 1 | 200 | 19 | 31 | + | 2 | 404 | 19 | 31 | + # try to pass on more bits but not reshare + | 1 | 200 | 17 | 3 | + | 2 | 404 | 17 | 3 | + | 1 | 200 | 17 | 5 | + | 2 | 404 | 17 | 5 | + | 1 | 200 | 17 | 7 | + | 2 | 404 | 17 | 7 | + | 1 | 200 | 17 | 15 | + | 2 | 404 | 17 | 15 | + | 1 | 200 | 19 | 7 | + | 2 | 404 | 19 | 7 | + | 1 | 200 | 19 | 15 | + | 2 | 404 | 19 | 15 | + # try to pass on extra delete (including reshare) + | 1 | 200 | 17 | 25 | + | 2 | 404 | 17 | 25 | + | 1 | 200 | 19 | 27 | + | 2 | 404 | 19 | 27 | + | 1 | 200 | 23 | 31 | + | 2 | 404 | 23 | 31 | + # try to pass on extra delete (but not reshare) + | 1 | 200 | 17 | 9 | + | 2 | 404 | 17 | 9 | + | 1 | 200 | 19 | 11 | + | 2 | 404 | 19 | 11 | + | 1 | 200 | 23 | 15 | + | 2 | 404 | 23 | 15 | + + @issue-ocis-2214 + Scenario Outline: User is allowed to update reshare of a sub-folder with less permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,create,update,read" + And user "Carol" has accepted share "" offered by user "Brian" + When user "Brian" updates the last share using the sharing API with + | permissions | share,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" folder "/Shares/SUB" should exist + But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt" + And as "Brian" folder "/Shares/TMP/SUB" should exist + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | pending_sub_share_path | + | 1 | 100 | /SUB | + | 2 | 200 | /SUB | + + @issue-ocis-2214 + Scenario Outline: User is allowed to update reshare of a sub-folder to the maximum allowed permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read" + And user "Carol" has accepted share "" offered by user "Brian" + When user "Brian" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Carol" folder "/Shares/SUB" should exist + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt" + And as "Brian" folder "/Shares/TMP/SUB" should exist + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | pending_sub_share_path | + | 1 | 100 | /SUB | + | 2 | 200 | /SUB | + + @issue-ocis-2214 + Scenario Outline: User is not allowed to update reshare of a sub-folder with more permissions + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/TMP" + And user "Alice" has created folder "/TMP/SUB" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read" + And user "Carol" has accepted share "" offered by user "Brian" + When user "Brian" updates the last share using the sharing API with + | permissions | all | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And as "Carol" folder "/Shares/SUB" should exist + But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt" + And as "Brian" folder "/Shares/TMP/SUB" should exist + But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt" + Examples: + | ocs_api_version | http_status_code | pending_sub_share_path | + | 1 | 200 | /SUB | + | 2 | 404 | /SUB | diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareWhenShareWithOnlyMembershipGroups.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareWhenShareWithOnlyMembershipGroups.feature new file mode 100644 index 00000000000..0e4b2410faf --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToShares2/reShareWhenShareWithOnlyMembershipGroups.feature @@ -0,0 +1,48 @@ +@api @files_sharing-app-required @issue-ocis-1289 @issue-ocis-reva-194 @issue-ocis-1328 @skipOnOcis +Feature: resharing a resource with an expiration date + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: User should not be able to re-share a folder to a group which he/she is not member of when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/PARENT" + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" shares folder "/Shares/PARENT" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Carol" folder "/Shares/PARENT" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | + + + Scenario Outline: User should not be able to re-share a file to a group which he/she is not member of when share with only member group is enabled + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" shares folder "/Shares/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Carol" folder "/Shares/textfile0.txt" should not exist + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 403 | 200 | + | 2 | 403 | 403 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares3/reShareUpdate.feature b/tests/acceptance/features/coreApiShareReshareToShares3/reShareUpdate.feature new file mode 100644 index 00000000000..d8447d45319 --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToShares3/reShareUpdate.feature @@ -0,0 +1,160 @@ +@api @files_sharing-app-required @issue-ocis-1328 +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + + + Scenario Outline: Update of reshare can reduce permissions + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read" + And user "Carol" has accepted share "/TMP" offered by user "Brian" + When user "Brian" updates the last share using the sharing API with + | permissions | share,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Update of reshare can increase permissions to the maximum allowed + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read" + And user "Carol" has accepted share "/TMP" offered by user "Brian" + When user "Brian" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Do not allow update of reshare to exceed permissions + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read" + And user "Carol" has accepted share "/TMP" offered by user "Brian" + When user "Brian" updates the last share using the sharing API with + | permissions | all | + Then the OCS status code should be "404" + And the HTTP status code should be "" + And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: Update of user reshare by the original share owner can increase permissions up to the permissions of the top-level share + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read" + And user "Carol" has accepted share "/TMP" offered by user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Update of user reshare by the original share owner can increase permissions to more than the permissions of the top-level share + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read" + And user "Carol" has accepted share "/TMP" offered by user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Update of group reshare by the original share owner can increase permissions up to permissions of the top-level share + Given using OCS API version "" + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "Shares/TMP" with group "grp1" with permissions "share,read" + And user "Carol" has accepted share "/TMP" offered by user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Update of group reshare by the original share owner can increase permissions to more than the permissions of the top-level share + Given using OCS API version "" + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "Shares/TMP" with group "grp1" with permissions "share,read" + And user "Carol" has accepted share "/TMP" offered by user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | share,create,update,read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: After losing share permissions user can still delete a previously reshared share + Given using OCS API version "" + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read" + And user "Carol" has accepted share "/TMP" offered by user "Brian" + And user "Alice" has updated the last share of "Alice" with + | permissions | create,update,read | + When user "Brian" deletes the last share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should not have any received shares + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDate.feature b/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDate.feature new file mode 100644 index 00000000000..5cbef9a893d --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDate.feature @@ -0,0 +1,445 @@ +@api @files_sharing-app-required @issue-ocis-1328 +Feature: resharing a resource with an expiration date + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + + + Scenario Outline: User should be able to set expiration while resharing a file with user + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +3 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | +3 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +3 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-194 + Scenario Outline: User should be able to set expiration while resharing a file with group + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + | expireDate | +3 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | +3 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +3 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: resharing with user using the sharing API with expire days set and combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | +30 days | 100 | + | 2 | yes | +30 days | 200 | + | 1 | no | | 100 | + | 2 | no | | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing with group using the sharing API with expire days set and combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | +30 days | 100 | + | 2 | yes | +30 days | 200 | + | 1 | no | | 100 | + | 2 | no | | 200 | + + + Scenario Outline: resharing with user using the sharing API without expire days set and with combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | +7 days | 100 | + | 2 | yes | +7 days | 200 | + | 1 | no | | 100 | + | 2 | no | | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing with group using the sharing API without expire days set and with combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | +7 days | 100 | + | 2 | yes | +7 days | 200 | + | 1 | no | | 100 | + | 2 | no | | 200 | + + + Scenario Outline: resharing with user using the sharing API with expire days set and with combinations of default/enforce expire date enabled and specify expire date in share + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +20 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +20 days | + Examples: + | ocs_api_version | default-expire-date | ocs_status_code | + | 1 | yes | 100 | + | 2 | yes | 200 | + | 1 | no | 100 | + | 2 | no | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing with group using the sharing API with expire days set and with combinations of default/enforce expire date enabled and specify expire date in share + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Carol" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | group | + | permissions | change | + | shareWith | grp1 | + | expireDate | +20 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +20 days | + Examples: + | ocs_api_version | default-expire-date | ocs_status_code | + | 1 | yes | 100 | + | 2 | yes | 200 | + | 1 | no | 100 | + | 2 | no | 200 | + + + Scenario Outline: Setting default expiry date and enforcement after the share is created + Given using OCS API version "" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Brian" has shared file "/Shares/textfile0.txt" with user "Carol" + And user "Carol" has accepted share "/textfile0.txt" offered by user "Brian" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "4" + When user "Brian" gets the info of the last share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | ocs_status_code | + | 1 | yes | 100 | + | 2 | yes | 200 | + | 1 | no | 100 | + | 2 | no | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing group share with user using the sharing API with default expire date set and with combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | expected-expire-date | ocs_status_code | + | 1 | yes | +30 days | 100 | + | 2 | yes | +30 days | 200 | + | 1 | no | | 100 | + | 2 | no | | 200 | + + @issue-ocis-reva-194 + Scenario Outline: resharing group share with user using the sharing API with default expire date set and specifying expiration on share and with combinations of default/enforce expire date enabled + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And group "grp1" has been created + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +20 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +20 days | + Examples: + | ocs_api_version | default-expire-date | ocs_status_code | + | 1 | yes | 100 | + | 2 | yes | 200 | + | 1 | no | 100 | + | 2 | no | 200 | + + + Scenario Outline: resharing using the sharing API with default expire date set but not enforced + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "no" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Brian" should include + | expiration | | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | ocs_status_code | + | 1 | yes | 100 | + | 2 | yes | 200 | + | 1 | no | 100 | + | 2 | no | 200 | + + @skipOnOcV10 @issue-37013 + Scenario Outline: reshare extends the received expiry date up to the default by default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + | expireDate | +20 days | + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Alice" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +20 | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | ocs_status_code | + | 1 | yes | yes | 100 | + | 2 | yes | yes | 200 | + | 1 | yes | no | 100 | + | 2 | yes | no | 200 | + | 1 | no | no | 100 | + | 2 | no | no | 200 | + + @skipOnOcV10 @issue-37013 + Scenario Outline: reshare cannot extend the received expiry date further into the future + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "no" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + | expireDate | +20 days | + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +40 days | + #The action of changing the expiration date while resharing should be forbidden + Then the HTTP status code should be "403" + And the OCS status code should be "403" + And the information of the last share of user "Alice" should include + | expiration | +20 days | + Examples: + | ocs_api_version | default-expire-date | + | 1 | yes | + | 2 | yes | + | 1 | no | + | 2 | no | + + @skipOnOcV10 @issue-37013 + Scenario Outline: reshare cannot extend the received expiry date past the default when the default is enforced + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + | expireDate | +20 days | + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +40 days | + Then the HTTP status code should be "403" + And the OCS status code should be "403" + And the information of the last share of user "Alice" should include + | expiration | +20 days | + Examples: + | ocs_api_version | + | 1 | + | 2 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDateOc10Issue37013.feature b/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDateOc10Issue37013.feature new file mode 100644 index 00000000000..bce4ee0a155 --- /dev/null +++ b/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDateOc10Issue37013.feature @@ -0,0 +1,110 @@ +@api @files_sharing-app-required @issue-ocis-1250 @notToImplementOnOCIS +Feature: resharing a resource with an expiration date + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + + @issue-37013 + Scenario Outline: reshare extends the received expiry date up to the default by default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + | expireDate | +20 days | + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Alice" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | default-expire-date | enforce-expire-date | actual-expire-date | ocs_status_code | + | 1 | yes | yes | +30 days | 100 | + | 2 | yes | yes | +30 days | 200 | + | 1 | yes | no | | 100 | + | 2 | yes | no | | 200 | + | 1 | no | no | | 100 | + | 2 | no | no | | 200 | + + @issue-37013 + Scenario Outline: reshare can extend the received expiry date further into the future + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "no" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + | expireDate | +20 days | + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +40 days | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" + And the information of the last share of user "Alice" should include + | expiration | +20 days | + And the response when user "Carol" gets the info of the last share should include + | expiration | +40 days | + Examples: + | ocs_api_version | default-expire-date | ocs_status_code | + | 1 | yes | 100 | + | 2 | yes | 200 | + | 1 | no | 100 | + | 2 | no | 200 | + + @issue-37013 + Scenario Outline: reshare cannot extend the received expiry date past the default when the default is enforced + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + | expireDate | +20 days | + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" creates a share using the sharing API with settings + | path | /Shares/textfile0.txt | + | shareType | user | + | permissions | change | + | shareWith | Carol | + | expireDate | +40 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the sharing API should report to user "Carol" that no shares are in the pending state + And the information of the last share of user "Alice" should include + | expiration | +20 days | + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | diff --git a/tests/acceptance/features/coreApiShareUpdateToRoot/updateShare.feature b/tests/acceptance/features/coreApiShareUpdateToRoot/updateShare.feature new file mode 100644 index 00000000000..29188e4c748 --- /dev/null +++ b/tests/acceptance/features/coreApiShareUpdateToRoot/updateShare.feature @@ -0,0 +1,315 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: sharing + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: Allow modification of reshare + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "TMP" with user "Brian" + And user "Brian" has shared folder "TMP" with user "Carol" + When user "Brian" updates the last share using the sharing API with + | permissions | read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile.txt" + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: keep group permissions in sync + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And user "Brian" has created folder "FOLDER" + And user "Brian" has moved file "/textfile0.txt" to "/FOLDER/textfile0.txt" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | group | + | file_source | A_STRING | + | file_target | /textfile0.txt | + | permissions | read | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | mimetype | text/plain | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Cannot set permissions to zero + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with group "grp1" + When user "Alice" updates the last share using the sharing API with + | permissions | 0 | + Then the OCS status code should be "400" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + + Scenario Outline: Cannot update a share of a file with a user to have only create and/or delete permission + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | | + Then the OCS status code should be "400" + And the HTTP status code should be "" + # Brian should still have at least read access to the shared file + And as "Brian" entry "textfile0.txt" should exist + Examples: + | ocs_api_version | http_status_code | permissions | + | 1 | 200 | create | + | 2 | 400 | create | + | 1 | 200 | delete | + | 2 | 400 | delete | + | 1 | 200 | create,delete | + | 2 | 400 | create,delete | + + + Scenario Outline: Cannot update a share of a file with a group to have only create and/or delete permission + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + When user "Alice" updates the last share using the sharing API with + | permissions | | + Then the OCS status code should be "400" + And the HTTP status code should be "" + # Brian in grp1 should still have at least read access to the shared file + And as "Brian" entry "textfile0.txt" should exist + Examples: + | ocs_api_version | http_status_code | permissions | + | 1 | 200 | create | + | 2 | 400 | create | + | 1 | 200 | delete | + | 2 | 400 | delete | + | 1 | 200 | create,delete | + | 2 | 400 | create,delete | + + @skipOnFilesClassifier @issue-files-classifier-291 + Scenario: Share ownership change after moving a shared file outside of an outer share + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "/folder1" + And user "Alice" has created folder "/folder1/folder2" + And user "Brian" has created folder "/moved-out" + And user "Alice" has shared folder "/folder1" with user "Brian" with permissions "all" + And user "Brian" has shared folder "/folder1/folder2" with user "Carol" with permissions "all" + When user "Brian" moves folder "/folder1/folder2" to "/moved-out/folder2" using the WebDAV API + Then the HTTP status code should be "201" + And the response when user "Brian" gets the info of the last share should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | user | + | file_source | A_STRING | + | file_target | /folder2 | + | permissions | all | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | mimetype | httpd/unix-directory | + And as "Alice" folder "/folder1/folder2" should not exist + And as "Carol" folder "/folder2" should exist + + + Scenario: Share ownership change after moving a shared file to another share + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "/Alice-folder" + And user "Alice" has created folder "/Alice-folder/folder2" + And user "Carol" has created folder "/Carol-folder" + And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all" + And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all" + When user "Brian" moves folder "/Alice-folder/folder2" to "/Carol-folder/folder2" using the WebDAV API + Then the HTTP status code should be "201" + And the response when user "Carol" gets the info of the last share should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | user | + | file_source | A_STRING | + | file_target | /Carol-folder | + | permissions | all | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | mimetype | httpd/unix-directory | + And as "Alice" folder "/Alice-folder/folder2" should not exist + And as "Carol" folder "/Carol-folder/folder2" should exist + + + Scenario Outline: Increasing permissions is allowed for owner + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Carol" has created folder "/FOLDER" + And user "Carol" has shared folder "/FOLDER" with group "grp1" + And user "Carol" has updated the last share with + | permissions | read | + When user "Carol" updates the last share using the sharing API with + | permissions | all | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "FOLDER/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Forbid sharing with groups + Given using OCS API version "" + And group "grp1" has been created + And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: Editing share permission of existing share is forbidden when sharing with groups is forbidden + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + When user "Alice" updates the last share using the sharing API with + | permissions | read, create | + Then the OCS status code should be "400" + And the HTTP status code should be "" + And the response when user "Alice" gets the info of the last share should include + | item_type | file | + | item_source | A_STRING | + | share_type | group | + | file_target | /textfile0.txt | + | permissions | read, update, share | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + + Scenario Outline: Deleting group share is allowed when sharing with groups is forbidden + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + When user "Alice" deletes the last share using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + When user "Alice" gets the info of the last share using the sharing API + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the last response should be empty + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 404 | + + + Scenario Outline: user can update the role in an existing share after the system maximum expiry date has been reduced + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +30 days | + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "5" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the response when user "Alice" gets the info of the last share should include + | permissions | read | + | expiration | +30 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: user cannot concurrently update the role and date in an existing share after the system maximum expiry date has been reduced + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +30 days | + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "10" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + | expireDate | +28 days | + Then the OCS status message should be "Cannot set expiration date more than 10 days in the future" + And the HTTP status code should be "" + And the OCS status code should be "404" + And the response when user "Brian" gets the info of the last share should include + | permissions | read, share | + | expiration | +30 days | + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | diff --git a/tests/acceptance/features/coreApiShareUpdateToRoot/updateShareGroupAndUserWithSameName.feature b/tests/acceptance/features/coreApiShareUpdateToRoot/updateShareGroupAndUserWithSameName.feature new file mode 100644 index 00000000000..acee69c2f9a --- /dev/null +++ b/tests/acceptance/features/coreApiShareUpdateToRoot/updateShareGroupAndUserWithSameName.feature @@ -0,0 +1,49 @@ +@api @files_sharing-app-required @notToImplementOnOCIS +Feature: updating shares to users and groups that have the same name + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + And group "Brian" has been created + And user "Carol" has been added to group "Brian" + And user "Alice" has created folder "/TMP" + And user "Alice" has uploaded file with content "Random data" to "/TMP/randomfile.txt" + + @skipOnLDAP + Scenario Outline: update permissions of a user share with a user and a group having the same name + Given using OCS API version "" + And user "Alice" has shared folder "/TMP" with group "Brian" + And user "Alice" has shared folder "/TMP" with user "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the content of file "/TMP/randomfile.txt" for user "Brian" should be "Random data" + And the content of file "/TMP/randomfile.txt" for user "Carol" should be "Random data" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile-by-Carol.txt" + But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile-by-Brian.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnLDAP + Scenario Outline: update permissions of a group share with a user and a group having the same name + Given using OCS API version "" + And user "Alice" has shared folder "/TMP" with user "Brian" + And user "Alice" has shared folder "/TMP" with group "Brian" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the content of file "/TMP/randomfile.txt" for user "Brian" should be "Random data" + And the content of file "/TMP/randomfile.txt" for user "Carol" should be "Random data" + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile-by-Carol.txt" + But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "TMP/textfile-by-Brian.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature new file mode 100644 index 00000000000..15e1192eac9 --- /dev/null +++ b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature @@ -0,0 +1,441 @@ +@api @files_sharing-app-required +Feature: sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: Allow modification of reshare + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "/TMP" + And user "Alice" has shared folder "TMP" with user "Brian" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has shared folder "/Shares/TMP" with user "Carol" + And user "Carol" has accepted share "/TMP" offered by user "Brian" + When user "Brian" updates the last share using the sharing API with + | permissions | read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/textfile.txt" + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-1289 @notToImplementOnOCIS + Scenario Outline: keep group permissions in sync when the share is moved to another folder by the receiver and then the sharer updates the permissions + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Brian" has created folder "/FOLDER" + And user "Brian" has moved file "/Shares/textfile0.txt" to "/FOLDER/textfile0.txt" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | group | + | file_source | A_STRING | + | file_target | /Shares/textfile0.txt | + | permissions | read | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | mimetype | text/plain | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-1289 + Scenario Outline: keep group permissions in sync when the share is renamed by the receiver and then the permissions are updated by sharer + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Brian" has moved file "/Shares/textfile0.txt" to "/Shares/textfile_new.txt" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with group "grp1" should include + | id | A_STRING | + | item_type | file | + | item_source | A_STRING | + | share_type | group | + | file_source | A_STRING | + | file_target | /Shares/textfile0.txt | + | permissions | read | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | mimetype | text/plain | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Cannot set permissions to zero + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with group "grp1" + When user "Alice" updates the last share using the sharing API with + | permissions | 0 | + Then the OCS status code should be "400" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + @issue-ocis-2173 + Scenario Outline: Cannot update a share of a file with a user to have only create and/or delete permission + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | | + Then the OCS status code should be "400" + And the HTTP status code should be "" + # Brian should still have at least read access to the shared file + And as "Brian" entry "/Shares/textfile0.txt" should exist + Examples: + | ocs_api_version | http_status_code | permissions | + | 1 | 200 | create | + | 2 | 400 | create | + | 1 | 200 | delete | + | 2 | 400 | delete | + | 1 | 200 | create,delete | + | 2 | 400 | create,delete | + + @issue-ocis-2173 + Scenario Outline: Cannot update a share of a file with a group to have only create and/or delete permission + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | | + Then the OCS status code should be "400" + And the HTTP status code should be "" + # Brian in grp1 should still have at least read access to the shared file + And as "Brian" entry "/Shares/textfile0.txt" should exist + Examples: + | ocs_api_version | http_status_code | permissions | + | 1 | 200 | create | + | 2 | 400 | create | + | 1 | 200 | delete | + | 2 | 400 | delete | + | 1 | 200 | create,delete | + | 2 | 400 | create,delete | + + @skipOnFilesClassifier @issue-files-classifier-291 @toFixOnOCIS @issue-ocis-2201 + Scenario Outline: Share ownership change after moving a shared file outside of an outer share + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "/folder1" + And user "Alice" has created folder "/folder1/folder2" + And user "Brian" has created folder "/moved-out" + And user "Alice" has shared folder "/folder1" with user "Brian" with permissions "all" + And user "Brian" has accepted share "/folder1" offered by user "Alice" + And user "Brian" has shared folder "/Shares/folder1/folder2" with user "Carol" with permissions "all" + And user "Carol" has accepted share "" offered by user "Brian" + When user "Brian" moves folder "/Shares/folder1/folder2" to "/moved-out/folder2" using the WebDAV API + Then the HTTP status code should be "201" + And the response when user "Brian" gets the info of the last share should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | user | + | file_source | A_STRING | + | file_target | /Shares/folder2 | + | permissions | all | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | mimetype | httpd/unix-directory | + And as "Alice" folder "/Shares/folder1/folder2" should not exist + And as "Carol" folder "/Shares/folder2" should exist + Examples: + | folder2_share_path | + | /folder2 | + + + Scenario Outline: Share ownership change after moving a shared file to another share + Given these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Alice" has created folder "/Alice-folder" + And user "Alice" has created folder "/Alice-folder/folder2" + And user "Carol" has created folder "/Carol-folder" + And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all" + And user "Brian" has accepted share "/Alice-folder" offered by user "Alice" + And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all" + And user "Brian" has accepted share "/Carol-folder" offered by user "Carol" + When user "Brian" moves folder "/Shares/Alice-folder/folder2" to "/Shares/Carol-folder/folder2" using the WebDAV API + Then the HTTP status code should be "201" + And the response when user "Carol" gets the info of the last share should include + | id | A_STRING | + | item_type | folder | + | item_source | A_STRING | + | share_type | user | + | file_source | A_STRING | + | file_target | | + | permissions | all | + | stime | A_NUMBER | + | storage | A_STRING | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | mimetype | httpd/unix-directory | + And as "Alice" folder "/Alice-folder/folder2" should not exist + And as "Carol" folder "/Carol-folder/folder2" should exist + @skipOnOcis + Examples: + | path | + | /Shares/Carol-folder | + + @skipOnOcV10 @issue-2442 + Examples: + | path | + | /Carol-folder | + + @toFixOnOCIS @toFixOnOcV10 @issue-ocis-reva-349 @issue-ocis-reva-350 @issue-ocis-reva-352 @issue-37653 + #after fixing all the issues merge this scenario with the one below + Scenario Outline: API responds with a full set of parameters when owner changes the permission of a share + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/Alice-folder" + And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "read" + When user "Alice" updates the last share using the sharing API with + | permissions | all | + Then the OCS status code should be "" + And the OCS status message should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | id | A_STRING | + | share_type | user | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | permissions | all | + | stime | A_NUMBER | + | parent | | + | expiration | | + | token | | + | uid_file_owner | %username% | + | displayname_file_owner | %displayname% | + | additional_info_owner | | + | additional_info_file_owner | | + | item_type | folder | + | item_source | A_STRING | + | path | /Alice-folder | + | mimetype | httpd/unix-directory | + | storage_id | A_STRING | + | storage | A_STRING | + | file_source | A_STRING | + | file_target | /Shares/Alice-folder | + | share_with | %username% | + | share_with_displayname | %displayname% | + | share_with_additional_info | | + | mail_send | 0 | + | attributes | | + And the fields of the last response should not include + | name | | + # | token | | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + + Scenario Outline: Increasing permissions is allowed for owner + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Carol" has created folder "/FOLDER" + And user "Carol" has shared folder "/FOLDER" with group "grp1" + And user "Brian" has accepted share "/FOLDER" offered by user "Carol" + And user "Carol" has updated the last share with + | permissions | read | + When user "Carol" updates the last share using the sharing API with + | permissions | all | + Then the OCS status code should be "" + And the HTTP status code should be "200" + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-1328 @skipOnOcis + Scenario Outline: Forbid sharing with groups + Given using OCS API version "" + And group "grp1" has been created + And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @issue-ocis-1328 @skipOnOcis + Scenario Outline: Editing share permission of existing share is forbidden when sharing with groups is forbidden + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + When user "Alice" updates the last share using the sharing API with + | permissions | read, create | + Then the OCS status code should be "400" + And the HTTP status code should be "" + And the response when user "Alice" gets the info of the last share should include + | item_type | file | + | item_source | A_STRING | + | share_type | group | + | file_target | /Shares/textfile0.txt | + | permissions | read, update, share | + | mail_send | 0 | + | uid_owner | %username% | + | displayname_owner | %displayname% | + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 400 | + + @issue-ocis-1328 @skipOnOcis + Scenario Outline: Deleting group share is allowed when sharing with groups is forbidden + Given using OCS API version "" + And group "grp1" has been created + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with group "grp1" + And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + When user "Alice" deletes the last share using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + When user "Alice" gets the info of the last share using the sharing API + Then the OCS status code should be "404" + And the HTTP status code should be "" + And the last response should be empty + Examples: + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 404 | + + @issue-ocis-1328 @skipOnOcis + Scenario Outline: user can update the role in an existing share after the system maximum expiry date has been reduced + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +30 days | + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "5" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include + | permissions | read | + | expiration | +30 days | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-1328 @skipOnOcis + Scenario Outline: user cannot concurrently update the role and date in an existing share after the system maximum expiry date has been reduced + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has created a share with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +30 days | + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "10" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + | expireDate | +28 days | + Then the OCS status message should be "Cannot set expiration date more than 10 days in the future" + And the HTTP status code should be "" + And the OCS status code should be "404" + And the response when user "Alice" gets the info of the last share should include + | permissions | read, share | + | expiration | +30 days | + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + + Scenario Outline: Sharer deletes file uploaded with upload-only permission by sharee to a shared folder + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created a share with settings + | path | FOLDER | + | shareType | user | + | permissions | create | + | shareWith | Brian | + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And user "Brian" has uploaded file with content "some content" to "/Shares/FOLDER/textFile.txt" + When user "Alice" deletes file "/FOLDER/textFile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" file "/Shares/FOLDER/textFile.txt" should not exist + And as "Alice" file "/textFile.txt" should not exist + Examples: + | dav-path | + | old | + | new | diff --git a/tests/acceptance/features/coreApiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature b/tests/acceptance/features/coreApiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature new file mode 100644 index 00000000000..090d8c2f3cc --- /dev/null +++ b/tests/acceptance/features/coreApiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature @@ -0,0 +1,55 @@ +@api @files_sharing-app-required @issue-ocis-1289 @issue-ocis-1328 +Feature: updating shares to users and groups that have the same name + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + And group "Brian" has been created + And user "Carol" has been added to group "Brian" + And user "Alice" has created folder "/TMP" + And user "Alice" has uploaded file with content "Random data" to "/TMP/randomfile.txt" + + @skipOnLDAP + Scenario Outline: update permissions of a user share with a user and a group having the same name + Given using OCS API version "" + And user "Alice" has shared folder "/TMP" with group "Brian" + And user "Alice" has shared folder "/TMP" with user "Brian" + And user "Carol" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the content of file "/Shares/TMP/randomfile.txt" for user "Brian" should be "Random data" + And the content of file "/Shares/TMP/randomfile.txt" for user "Carol" should be "Random data" + And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile-by-Carol.txt" + But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile-by-Brian.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @skipOnLDAP + Scenario Outline: update permissions of a group share with a user and a group having the same name + Given using OCS API version "" + And user "Alice" has shared folder "/TMP" with user "Brian" + And user "Alice" has shared folder "/TMP" with group "Brian" + And user "Carol" has accepted share "/TMP" offered by user "Alice" + And user "Brian" has accepted share "/TMP" offered by user "Alice" + When user "Alice" updates the last share using the sharing API with + | permissions | read | + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the content of file "/Shares/TMP/randomfile.txt" for user "Brian" should be "Random data" + And the content of file "/Shares/TMP/randomfile.txt" for user "Carol" should be "Random data" + And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile-by-Carol.txt" + But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile-by-Brian.txt" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/coreApiSharees/sharees.feature b/tests/acceptance/features/coreApiSharees/sharees.feature new file mode 100644 index 00000000000..e86128c1707 --- /dev/null +++ b/tests/acceptance/features/coreApiSharees/sharees.feature @@ -0,0 +1,726 @@ +@api @files_sharing-app-required @issue-ocis-reva-34 +Feature: sharees + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | sharee1 | + And group "ShareeGroup" has been created + And group "ShareeGroup2" has been created + And user "Alice" has been added to group "ShareeGroup2" + + @smokeTest + Scenario Outline: Search without exact match + Given using OCS API version "" + When user "Alice" gets the sharees using the sharing API with parameters + | search | sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be + | ShareeGroup | 1 | ShareeGroup | + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: Search without exact match not-exact casing + Given using OCS API version "" + When user "Alice" gets the sharees using the sharing API with parameters + | search | sHaRee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be + | ShareeGroup | 1 | ShareeGroup | + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Search only with group members - denied + Given using OCS API version "" + And parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" + When user "Alice" gets the sharees using the sharing API with parameters + | search | sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be + | ShareeGroup | 1 | ShareeGroup | + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @skipOnLDAP + Scenario Outline: Search only with group members - allowed + Given using OCS API version "" + And parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" + And user "Sharee1" has been added to group "ShareeGroup2" + When user "Alice" gets the sharees using the sharing API with parameters + | search | sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be + | ShareeGroup | 1 | ShareeGroup | + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Search only with group members - no group as non-member + Given using OCS API version "" + And parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + When user "Sharee1" gets the sharees using the sharing API with parameters + | search | sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Search only with membership groups - denied + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + When user "Sharee1" gets the sharees using the sharing API with parameters + | search | ShareeGroup | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Search only with membership groups - denied but users match + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + When user "Sharee1" gets the sharees using the sharing API with parameters + | search | sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Search only with membership groups - allowed + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + When user "Alice" gets the sharees using the sharing API with parameters + | search | ShareeGroup | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Search only with membership groups - allowed including users + Given using OCS API version "" + And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" + When user "Alice" gets the sharees using the sharing API with parameters + | search | Sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Search without exact match no iteration allowed + Given using OCS API version "" + And parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no" + When user "Alice" gets the sharees using the sharing API with parameters + | search | Sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Search with exact match no iteration allowed + Given using OCS API version "" + And parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no" + When user "Alice" gets the sharees using the sharing API with parameters + | search | Sharee1 | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Search with exact match group no iteration allowed + Given using OCS API version "" + And parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no" + When user "Alice" gets the sharees using the sharing API with parameters + | search | ShareeGroup | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be + | ShareeGroup | 1 | ShareeGroup | + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Try to search for users and groups when in a group that is excluded from sharing (could match both users and groups) + Given using OCS API version "" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["ShareeGroup2"]' + When user "Alice" gets the sharees using the sharing API with parameters + | search | sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Try to search for users and groups when in a group that is excluded from sharing (exact match to a user) + Given using OCS API version "" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["ShareeGroup2"]' + When user "Alice" gets the sharees using the sharing API with parameters + | search | sharee1 | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Try to search for users and groups when in a group that is excluded from sharing (exact match to a group) + Given using OCS API version "" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["ShareeGroup2"]' + When user "Alice" gets the sharees using the sharing API with parameters + | search | ShareeGroup | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: Search with exact match + Given using OCS API version "" + When user "Alice" gets the sharees using the sharing API with parameters + | search | Sharee1 | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: Search with exact match not-exact casing + Given using OCS API version "" + When user "Alice" gets the sharees using the sharing API with parameters + | search | sharee1 | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: Search with exact match not-exact casing group + Given using OCS API version "" + When user "Alice" gets the sharees using the sharing API with parameters + | search | shareegroup2 | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: Search with "self" + Given using OCS API version "" + When user "Sharee1" gets the sharees using the sharing API with parameters + | search | Sharee1 | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: Federated sharee for files + Given using OCS API version "" + When user "Alice" gets the sharees using the sharing API with parameters + | search | test@localhost | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be + | test@localhost | 6 | test@localhost | + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: Federated sharee for calendars not allowed + Given using OCS API version "" + When user "Alice" gets the sharees using the sharing API with parameters + | search | test@localhost | + | itemType | calendar | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Group sharees not returned when group sharing is disabled + Given using OCS API version "" + And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" + When user "Alice" gets the sharees using the sharing API with parameters + | search | sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @skipOnLDAP + Scenario Outline: Enumerate only group members - only show partial results from member of groups + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | displayname | + | another | Another | + And user "Another" has been added to group "ShareeGroup2" + And parameter "shareapi_share_dialog_user_enumeration_group_members" of app "core" has been set to "yes" + When user "Alice" gets the sharees using the sharing API with parameters + | search | anot | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be + | Another | 0 | another | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Enumerate only group members - accept exact match from non-member groups + Given using OCS API version "" + And parameter "shareapi_share_dialog_user_enumeration_group_members" of app "core" has been set to "yes" + When user "Alice" gets the sharees using the sharing API with parameters + | search | Sharee1 | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be + | Sharee One | 0 | sharee1 | + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Enumerate only group members - only show partial results from member groups + Given using OCS API version "" + And parameter "shareapi_share_dialog_user_enumeration_group_members" of app "core" has been set to "yes" + When user "Alice" gets the sharees using the sharing API with parameters + | search | ShareeG | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @skipOnLDAP @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: Enumerate only group members - only accept exact group match from non-memberships + Given using OCS API version "" + And group "ShareeGroupNonMember" has been created + And parameter "shareapi_share_dialog_user_enumeration_group_members" of app "core" has been set to "yes" + When user "Alice" gets the sharees using the sharing API with parameters + | search | ShareeGroupNonMember | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be + | ShareeGroupNonMember | 1 | ShareeGroupNonMember | + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: Search without exact match such that the search string matches the user getting the sharees + Given user "sharee2" has been created with default attributes and without skeleton files + And using OCS API version "" + When user "sharee1" gets the sharees using the sharing API with parameters + | search | sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be + | Sharee One | 0 | sharee1 | + | Sharee Two | 0 | sharee2 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be + | ShareeGroup | 1 | ShareeGroup | + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: empty search for sharees when search min length is set to 0 + Given the administrator has updated system config key "user.search_min_length" with value "0" + And user "sharee2" has been created with default attributes and without skeleton files + And using OCS API version "" + When user "sharee1" gets the sharees using the sharing API with parameters + | search | | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should include + | Alice Hansen | 0 | Alice | + | Sharee One | 0 | sharee1 | + | Sharee Two | 0 | sharee2 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should include + | ShareeGroup | 1 | ShareeGroup | + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: empty search for sharees when search min length is set to 2 + Given the administrator has updated system config key "user.search_min_length" with value "2" + And user "sharee2" has been created with default attributes and without skeleton files + And using OCS API version "" + When user "sharee1" gets the sharees using the sharing API with parameters + | search | | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: search for sharees when search min length is set to 2 + Given the administrator has updated system config key "user.search_min_length" with value "2" + And user "sharee2" has been created with default attributes and without skeleton files + And using OCS API version "" + When user "sharee1" gets the sharees using the sharing API with parameters + | search | sh | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should include + | Sharee One | 0 | sharee1 | + | Sharee Two | 0 | sharee2 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should include + | ShareeGroup | 1 | ShareeGroup | + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + + Scenario Outline: search for sharees with long name when search min length is set to 2 + Given the administrator has updated system config key "user.search_min_length" with value "2" + And user "sharee2" has been created with default attributes and without skeleton files + And using OCS API version "" + When user "sharee1" gets the sharees using the sharing API with parameters + | search | sharee | + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should include + | Sharee One | 0 | sharee1 | + | Sharee Two | 0 | sharee2 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should include + | ShareeGroup | 1 | ShareeGroup | + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: search for sharees without search when min length is set to 0 + Given the administrator has updated system config key "user.search_min_length" with value "0" + And user "sharee2" has been created with default attributes and without skeleton files + And using OCS API version "" + When user "sharee1" gets the sharees using the sharing API with parameters + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should include + | Alice Hansen | 0 | Alice | + | Sharee One | 0 | sharee1 | + | Sharee Two | 0 | sharee2 | + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should include + | ShareeGroup | 1 | ShareeGroup | + | ShareeGroup2 | 1 | ShareeGroup2 | + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | + + @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 + Scenario Outline: search for sharees without search when min length is set to 2 + Given the administrator has updated system config key "user.search_min_length" with value "2" + And user "sharee2" has been created with default attributes and without skeleton files + And using OCS API version "" + When user "sharee1" gets the sharees using the sharing API with parameters + | itemType | file | + Then the OCS status code should be "" + And the HTTP status code should be "" + And the "exact users" sharees returned should be empty + And the "users" sharees returned should be empty + And the "exact groups" sharees returned should be empty + And the "groups" sharees returned should be empty + And the "exact remotes" sharees returned should be empty + And the "remotes" sharees returned should be empty + Examples: + | ocs-api-version | ocs-status | http-status | + | 1 | 100 | 200 | + | 2 | 200 | 200 | diff --git a/tests/acceptance/features/coreApiSharingNotificationsToRoot/sharingNotifications.feature b/tests/acceptance/features/coreApiSharingNotificationsToRoot/sharingNotifications.feature new file mode 100644 index 00000000000..bd3ec2b7b63 --- /dev/null +++ b/tests/acceptance/features/coreApiSharingNotificationsToRoot/sharingNotifications.feature @@ -0,0 +1,177 @@ +@api @app-required @notifications-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: Display notifications when receiving a share + As a user + I want to see notifications about shares that have been offered to me + So that I can easily decide what I want to do with new received shares + + Background: + Given app "notifications" has been enabled + And using OCS API version "1" + And using new DAV path + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + And these groups have been created: + | groupname | + | grp1 | + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + + @smokeTest + Scenario: share to user sends notification + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should have 2 notifications + And the last notification of user "Brian" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + + + Scenario: share to group sends notification to every member + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should have 2 notifications + And the last notification of user "Brian" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "Carol" should have 2 notifications + And the last notification of user "Carol" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + + # This scenario documents behavior discussed in core issue 31870 + # An old share keeps its old auto-accept behavior, even after auto-accept has been disabled. + @skipOnLDAP + Scenario: share to group does not send notifications to either existing or new members for an old share created before auto-accept is disabled + Given user "Alice" has shared folder "/PARENT" with group "grp1" + When the administrator sets parameter "shareapi_auto_accept_share" of app "core" to "no" + And the administrator creates user "David" using the provisioning API + And the administrator adds user "David" to group "grp1" using the provisioning API + Then the OCS status code of responses on each endpoint should be "200, 100" respectively + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should have 0 notifications + And user "Carol" should have 0 notifications + And user "David" should have 0 notifications + + # This scenario documents behavior discussed in core issue 31870 + # As users are added to an existing group, they are not sent notifications about group shares. + @skipOnLDAP + Scenario: share to group sends notifications to existing members, but not to new members, for a share created after auto-accept is disabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And the administrator creates user "David" using the provisioning API + And the administrator adds user "David" to group "grp1" using the provisioning API + Then the OCS status code of responses on each endpoint should be "100, 200, 100" respectively + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should have 1 notification + And the last notification of user "Brian" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "Carol" should have 1 notification + And the last notification of user "Carol" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "David" should have 0 notifications + + # This scenario documents behavior discussed in core issue 31870 + # Similar to the previous scenario, a new user added to the group does not get a notification, + # even though the group, when originally created, had notifications on. + @skipOnLDAP + Scenario: share to group sends notifications to existing members, but not to new members, for an old share created before auto-accept is enabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has shared folder "/PARENT" with group "grp1" + When the administrator sets parameter "shareapi_auto_accept_share" of app "core" to "yes" + And the administrator creates user "David" using the provisioning API + And the administrator adds user "David" to group "grp1" using the provisioning API + Then the OCS status code of responses on each endpoint should be "200, 100" respectively + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should have 1 notification + And the last notification of user "Brian" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "Carol" should have 1 notification + And the last notification of user "Carol" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "David" should have 0 notifications + + @skipOnLDAP + Scenario: share to group does not send notifications to existing and new members for a share created after auto-accept is enabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And the administrator creates user "David" using the provisioning API + And the administrator adds user "David" to group "grp1" using the provisioning API + Then the OCS status code of responses on each endpoint should be "100, 200, 100" respectively + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should have 0 notifications + And user "Carol" should have 0 notifications + And user "David" should have 0 notifications + + + Scenario: when auto-accepting is enabled no notifications are sent + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should have 0 notifications + + @skipOnLDAP + Scenario: discard notification if target user is not member of the group anymore + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And the administrator removes user "Brian" from group "grp1" using the provisioning API + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should have 0 notifications + And user "Carol" should have 1 notification + + + Scenario: discard notification if group is deleted + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And the administrator deletes group "grp1" from the default user backend + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should have 0 notifications + And user "Carol" should have 0 notifications diff --git a/tests/acceptance/features/coreApiSharingNotificationsToShares/sharingNotifications.feature b/tests/acceptance/features/coreApiSharingNotificationsToShares/sharingNotifications.feature new file mode 100644 index 00000000000..e5ce35c0d3a --- /dev/null +++ b/tests/acceptance/features/coreApiSharingNotificationsToShares/sharingNotifications.feature @@ -0,0 +1,164 @@ +@api @app-required @notifications-app-required @files_sharing-app-required @issue-ocis-1328 +Feature: Display notifications when receiving a share + As a user + I want to see notifications about shares that have been offered to me + So that I can easily decide what I want to do with new received shares + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And app "notifications" has been enabled + And using OCS API version "1" + And using new DAV path + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + And these groups have been created: + | groupname | + | grp1 | + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + + @smokeTest + Scenario: share to user sends notification + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + 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 "100" + And user "Brian" should have 2 notifications + And the last notification of user "Brian" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + + + Scenario: share to group sends notification to every member + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API + 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 "100" + And user "Brian" should have 2 notifications + And the last notification of user "Brian" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "Carol" should have 2 notifications + And the last notification of user "Carol" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + + # This scenario documents behavior discussed in core issue 31870 + # As users are added to an existing group, they are not sent notifications about group shares. + @skipOnLDAP + Scenario: share to group sends notifications to existing members, but not to new members, for a share created after auto-accept is disabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And the administrator creates user "David" using the provisioning API + And the administrator adds user "David" to group "grp1" using the provisioning API + Then the HTTP status code of responses on all endpoints should be "200" + And the OCS status code of responses on each endpoint should be "100, 200, 100" respectively + And user "Brian" should have 1 notification + And the last notification of user "Brian" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "Carol" should have 1 notification + And the last notification of user "Carol" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "David" should have 0 notifications + + # This scenario documents behavior discussed in core issue 31870 + # Similar to the previous scenario, a new user added to the group does not get a notification, + # even though the group, when originally created, had notifications on. + @skipOnLDAP + Scenario: share to group sends notifications to existing members, but not to new members, for an old share created before auto-accept is enabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has shared folder "/PARENT" with group "grp1" + When the administrator sets parameter "shareapi_auto_accept_share" of app "core" to "yes" + And the administrator creates user "David" using the provisioning API + And the administrator adds user "David" to group "grp1" using the provisioning API + Then the HTTP status code of responses on all endpoints should be "200" + And the OCS status code of responses on each endpoint should be "200,100" respectively + And user "Brian" should have 1 notification + And the last notification of user "Brian" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "Carol" should have 1 notification + And the last notification of user "Carol" should match these regular expressions about user "Alice" + | key | regex | + | app | /^files_sharing$/ | + | subject | /^"%displayname%" shared "PARENT" with you$/ | + | message | /^"%displayname%" invited you to view "PARENT"$/ | + | link | /^https?:\/\/.+\/f\/(\d+)$/ | + | object_type | /^local_share$/ | + And user "David" should have 0 notifications + + @skipOnLDAP + Scenario: share to group does not send notifications to existing and new members for a share created after auto-accept is enabled + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And the administrator creates user "David" using the provisioning API + And the administrator adds user "David" to group "grp1" using the provisioning API + Then the HTTP status code of responses on all endpoints should be "200" + And the OCS status code of responses on each endpoint should be "100, 200, 100" respectively + And user "Brian" should have 0 notifications + And user "Carol" should have 0 notifications + And user "David" should have 0 notifications + + + Scenario: when auto-accepting is enabled no notifications are sent + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "yes" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API + 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 "100" + And user "Brian" should have 0 notifications + + @skipOnLDAP + Scenario: discard notification if target user is not member of the group anymore + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And the administrator removes user "Brian" from group "grp1" using the provisioning API + 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 "100" + And user "Brian" should have 0 notifications + And user "Carol" should have 1 notification + + + Scenario: discard notification if group is deleted + Given parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API + And the administrator deletes group "grp1" from the default user backend + 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 "100" + And user "Brian" should have 0 notifications + And user "Carol" should have 0 notifications diff --git a/tests/acceptance/features/coreApiTags/assignTags.feature b/tests/acceptance/features/coreApiTags/assignTags.feature new file mode 100644 index 00000000000..3391b7271ca --- /dev/null +++ b/tests/acceptance/features/coreApiTags/assignTags.feature @@ -0,0 +1,136 @@ +@api @systemtags-app-required @files_sharing-app-required @issue-ocis-reva-51 +Feature: Assign tags to file/folder + As a user + I want to assign tags to the file/folder + So that I can organize the files/folders easily + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario: Assigning a normal tag to a file shared by someone else as regular user should work + Given the administrator has created a "normal" tag with name "JustARegularTagName" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + When user "Brian" adds tag "JustARegularTagName" to file "/myFileToTag.txt" using the WebDAV API + Then the HTTP status code should be "201" + And file "/myFileToTag.txt" shared by user "Alice" should have the following tags + | name | type | + | JustARegularTagName | normal | + + + Scenario: Assigning a normal tag to a file belonging to someone else as regular user should fail + Given the administrator has created a "normal" tag with name "MyFirstTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" + When user "Brian" adds tag "MySecondTag" to file "/myFileToTag.txt" owned by user "Alice" using the WebDAV API + Then the HTTP status code should be "404" + And file "/myFileToTag.txt" owned by user "Alice" should have the following tags + | name | type | + | MyFirstTag | normal | + + + Scenario: Assigning a not user-assignable tag to a file shared by someone else as regular user should fail + Given the administrator has created a "normal" tag with name "MyFirstTag" + And the administrator has created a "not user-assignable" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" + When user "Brian" adds tag "MySecondTag" to file "/myFileToTag.txt" using the WebDAV API + Then the HTTP status code should be "403" + And file "/myFileToTag.txt" shared by user "Alice" should have the following tags + | name | type | + | MyFirstTag | normal | + + + Scenario: Assigning a not user-assignable tag to a file shared by someone else as regular user belongs to tag's groups should work + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And the administrator has created a "not user-assignable" tag with name "JustARegularTagName" and groups "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + When user "Brian" adds tag "JustARegularTagName" to file "/myFileToTag.txt" using the WebDAV API + Then the HTTP status code should be "201" + And file "/myFileToTag.txt" shared by user "Alice" should have the following tags + | name | type | + | JustARegularTagName | not user-assignable | + + + Scenario: Assigning a static tag to a file shared by someone else as regular user belongs to tag's groups should work + Given group "grp1" has been created + And user "Brian" has been added to group "grp1" + And the administrator has created a "static" tag with name "StaticTagName" and groups "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + When user "Brian" adds tag "StaticTagName" to file "/myFileToTag.txt" using the WebDAV API + Then the HTTP status code should be "201" + And file "/myFileToTag.txt" shared by user "Alice" should have the following tags + | name | type | + | StaticTagName | static | + + + Scenario: Assigning a not user-visible tag to a file shared by someone else as regular user should fail + Given the administrator has created a "normal" tag with name "MyFirstTag" + And the administrator has created a "not user-visible" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" + When user "Brian" adds tag "MySecondTag" to file "/myFileToTag.txt" using the WebDAV API + Then the HTTP status code should be "412" + And file "/myFileToTag.txt" shared by user "Alice" should have the following tags + | name | type | + | MyFirstTag | normal | + + + Scenario: Assigning a static tag to a file shared by someone else as regular user does not belong to tag's group should fail + Given group "hash#group" has been created + And user "Alice" has been added to group "hash#group" + And the administrator has created a "normal" tag with name "NormalTag" + And the administrator has created a "static" tag with name "StaticTag" and groups "hash#group" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has added tag "NormalTag" to file "/myFileToTag.txt" + When user "Brian" adds tag "StaticTag" to file "/myFileToTag.txt" using the WebDAV API + Then the HTTP status code should be "403" + And file "/myFileToTag.txt" shared by user "Alice" should have the following tags + | name | type | + | NormalTag | normal | + + + Scenario: Assigning a not user-visible tag to a file shared by someone else as admin user should work + Given the administrator has created a "normal" tag with name "MyFirstTag" + And the administrator has created a "not user-visible" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" + When the administrator adds tag "MySecondTag" to file "/myFileToTag.txt" using the WebDAV API + Then the HTTP status code should be "201" + And file "/myFileToTag.txt" should have the following tags for the administrator + | name | type | + | MyFirstTag | normal | + | MySecondTag | not user-visible | + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MyFirstTag | normal | + + + Scenario: Assigning a not user-assignable tag to a file shared by someone else as admin user should work + Given the administrator has created a "normal" tag with name "MyFirstTag" + And the administrator has created a "not user-assignable" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" + When the administrator adds tag "MySecondTag" to file "/myFileToTag.txt" using the WebDAV API + Then the HTTP status code should be "201" + And file "/myFileToTag.txt" should have the following tags for the administrator + | name | type | + | MyFirstTag | normal | + | MySecondTag | not user-assignable | + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MyFirstTag | normal | + | MySecondTag | not user-assignable | diff --git a/tests/acceptance/features/coreApiTags/assignTagsGroup.feature b/tests/acceptance/features/coreApiTags/assignTagsGroup.feature new file mode 100644 index 00000000000..c441aeac6cd --- /dev/null +++ b/tests/acceptance/features/coreApiTags/assignTagsGroup.feature @@ -0,0 +1,29 @@ +@api @systemtags-app-required @issue-ocis-reva-51 +Feature: Assign tag to groups + As a user + I should be able to assign tag to groups + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario: User can assign tags when in the tag's groups + Given group "grp1" has been created + And user "Alice" has been added to group "grp1" + When the administrator creates a "not user-assignable" tag with name "TagWithGroups" and groups "grp1|group2" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should be able to assign the "not user-assignable" tag with name "TagWithGroups" + + + Scenario: User can assign static tags when in the tag's groups + Given group "grp1" has been created + And user "Alice" has been added to group "grp1" + When the administrator creates a "static" tag with name "TagWithGroups" and groups "grp1|group2" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should be able to assign the "static" tag with name "TagWithGroups" + + + Scenario: User cannot assign tags when not in the tag's groups + When the administrator creates a "not user-assignable" tag with name "TagWithGroups" and groups "grp2|group2" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should not be able to assign the "not user-assignable" tag with name "TagWithGroups" diff --git a/tests/acceptance/features/coreApiTags/createTags.feature b/tests/acceptance/features/coreApiTags/createTags.feature new file mode 100644 index 00000000000..d80bb1f1a87 --- /dev/null +++ b/tests/acceptance/features/coreApiTags/createTags.feature @@ -0,0 +1,142 @@ +@api @systemtags-app-required @issue-ocis-reva-51 +Feature: Creation of tags + As a user + I should be able to create tags + So that I could categorize my files + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario Outline: Creating a normal tag as regular user should work + When user "Alice" creates a "normal" tag with name "" using the WebDAV API + Then the HTTP status code should be "201" + And the following tags should exist for the administrator + | name | type | + | | normal | + And the following tags should exist for user "Alice" + | name | type | + | | normal | + Examples: + | tag_name | + | JustARegularTagName | + | 😀 | + | सिमप्ले | + + + Scenario: Creating a normal tag as a regular user should work (sending the string "1" to turn on the tag attributes) + When user "Alice" creates a "normal" tag with name "RegularTag" sending numbers in the request using the WebDAV API + Then the HTTP status code should be "201" + And the following tags should exist for the administrator + | name | type | + | RegularTag | normal | + And the following tags should exist for user "Alice" + | name | type | + | RegularTag | normal | + + + Scenario: Creating a not user-assignable tag as regular user should fail + When user "Alice" creates a "not user-assignable" tag with name "JustARegularTagName" using the WebDAV API + Then the HTTP status code should be "400" + And tag "JustARegularTagName" should not exist for the administrator + + + Scenario: Creating a static tag as regular user should fail + When user "Alice" creates a "static" tag with name "StaticTagName" using the WebDAV API + Then the HTTP status code should be "400" + And tag "StaticTagName" should not exist for the administrator + + + Scenario: Creating a not user-visible tag as regular user should fail + When user "Alice" creates a "not user-visible" tag with name "JustARegularTagName" using the WebDAV API + Then the HTTP status code should be "400" + And tag "JustARegularTagName" should not exist for the administrator + + + Scenario Outline: Creating a tag as administrator should work + When the administrator creates a "" tag with name "JustARegularTagName" sending in the request using the WebDAV API + Then the HTTP status code should be "201" + And the following tags should exist for the administrator + | name | type | + | JustARegularTagName | | + Examples: + | tag_type | sending_style | + | normal | true-false-strings | + | normal | numbers | + | not user-assignable | true-false-strings | + | not user-assignable | numbers | + | not user-visible | true-false-strings | + | not user-visible | numbers | + | static | true-false-strings | + | static | numbers | + + @smokeTest + Scenario: Creating a not user-assignable tag with groups as admin should work + When the administrator creates a "not user-assignable" tag with name "TagWithGroups" and groups "group1|group2" using the WebDAV API + Then the HTTP status code should be "201" + And the "not user-assignable" tag with name "TagWithGroups" should have the groups "group1|group2" + + + Scenario: Creating a normal tag with groups as regular user should fail + When user "Alice" creates a "normal" tag with name "JustARegularTagName" and groups "group1|group2" using the WebDAV API + Then the HTTP status code should be "400" + And tag "JustARegularTagName" should not exist for user "Alice" + + + Scenario: Creating a normal tag that is already created by other user should fail + Given user "Brian" has created a "normal" tag with name "JustARegularTagName" + When user "Alice" creates a "normal" tag with name "JustARegularTagName" using the WebDAV API + Then the HTTP status code should be "409" + + + Scenario: Overwriting existing normal tags should fail + Given user "Alice" has created a "normal" tag with name "MyFirstTag" + When user "Alice" creates a "normal" tag with name "MyFirstTag" using the WebDAV API + Then the HTTP status code should be "409" + + + Scenario: Overwriting existing not user-assignable tags should fail + Given the administrator has created a "not user-assignable" tag with name "MyFirstTag" + When the administrator creates a "not user-assignable" tag with name "MyFirstTag" using the WebDAV API + Then the HTTP status code should be "409" + + + Scenario: Overwriting existing not user-visible tags should fail + Given the administrator has created a "not user-visible" tag with name "MyFirstTag" + When the administrator creates a "not user-visible" tag with name "MyFirstTag" using the WebDAV API + Then the HTTP status code should be "409" + + + Scenario: Overwriting existing static tags should fail + Given the administrator has created a "static" tag with name "StaticTag" + When the administrator creates a "static" tag with name "StaticTag" using the WebDAV API + Then the HTTP status code should be "409" + + + Scenario: Creating tags in lowercase and uppercase should work + When the administrator creates the following tags using the WebDAV API + | name | type | + | UppercaseTag | normal | + | lowercasetag | normal | + Then the HTTP status code of responses on all endpoints should be "201" + And the following tags should exist for the administrator + | name | type | + | UppercaseTag | normal | + | lowercasetag | normal | + + + Scenario: Creating tags with the same name in lowercase and uppercase should work + When the administrator creates the following tags using the WebDAV API + | name | type | + | testtag | normal | + | Testtag | normal | + | TESTTAG | normal | + Then the HTTP status code of responses on all endpoints should be "201" + And the following tags should exist for the administrator + | name | type | + | testtag | normal | + | Testtag | normal | + | TESTTAG | normal | diff --git a/tests/acceptance/features/coreApiTags/deleteTags.feature b/tests/acceptance/features/coreApiTags/deleteTags.feature new file mode 100644 index 00000000000..ef128574526 --- /dev/null +++ b/tests/acceptance/features/coreApiTags/deleteTags.feature @@ -0,0 +1,72 @@ +@api @systemtags-app-required @issue-ocis-reva-51 +Feature: Deletion of tags + As a user + I want to delete the tags that are already created + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario: Deleting a normal tag as regular user should work + Given the administrator has created a "normal" tag with name "JustARegularTagName" + When user "Alice" deletes the tag with name "JustARegularTagName" using the WebDAV API + Then the HTTP status code should be "204" + And tag "JustARegularTagName" should not exist for the administrator + + + Scenario: Deleting a normal tag that has already been assigned to a file should work + Given user "Alice" has created a "normal" tag with name "JustARegularTagName" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has added tag "JustARegularTagName" to file "/myFileToTag.txt" + When user "Alice" deletes the tag with name "JustARegularTagName" using the WebDAV API + Then the HTTP status code should be "204" + And tag "JustARegularTagName" should not exist for the administrator + And file "/myFileToTag.txt" should have no tags for user "Alice" + + + Scenario: Deleting a not user-assignable tag as regular user should fail + Given the administrator has created a "not user-assignable" tag with name "JustARegularTagName" + When user "Alice" deletes the tag with name "JustARegularTagName" using the WebDAV API + Then the HTTP status code should be "403" + And the following tags should exist for the administrator + | name | type | + | JustARegularTagName | not user-assignable | + + + Scenario: Deleting a not user-visible tag as regular user should fail + Given the administrator has created a "not user-visible" tag with name "JustARegularTagName" + When user "Alice" deletes the tag with name "JustARegularTagName" using the WebDAV API + Then the HTTP status code should be "404" + And the following tags should exist for the administrator + | name | type | + | JustARegularTagName | not user-visible | + + + Scenario: Deleting a static tag as regular user should fail + Given the administrator has created a "static" tag with name "StaticTagName" + When user "Alice" deletes the tag with name "StaticTagName" using the WebDAV API + Then the HTTP status code should be "403" + And the following tags should exist for the administrator + | name | type | + | StaticTagName | static | + + + Scenario: Deleting a not user-assignable tag as admin should work + Given the administrator has created a "not user-assignable" tag with name "JustARegularTagName" + When the administrator deletes the tag with name "JustARegularTagName" using the WebDAV API + Then the HTTP status code should be "204" + And tag "JustARegularTagName" should not exist for the administrator + + + Scenario: Deleting a not user-visible tag as admin should work + Given the administrator has created a "not user-visible" tag with name "JustARegularTagName" + When the administrator deletes the tag with name "JustARegularTagName" using the WebDAV API + Then the HTTP status code should be "204" + And tag "JustARegularTagName" should not exist for the administrator + + + Scenario: Deleting a static tag as admin should work + Given the administrator has created a "static" tag with name "StaticTagName" + When the administrator deletes the tag with name "StaticTagName" using the WebDAV API + Then the HTTP status code should be "204" + And tag "StaticTagName" should not exist for the administrator diff --git a/tests/acceptance/features/coreApiTags/editTags.feature b/tests/acceptance/features/coreApiTags/editTags.feature new file mode 100644 index 00000000000..f548976145b --- /dev/null +++ b/tests/acceptance/features/coreApiTags/editTags.feature @@ -0,0 +1,99 @@ +@api @systemtags-app-required @issue-ocis-reva-51 +Feature: Editing the tags + As a user + I want to be able to change the tags I have created + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: Renaming a normal tag as regular user should work + Given the administrator has created a "normal" tag with name "" + When user "Alice" edits the tag with name "" and sets its name to "AnotherTagName" using the WebDAV API + Then the HTTP status code should be "207" + And the following tags should exist for the administrator + | name | type | + | AnotherTagName | normal | + Examples: + | tag_name | + | JustARegularTagName | + | 😀 | + | सिमप्ले | + + + Scenario: Renaming a not user-assignable tag as regular user should fail + Given the administrator has created a "not user-assignable" tag with name "JustARegularTagName" + When user "Alice" edits the tag with name "JustARegularTagName" and sets its name to "AnotherTagName" using the WebDAV API + Then the HTTP status code should be "403" + And the following tags should exist for the administrator + | name | type | + | JustARegularTagName | not user-assignable | + + + Scenario: Renaming a static tag as regular user should fail + Given the administrator has created a "static" tag with name "StaticTagName" + When user "Alice" edits the tag with name "StaticTagName" and sets its name to "AnotherTagName" using the WebDAV API + Then the HTTP status code should be "403" + And the following tags should exist for the administrator + | name | type | + | StaticTagName | static | + + + Scenario: Renaming a not user-visible tag as regular user should fail + Given the administrator has created a "not user-visible" tag with name "JustARegularTagName" + When user "Alice" edits the tag with name "JustARegularTagName" and sets its name to "AnotherTagName" using the WebDAV API + Then the HTTP status code should be "404" + And the following tags should exist for the administrator + | name | type | + | JustARegularTagName | not user-visible | + + + Scenario: Renaming a not user-assignable tag as administrator should work + Given the administrator has created a "not user-assignable" tag with name "JustARegularTagName" + When the administrator edits the tag with name "JustARegularTagName" and sets its name to "AnotherTagName" using the WebDAV API + Then the HTTP status code should be "207" + And the following tags should exist for the administrator + | name | type | + | AnotherTagName | not user-assignable | + And tag "JustARegularTagName" should not exist for the administrator + + + Scenario: Renaming a not user-visible tag as administrator should work + Given the administrator has created a "not user-visible" tag with name "JustARegularTagName" + When the administrator edits the tag with name "JustARegularTagName" and sets its name to "AnotherTagName" using the WebDAV API + Then the HTTP status code should be "207" + And the following tags should exist for the administrator + | name | type | + | AnotherTagName | not user-visible | + And tag "JustARegularTagName" should not exist for the administrator + + + Scenario: Renaming a static tag as administrator should work + Given the administrator has created a "static" tag with name "StaticTagName" + When the administrator edits the tag with name "StaticTagName" and sets its name to "AnotherTagName" using the WebDAV API + Then the HTTP status code should be "207" + And the following tags should exist for the administrator + | name | type | + | AnotherTagName | static | + And tag "StaticTagName" should not exist for the administrator + + + Scenario: Editing tag groups as admin should work + Given the administrator has created a "not user-assignable" tag with name "TagWithGroups" and groups "group1|group2" + When the administrator edits the tag with name "TagWithGroups" and sets its groups to "group1|group3" using the WebDAV API + Then the HTTP status code should be "207" + And the "not user-assignable" tag with name "TagWithGroups" should have the groups "group1|group3" + + + Scenario: Editing static tag groups as admin should work + Given the administrator has created a "static" tag with name "StaticTagWithGroups" and groups "group1|group2" + When the administrator edits the tag with name "StaticTagWithGroups" and sets its groups to "group1|group3" using the WebDAV API + Then the HTTP status code should be "207" + And the "static" tag with name "StaticTagWithGroups" should have the groups "group1|group3" + + + Scenario: Editing tag groups as regular user should fail + Given the administrator has created a "not user-assignable" tag with name "TagWithGroups" and groups "group1|group2" + When user "Alice" edits the tag with name "TagWithGroups" and sets its groups to "group1|group3" using the WebDAV API + Then the HTTP status code should be "403" + And the "not user-assignable" tag with name "TagWithGroups" should have the groups "group1|group2" diff --git a/tests/acceptance/features/coreApiTags/retreiveTags.feature b/tests/acceptance/features/coreApiTags/retreiveTags.feature new file mode 100644 index 00000000000..857d0f82a62 --- /dev/null +++ b/tests/acceptance/features/coreApiTags/retreiveTags.feature @@ -0,0 +1,31 @@ +@api @systemtags-app-required @issue-ocis-reva-51 +Feature: tags + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario: Getting tags only works with access to the file + Given the administrator has created a "normal" tag with name "MyFirstTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" + When user "Brian" requests tags for file "/myFileToTag.txt" owned by user "Alice" using the WebDAV API + And user "Alice" gets the following properties of file "/myFileToTag.txt" using the WebDAV API + | propertyName | + | oc:tags | + Then the HTTP status code of responses on all endpoints should be "404" + And the single response should contain a property "oc:tags" with value "" + + @files_sharing-app-required + Scenario: Static tags should be available while accessing the file if it is assigned to file + Given the administrator has created a "static" tag with name "StaticTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + When the administrator adds tag "StaticTag" to file "/myFileToTag.txt" using the WebDAV API + Then file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | StaticTag | static | + And the HTTP status when user "Brian" requests tags for file "/myFileToTag.txt" owned by user "Alice" should be "404" diff --git a/tests/acceptance/features/coreApiTags/unassignTags.feature b/tests/acceptance/features/coreApiTags/unassignTags.feature new file mode 100644 index 00000000000..b2209367798 --- /dev/null +++ b/tests/acceptance/features/coreApiTags/unassignTags.feature @@ -0,0 +1,177 @@ +@api @systemtags-app-required @files_sharing-app-required @issue-ocis-reva-51 +Feature: Unassigning tags from file/folder + As a user + I want to be able to remove tags from file/folder + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + @smokeTest + Scenario: Unassigning a normal tag from a file shared by someone else as regular user should work + Given the administrator has created a "normal" tag with name "MyFirstTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + When user "Brian" removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MySecondTag | normal | + + + Scenario: Unassigning a normal tag from a file unshared by someone else as regular user should fail + Given the administrator has created a "normal" tag with name "MyFirstTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has added tag "MyFirstTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + When user "Brian" removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "404" + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MyFirstTag | normal | + | MySecondTag | normal | + + + Scenario: Unassigning a not user-visible tag from a file shared by someone else as regular user should fail + Given the administrator has created a "not user-visible" tag with name "MyFirstTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + When user "Brian" removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "404" + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MySecondTag | normal | + And file "/myFileToTag.txt" should have the following tags for the administrator + | name | type | + | MyFirstTag | not user-visible | + | MySecondTag | normal | + + + Scenario: Unassigning a static tag from a file and not part of static tags group shared by someone else as regular user should fail + Given the administrator has created a "static" tag with name "StaticTag" + And user "Alice" has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And the administrator has added tag "StaticTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + When user "Brian" removes tag "StaticTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MySecondTag | normal | + | StaticTag | static | + And file "/myFileToTag.txt" should have the following tags for the administrator + | name | type | + | StaticTag | static | + | MySecondTag | normal | + + + Scenario: Unassigning a not user-visible tag from a file shared by someone else as admin should work + Given the administrator has created a "not user-visible" tag with name "MyFirstTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + When the administrator removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MySecondTag | normal | + And file "/myFileToTag.txt" should have the following tags for the administrator + | name | type | + | MySecondTag | normal | + + + Scenario: Unassigning a static tag from a file shared by someone else as admin should work + Given the administrator has created a "static" tag with name "StaticTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And the administrator has added tag "StaticTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + When the administrator removes tag "StaticTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MySecondTag | normal | + And file "/myFileToTag.txt" should have the following tags for the administrator + | name | type | + | MySecondTag | normal | + + + Scenario: Unassigning a not user-visible tag from a file unshared by someone else should fail + Given the administrator has created a "not user-visible" tag with name "MyFirstTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + And user "Alice" has removed all shares from the file named "/myFileToTag.txt" + When the administrator removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "404" + + + Scenario: Unassigning a not user-assignable tag from a file shared by someone else as regular user should fail + Given the administrator has created a "not user-assignable" tag with name "MyFirstTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + When user "Brian" removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MyFirstTag | not user-assignable | + | MySecondTag | normal | + And file "/myFileToTag.txt" should have the following tags for the administrator + | name | type | + | MyFirstTag | not user-assignable | + | MySecondTag | normal | + + + Scenario: Unassigning a not user-assignable tag from a file shared by someone else as admin should work + Given the administrator has created a "not user-assignable" tag with name "MyFirstTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + When the administrator removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And file "/myFileToTag.txt" should have the following tags for user "Alice" + | name | type | + | MySecondTag | normal | + And file "/myFileToTag.txt" should have the following tags for the administrator + | name | type | + | MySecondTag | normal | + + + Scenario: Unassigning a not user-assignable tag from a file unshared by someone else should fail + Given the administrator has created a "not user-assignable" tag with name "MyFirstTag" + And the administrator has created a "normal" tag with name "MySecondTag" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myFileToTag.txt" + And user "Alice" has shared file "/myFileToTag.txt" with user "Brian" + And user "Alice" has shared file "/myFileToTag.txt" with the administrator + And the administrator has added tag "MyFirstTag" to file "/myFileToTag.txt" + And user "Alice" has added tag "MySecondTag" to file "/myFileToTag.txt" + And user "Alice" has removed all shares from the file named "/myFileToTag.txt" + When the administrator removes tag "MyFirstTag" from file "/myFileToTag.txt" shared by "Alice" using the WebDAV API + Then the HTTP status code should be "404" diff --git a/tests/acceptance/features/coreApiTranslation/translation.feature b/tests/acceptance/features/coreApiTranslation/translation.feature new file mode 100644 index 00000000000..290a9de9379 --- /dev/null +++ b/tests/acceptance/features/coreApiTranslation/translation.feature @@ -0,0 +1,36 @@ +@api @skipOnLDAP @skipOnOcis +Feature: translate messages in api response to preferred language + As a user + I want response messages to be translated in preferred language + So that I can see and understand the response messages in my language + + Scenario Outline: user tries to get non existing share and uses some preferred language + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + And using DAV path + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Brian" has shared file "textfile0.txt" with user "Carol" + When user "Alice" gets the info of the last share in language "" using the sharing API + Then the OCS status code should be "404" + And the OCS status message should be "Wrong share ID, share doesn't exist" in language "" + Examples: + | dav_version | language | + | old | de-DE | + | old | es-ES | + | old | zh-CN | + | old | fr-FR | + | new | de-DE | + | new | es-ES | + | new | zh-CN | + | new | fr-FR | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | language | + | spaces | de-DE | + | spaces | es-ES | + | spaces | zh-CN | + | spaces | fr-FR | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature b/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature new file mode 100644 index 00000000000..ae114b9e863 --- /dev/null +++ b/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature @@ -0,0 +1,328 @@ +@api @files_trashbin-app-required @issue-ocis-reva-52 +Feature: files and folders can be deleted from the trashbin + As a user + I want to delete files and folders from the trashbin + So that I can control my trashbin space and which files are kept in that space + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "to delete" to "/textfile0.txt" + And user "Alice" has uploaded file with content "to delete" to "/textfile1.txt" + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file with content "to delete" to "/PARENT/parent.txt" + And user "Alice" has uploaded file with content "to delete" to "/PARENT/CHILD/child.txt" + + @smokeTest + Scenario Outline: Trashbin can be emptied + Given using DAV path + And user "Alice" has uploaded file with content "file with comma" to "sample,0.txt" + And user "Alice" has uploaded file with content "file with comma" to "sample,1.txt" + And user "Alice" has deleted file "" + And user "Alice" has deleted file "" + When user "Alice" empties the trashbin using the trashbin API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "" should not exist in the trashbin + And as "Alice" the file with original path "" should not exist in the trashbin + Examples: + | dav-path | filename1 | filename2 | + | new | textfile0.txt | textfile1.txt | + | new | sample,0.txt | sample,1.txt | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | filename1 | filename2 | + | spaces | textfile0.txt | textfile1.txt | + | spaces | sample,0.txt | sample,1.txt | + + @smokeTest + Scenario Outline: delete a single file from the trashbin + Given using DAV path + And user "Alice" has deleted file "/textfile0.txt" + And user "Alice" has deleted file "/textfile1.txt" + And user "Alice" has deleted file "/PARENT/parent.txt" + And user "Alice" has deleted file "/PARENT/CHILD/child.txt" + When user "Alice" deletes the file with original path "textfile1.txt" from the trashbin using the trashbin API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/textfile1.txt" should not exist in the trashbin + But as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/parent.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @smokeTest + Scenario Outline: delete multiple files from the trashbin and make sure the correct ones are gone + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/child.txt" + And user "Alice" has deleted file "/textfile0.txt" + And user "Alice" has deleted file "/textfile1.txt" + And user "Alice" has deleted file "/PARENT/parent.txt" + And user "Alice" has deleted file "/PARENT/child.txt" + And user "Alice" has deleted file "/PARENT/textfile0.txt" + And user "Alice" has deleted file "/PARENT/CHILD/child.txt" + When user "Alice" deletes the file with original path "/PARENT/textfile0.txt" from the trashbin using the trashbin API + And user "Alice" deletes the file with original path "/PARENT/CHILD/child.txt" from the trashbin using the trashbin API + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the file with original path "/PARENT/textfile0.txt" should not exist in the trashbin + And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should not exist in the trashbin + But as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/child.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: User tries to delete another user's trashbin + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has deleted file "/textfile0.txt" + And user "Alice" has deleted file "/textfile1.txt" + And user "Alice" has deleted file "/PARENT/parent.txt" + And user "Alice" has deleted file "/PARENT/CHILD/child.txt" + When user "Brian" tries to delete the file with original path "textfile1.txt" from the trashbin of user "Alice" using the trashbin API + Then the HTTP status code should be "" + And as "Alice" the file with original path "/textfile1.txt" should exist in the trashbin + And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/parent.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should exist in the trashbin + @skipOnOcis + Examples: + | dav-path | status-code | + | new | 401 | + @skipOnOcV10 @personalSpace + Examples: + | dav-path | status-code | + | new | 404 | + | spaces | 404 | + + + Scenario Outline: User tries to delete trashbin file using invalid password + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has deleted file "/textfile0.txt" + And user "Alice" has deleted file "/textfile1.txt" + And user "Alice" has deleted file "/PARENT/parent.txt" + And user "Alice" has deleted file "/PARENT/CHILD/child.txt" + When user "Brian" tries to delete the file with original path "textfile1.txt" from the trashbin of user "Alice" using the password "invalid" and the trashbin API + Then the HTTP status code should be "401" + And as "Alice" the file with original path "/textfile1.txt" should exist in the trashbin + And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/parent.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: User tries to delete trashbin file using no password + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has deleted file "/textfile0.txt" + And user "Alice" has deleted file "/textfile1.txt" + And user "Alice" has deleted file "/PARENT/parent.txt" + And user "Alice" has deleted file "/PARENT/CHILD/child.txt" + When user "Brian" tries to delete the file with original path "textfile1.txt" from the trashbin of user "Alice" using the password "" and the trashbin API + Then the HTTP status code should be "401" + And as "Alice" the file with original path "/textfile1.txt" should exist in the trashbin + And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/parent.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: delete a folder that contains a file from the trashbin + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has created folder "FOLDER/CHILD" + And user "Alice" has uploaded file with content "to delete" to "/FOLDER/parent.txt" + And user "Alice" has uploaded file with content "to delete" to "/FOLDER/CHILD/child.txt" + And user "Alice" has deleted folder "/PARENT" + And user "Alice" has deleted folder "/FOLDER" + When user "Alice" deletes the folder with original path "/PARENT" from the trashbin using the trashbin API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/PARENT/parent.txt" should not exist in the trashbin + And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should not exist in the trashbin + And as "Alice" the folder with original path "/PARENT/CHILD/" should not exist in the trashbin + But as "Alice" the file with original path "/FOLDER/parent.txt" should exist in the trashbin + And as "Alice" the file with original path "/FOLDER/CHILD/child.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: delete a subfolder from a deleted folder from the trashbin + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has created folder "FOLDER/CHILD" + And user "Alice" has uploaded file with content "to delete" to "/FOLDER/parent.txt" + And user "Alice" has uploaded file with content "to delete" to "/FOLDER/CHILD/child.txt" + And user "Alice" has deleted folder "/PARENT" + And user "Alice" has deleted folder "/FOLDER" + When user "Alice" deletes the folder with original path "/PARENT/CHILD" from the trashbin using the trashbin API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should not exist in the trashbin + And as "Alice" the folder with original path "/PARENT/CHILD/" should not exist in the trashbin + But as "Alice" the file with original path "/PARENT/parent.txt" should exist in the trashbin + But as "Alice" the file with original path "/FOLDER/parent.txt" should exist in the trashbin + And as "Alice" the file with original path "/FOLDER/CHILD/child.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: delete files with special characters from the trashbin + Given using DAV path + And user "Alice" has uploaded the following files with content "special character file" + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + And user "Alice" has deleted the following files + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + When user "Alice" deletes the following files with original path from the trashbin + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the files with following original paths should not exist in the trashbin + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: delete folders with special characters from the trashbin + Given using DAV path + And user "Alice" has created the following folders + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + And user "Alice" has deleted the following folders + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + When user "Alice" deletes the following files with original path from the trashbin + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the folders with following original paths should not exist in the trashbin + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: delete folders with dot in the name from the trashbin + Given using DAV path + And user "Alice" has created the following folders + | path | + | /fo. | + | /fo.1 | + | /fo...1.. | + | /... | + | /..fo | + | /fo.xyz | + | /fo.exe | + And user "Alice" has deleted the following folders + | path | + | /fo. | + | /fo.1 | + | /fo...1.. | + | /... | + | /..fo | + | /fo.xyz | + | /fo.exe | + When user "Alice" deletes the following files with original path from the trashbin + | path | + | /fo. | + | /fo.1 | + | /fo...1.. | + | /... | + | /..fo | + | /fo.xyz | + | /fo.exe | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the folders with following original paths should not exist in the trashbin + | path | + | /fo. | + | /fo.1 | + | /fo...1.. | + | /... | + | /..fo | + | /fo.xyz | + | /fo.exe | + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature new file mode 100644 index 00000000000..df0ce24f161 --- /dev/null +++ b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature @@ -0,0 +1,479 @@ +@api @files_trashbin-app-required @issue-ocis-reva-52 +Feature: files and folders exist in the trashbin after being deleted + As a user + I want deleted files and folders to be available in the trashbin + So that I can recover data easily + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "to delete" to "/textfile0.txt" + + @smokeTest + Scenario Outline: deleting a file moves it to trashbin + Given using DAV path + When user "Alice" deletes file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/textfile0.txt" should exist in the trashbin + But as "Alice" file "/textfile0.txt" should not exist + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @smokeTest + Scenario Outline: deleting a folder moves it to trashbin + Given using DAV path + And user "Alice" has created folder "/tmp" + When user "Alice" deletes folder "/tmp" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/tmp" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: deleting a file in a folder moves it to the trashbin root + Given using DAV path + And user "Alice" has created folder "/new-folder" + And user "Alice" has moved file "/textfile0.txt" to "/new-folder/new-file.txt" + When user "Alice" deletes file "/new-folder/new-file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/new-folder/new-file.txt" should exist in the trashbin + And as "Alice" file "/new-file.txt" should exist in the trashbin + But as "Alice" file "/new-folder/new-file.txt" should not exist + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @files_sharing-app-required + Scenario Outline: deleting a file in a shared folder moves it to the trashbin root + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + When user "Alice" deletes file "/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin + And as "Alice" file "/shared_file.txt" should exist in the trashbin + But as "Alice" file "/shared/shared_file.txt" should not exist + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @files_sharing-app-required + Scenario Outline: deleting a shared folder moves it to trashbin + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + When user "Alice" deletes folder "/shared" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the folder with original path "/shared" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @skipOnOcV10 @issue-23151 + # This scenario deletes many files as close together in time as the test can run. + # On a very slow system, the file deletes might all happen in different seconds. + # But on "reasonable" systems, some of the files will be deleted in the same second, + # thus testing the required behavior. + Scenario Outline: trashbin can store two files with the same name but different origins when the files are deleted close together in time + Given using DAV path + And user "Alice" has created folder "/folderA" + And user "Alice" has created folder "/folderB" + And user "Alice" has created folder "/folderC" + And user "Alice" has created folder "/folderD" + And user "Alice" has copied file "/textfile0.txt" to "/folderA/textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/folderB/textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/folderC/textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/folderD/textfile0.txt" + When user "Alice" deletes these files without delays using the WebDAV API + | /textfile0.txt | + | /folderA/textfile0.txt | + | /folderB/textfile0.txt | + | /folderC/textfile0.txt | + | /folderD/textfile0.txt | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the folder with original path "/folderA/textfile0.txt" should exist in the trashbin + And as "Alice" the folder with original path "/folderB/textfile0.txt" should exist in the trashbin + And as "Alice" the folder with original path "/folderC/textfile0.txt" should exist in the trashbin + And as "Alice" the folder with original path "/folderD/textfile0.txt" should exist in the trashbin + And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + # Note: the underlying acceptance test code ensures that each delete step is separated by a least 1 second + Scenario Outline: trashbin can store two files with the same name but different origins when the deletes are separated by at least 1 second + Given using DAV path + And user "Alice" has created folder "/folderA" + And user "Alice" has created folder "/folderB" + And user "Alice" has copied file "/textfile0.txt" to "/folderA/textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/folderB/textfile0.txt" + When user "Alice" deletes file "/folderA/textfile0.txt" using the WebDAV API + And user "Alice" deletes file "/folderB/textfile0.txt" using the WebDAV API + And user "Alice" deletes file "/textfile0.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the folder with original path "/folderA/textfile0.txt" should exist in the trashbin + And as "Alice" the folder with original path "/folderB/textfile0.txt" should exist in the trashbin + And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @local_storage @files_external-app-required @skipOnEncryptionType:user-keys @encryption-issue-42 @skip_on_objectstore + Scenario Outline: Deleting a folder into external storage moves it to the trashbin + Given using DAV path + And the administrator has invoked occ command "files:scan --all" + And user "Alice" has created folder "/local_storage/tmp" + And user "Alice" has moved file "/textfile0.txt" to "/local_storage/tmp/textfile0.txt" + When user "Alice" deletes folder "/local_storage/tmp" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the folder with original path "/local_storage/tmp" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @issue-ocis-3561 @skipOnLDAP @skip_on_objectstore + Scenario Outline: Listing other user's trashbin is prohibited + Given using DAV path + And user "testtrashbin100" has been created with default attributes and without skeleton files + And user "testtrashbin100" has uploaded file "filesForUpload/textfile.txt" to "/textfile1.txt" + And user "Brian" has been created with default attributes and without skeleton files + And user "testtrashbin100" has deleted file "/textfile1.txt" + When user "Brian" tries to list the trashbin content for user "testtrashbin100" + Then the HTTP status code should be "" + And the last webdav response should not contain the following elements + | path | user | + | textfile1.txt | testtrashbin100 | + @skipOnOcis + Examples: + | dav-path | status-code | + | new | 401 | + @skipOnOcV10 @personalSpace + Examples: + | dav-path | status-code | + | new | 404 | + | spaces | 404 | + + @issue-ocis-3561 @smokeTest @skipOnLDAP @skip_on_objectstore + Scenario Outline: Listing other user's trashbin is prohibited with multiple files on trashbin + Given using DAV path + And user "testtrashbin101" has been created with default attributes and without skeleton files + And user "testtrashbin101" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "testtrashbin101" has uploaded file "filesForUpload/textfile.txt" to "/textfile2.txt" + And user "Brian" has been created with default attributes and without skeleton files + And user "testtrashbin101" has deleted file "/textfile0.txt" + And user "testtrashbin101" has deleted file "/textfile2.txt" + When user "Brian" tries to list the trashbin content for user "testtrashbin101" + Then the HTTP status code should be "" + And the last webdav response should not contain the following elements + | path | user | + | textfile0.txt | testtrashbin101 | + | textfile2.txt | testtrashbin101 | + @skipOnOcis + Examples: + | dav-path | status-code | + | new | 401 | + @skipOnOcV10 @personalSpace + Examples: + | dav-path | status-code | + | new | 404 | + | spaces | 404 | + + @issue-ocis-3561 @skipOnLDAP @skip_on_objectstore @provisioning_api-app-required + Scenario Outline: Listing other user's trashbin is prohibited for newly recreated user with same name + Given using DAV path + And user "testtrashbin102" has been created with default attributes and without skeleton files + And user "testtrashbin102" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "testtrashbin102" has uploaded file "filesForUpload/textfile.txt" to "/textfile2.txt" + And user "Brian" has been created with default attributes and without skeleton files + And user "testtrashbin102" has deleted file "/textfile0.txt" + And user "testtrashbin102" has deleted file "/textfile2.txt" + And the administrator has deleted user "testtrashbin102" using the provisioning API + And user "testtrashbin102" has been created with default attributes and without skeleton files + And user "testtrashbin102" has uploaded file "filesForUpload/textfile.txt" to "/textfile3.txt" + And user "testtrashbin102" has deleted file "/textfile3.txt" + When user "Brian" tries to list the trashbin content for user "testtrashbin102" + Then the HTTP status code should be "" + And the last webdav response should not contain the following elements + | path | user | + | textfile0.txt | testtrashbin102 | + | textfile2.txt | testtrashbin102 | + | textfile3.txt | testtrashbin102 | + @skipOnOcis + Examples: + | dav-path | status-code | + | new | 401 | + @skipOnOcV10 @personalSpace + Examples: + | dav-path | status-code | + | new | 404 | + | spaces | 404 | + + @issue-ocis-3561 @skipOnLDAP @skip_on_objectstore + Scenario Outline: Listing other user's empty unused trashbin is prohibited + Given using DAV path + And user "testtrashbinempty" has been created with default attributes and without skeleton files + And user "testtrashbinempty" has uploaded file "filesForUpload/textfile.txt" to "/textfile1.txt" + When user "Alice" tries to list the trashbin content for user "testtrashbinempty" + Then the HTTP status code should be "" + @skipOnOcis + Examples: + | dav-path | status-code | + | new | 401 | + @skipOnOcV10 @personalSpace + Examples: + | dav-path | status-code | + | new | 404 | + | spaces | 404 | + + @issue-ocis-3561 @skipOnLDAP @skip_on_objectstore + Scenario Outline: Listing non-existent user's trashbin is prohibited + Given using DAV path + When user "Alice" tries to list the trashbin content for user "testtrashbinnotauser" + Then the HTTP status code should be "404" + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @smokeTest + Scenario Outline: Get trashbin content with wrong password + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has deleted file "/textfile0.txt" + When user "Alice" tries to list the trashbin content for user "Alice" using password "invalid" + Then the HTTP status code should be "401" + And the last webdav response should not contain the following elements + | path | user | + | /textfile0.txt | Alice | + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @smokeTest + Scenario Outline: Get trashbin content without password + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has deleted file "/textfile0.txt" + When user "Alice" tries to list the trashbin content for user "Alice" using password "" + Then the HTTP status code should be "401" + And the last webdav response should not contain the following elements + | path | user | + | /textfile0.txt | Alice | + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: user with unusual username deletes a file + Given using DAV path + And user "" has been created with default attributes and without skeleton files + And user "" has uploaded file with content "to delete" to "/textfile0.txt" + When user "" deletes file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "" file "/textfile0.txt" should exist in the trashbin + But as "" file "/textfile0.txt" should not exist + Examples: + | dav-path | username | + | new | dash-123 | + | new | null | + | new | nil | + | new | 123 | + | new | -123 | + | new | 0.0 | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | username | + | spaces | dash-123 | + | spaces | null | + | spaces | nil | + | spaces | 123 | + | spaces | -123 | + | spaces | 0.0 | + + + Scenario Outline: deleting a file with comma in the filename moves it to trashbin + Given using DAV path + And user "Alice" has uploaded file with content "file with comma in filename" to "sample,1.txt" + When user "Alice" deletes file "sample,1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "sample,1.txt" should exist in the trashbin + But as "Alice" file "sample,1.txt" should not exist + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: deleting a folder moves all its content to the trashbin + Given using DAV path + And user "Alice" has created folder "/new-folder" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/new-folder/new-file.txt" + When user "Alice" deletes folder "/new-folder" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/new-folder/new-file.txt" should exist in the trashbin + And as "Alice" the folder with original path "/new-folder" should exist in the trashbin + And as "Alice" file "/new-folder/new-file.txt" should exist in the trashbin + But as "Alice" file "/new-folder/new-file.txt" should not exist + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @issue-ocis-541 + Scenario Outline: deleted file has appropriate deletion time information + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2018 04:18:13 GMT" using the WebDAV API + And user "Alice" has deleted file "file.txt" + When user "Alice" tries to list the trashbin content for user "Alice" + Then the HTTP status code should be "207" + And the deleted file "file.txt" should have the correct deletion mtime in the response + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @issue-ocis-1547 + Scenario Outline: deleting files with special characters moves it to trashbin + Given using DAV path + And user "Alice" has uploaded the following files with content "special character file" + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + When user "Alice" deletes the following files + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the following files should not exist + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + But as "Alice" the files with following original paths should exist in the trashbin + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + @issue-ocis-1547 + Scenario Outline: deleting folders with special characters moves it to trashbin + Given using DAV path + And user "Alice" has created the following folders + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + When user "Alice" deletes the following folders + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + Then the HTTP status code of responses on all endpoints should be "204" + But as "Alice" the following folders should not exist + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + And as "Alice" the folders with following original paths should exist in the trashbin + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFoldersOc10Issue23151.feature b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFoldersOc10Issue23151.feature new file mode 100644 index 00000000000..578ed1c9756 --- /dev/null +++ b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFoldersOc10Issue23151.feature @@ -0,0 +1,43 @@ +@api @files_trashbin-app-required @issue-ocis-reva-52 @notToImplementOnOCIS +Feature: files and folders exist in the trashbin after being deleted + As a user + I want deleted files and folders to be available in the trashbin + So that I can recover data easily + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "to delete" to "/textfile0.txt" + + # This scenario deletes many files as close together in time as the test can run. + # On a very slow system, the file deletes might all happen in different seconds. + # But on "reasonable" systems, some of the files will be deleted in the same second, + # thus testing the required behavior. + # Note: skipOnDbOracle because Oracle is slow and so "close together in time" does not really happen + @issue-23151 @skipOnDbOracle + Scenario Outline: trashbin can store two files with the same name but different origins when the files are deleted close together in time + Given using DAV path + And user "Alice" has created folder "/folderA" + And user "Alice" has created folder "/folderB" + And user "Alice" has created folder "/folderC" + And user "Alice" has created folder "/folderD" + And user "Alice" has copied file "/textfile0.txt" to "/folderA/textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/folderB/textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/folderC/textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/folderD/textfile0.txt" + When user "Alice" deletes these files without delays using the WebDAV API + | /textfile0.txt | + | /folderA/textfile0.txt | + | /folderB/textfile0.txt | + | /folderC/textfile0.txt | + | /folderD/textfile0.txt | + Then the HTTP status code of responses on all endpoints should be "204" + # When issue-23151 is fixed, uncomment these lines. They should pass reliably. + # These files may or may not exist in the trashbin +# Then as "Alice" the folder with original path "/folderA/textfile0.txt" should not exist in the trashbin +# And as "Alice" the folder with original path "/folderB/textfile0.txt" should not exist in the trashbin +# And as "Alice" the folder with original path "/folderC/textfile0.txt" should not exist in the trashbin +# And as "Alice" the folder with original path "/folderD/textfile0.txt" should not exist in the trashbin + And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin + Examples: + | dav-path | + | new | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinSharingToRoot.feature b/tests/acceptance/features/coreApiTrashbin/trashbinSharingToRoot.feature new file mode 100644 index 00000000000..a078f13e318 --- /dev/null +++ b/tests/acceptance/features/coreApiTrashbin/trashbinSharingToRoot.feature @@ -0,0 +1,178 @@ +@api @files_trashbin-app-required @files_sharing-app-required @notToImplementOnOCIS +Feature: using trashbin together with sharing + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "to delete" to "/textfile0.txt" + + @smokeTest + Scenario Outline: deleting a received folder doesn't move it to trashbin + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has moved folder "/shared" to "/renamed_shared" + When user "Brian" deletes folder "/renamed_shared" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" the folder with original path "/renamed_shared" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: deleting a file in a received folder moves it to the trashbin of both users + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has moved file "/shared" to "/renamed_shared" + When user "Brian" deletes file "/renamed_shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" the file with original path "/renamed_shared/shared_file.txt" should exist in the trashbin + And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: sharee deleting a file in a group-shared folder moves it to the trashbin of sharee and sharer only + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with group "grp1" + When user "Brian" deletes file "/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" the file with original path "/shared/shared_file.txt" should exist in the trashbin + And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin + And as "Carol" the file with original path "/shared/shared_file.txt" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: sharer deleting a file in a group-shared folder moves it to the trashbin of sharer only + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with group "grp1" + When user "Alice" deletes file "/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin + And as "Brian" the file with original path "/shared/shared_file.txt" should not exist in the trashbin + And as "Carol" the file with original path "/shared/shared_file.txt" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: sharee deleting a folder in a group-shared folder moves it to the trashbin of sharee and sharer only + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/sub" + And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" + And user "Alice" has shared folder "/shared" with group "grp1" + When user "Brian" deletes folder "/shared/sub" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" the file with original path "/shared/sub/shared_file.txt" should exist in the trashbin + And as "Alice" the file with original path "/shared/sub/shared_file.txt" should exist in the trashbin + And as "Carol" the file with original path "/shared/sub/shared_file.txt" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: sharer deleting a folder in a group-shared folder moves it to the trashbin of sharer only + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/sub" + And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" + And user "Alice" has shared folder "/shared" with group "grp1" + When user "Alice" deletes folder "/shared/sub" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/shared/sub/shared_file.txt" should exist in the trashbin + And as "Brian" the file with original path "/shared/sub/shared_file.txt" should not exist in the trashbin + And as "Carol" the file with original path "/shared/sub/shared_file.txt" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: deleting a file in a received folder when restored it comes back to the original path + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/shared" + And user "Alice" has uploaded file with content "to delete" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has moved file "/shared" to "/renamed_shared" + And user "Brian" has deleted file "/renamed_shared/shared_file.txt" + When user "Brian" restores the file with original path "/renamed_shared/shared_file.txt" using the trashbin API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Brian" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Brian" the file with original path "/renamed_shared/shared_file.txt" should not exist in the trashbin + And user "Brian" should see the following elements + | /renamed_shared/ | + | /renamed_shared/shared_file.txt | + And the content of file "/renamed_shared/shared_file.txt" for user "Brian" should be "to delete" + Examples: + | dav-path | + | new | + + + Scenario Outline: restoring a file to a read-only folder is not allowed + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "shareFolderParent" + And user "Brian" has shared folder "shareFolderParent" with user "Alice" with permissions "read" + And as "Alice" folder "/shareFolderParent" should exist + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And user "Alice" has deleted file "/textfile0.txt" + When user "Alice" restores the file with original path "/textfile0.txt" to "/shareFolderParent/textfile0.txt" using the trashbin API + Then the HTTP status code should be "403" + And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin + And as "Alice" file "/shareFolderParent/textfile0.txt" should not exist + And as "Brian" file "/shareFolderParent/textfile0.txt" should not exist + Examples: + | dav-path | + | new | + + + Scenario Outline: restoring a file to a read-only sub-folder is not allowed + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "shareFolderParent" + And user "Brian" has created folder "shareFolderParent/shareFolderChild" + And user "Brian" has shared folder "shareFolderParent" with user "Alice" with permissions "read" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" + And as "Alice" folder "/shareFolderParent/shareFolderChild" should exist + And user "Alice" has deleted file "/textfile0.txt" + When user "Alice" restores the file with original path "/textfile0.txt" to "/shareFolderParent/shareFolderChild/textfile0.txt" using the trashbin API + Then the HTTP status code should be "403" + And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin + And as "Alice" file "/shareFolderParent/shareFolderChild/textfile0.txt" should not exist + And as "Brian" file "/shareFolderParent/shareFolderChild/textfile0.txt" should not exist + Examples: + | dav-path | + | new | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinSharingToShares.feature b/tests/acceptance/features/coreApiTrashbin/trashbinSharingToShares.feature new file mode 100644 index 00000000000..104de3fc5b6 --- /dev/null +++ b/tests/acceptance/features/coreApiTrashbin/trashbinSharingToShares.feature @@ -0,0 +1,236 @@ +@api @files_trashbin-app-required @files_sharing-app-required +Feature: using trashbin together with sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "file to delete" to "/textfile0.txt" + + @smokeTest + Scenario Outline: deleting a received folder doesn't move it to trashbin + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + And user "Brian" has moved folder "/Shares/shared" to "/Shares/renamed_shared" + When user "Brian" deletes folder "/Shares/renamed_shared" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" the folder with original path "/Shares/renamed_shared" should not exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: deleting a file in a received folder moves it to trashbin of both users + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + And user "Brian" has moved file "/Shares/shared" to "/Shares/renamed_shared" + When user "Brian" deletes file "/Shares/renamed_shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" the file with original path "/Shares/renamed_shared/shared_file.txt" should exist in the trashbin + And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: sharee deleting a file in a group-shared folder moves it to the trashbin of sharee and sharer only + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with group "grp1" + And user "Brian" has accepted share "/Shares/shared" offered by user "Alice" + And user "Carol" has accepted share "/Shares/shared" offered by user "Alice" + When user "Brian" deletes file "/Shares/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" the file with original path "/Shares/shared/shared_file.txt" should exist in the trashbin + And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin + And as "Carol" the file with original path "/Shares/shared/shared_file.txt" should not exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: sharer deleting a file in a group-shared folder moves it to the trashbin of sharer only + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with group "grp1" + And user "Brian" has accepted share "/Shares/shared" offered by user "Alice" + And user "Carol" has accepted share "/Shares/shared" offered by user "Alice" + When user "Alice" deletes file "/shared/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin + And as "Brian" the file with original path "/Shares/shared/shared_file.txt" should not exist in the trashbin + And as "Carol" the file with original path "/Shares/shared/shared_file.txt" should not exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: sharee deleting a folder in a group-shared folder moves it to the trashbin of sharee and sharer only + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/sub" + And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" + And user "Alice" has shared folder "/shared" with group "grp1" + And user "Brian" has accepted share "/Shares/shared" offered by user "Alice" + And user "Carol" has accepted share "/Shares/shared" offered by user "Alice" + When user "Brian" deletes file "/Shares/shared/sub/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" the file with original path "/Shares/shared/sub/shared_file.txt" should exist in the trashbin + And as "Alice" the file with original path "/shared/sub/shared_file.txt" should exist in the trashbin + And as "Carol" the file with original path "/Shares/sub/shared/shared_file.txt" should not exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: sharer deleting a folder in a group-shared folder moves it to the trashbin of sharer only + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/shared" + And user "Alice" has created folder "/shared/sub" + And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" + And user "Alice" has shared folder "/shared" with group "grp1" + And user "Brian" has accepted share "/Shares/shared" offered by user "Alice" + And user "Carol" has accepted share "/Shares/shared" offered by user "Alice" + When user "Alice" deletes file "/shared/sub/shared_file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/shared/sub/shared_file.txt" should exist in the trashbin + And as "Brian" the file with original path "/Shares/shared/sub/shared_file.txt" should not exist in the trashbin + And as "Carol" the file with original path "/Shares/shared/sub/shared_file.txt" should not exist in the trashbin + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: deleting a file in a received folder when restored it comes back to the original path + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/shared" + And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" + And user "Alice" has shared folder "/shared" with user "Brian" + And user "Brian" has accepted share "/shared" offered by user "Alice" + And user "Brian" has moved folder "/Shares/shared" to "/Shares/renamed_shared" + And user "Brian" has deleted file "/Shares/renamed_shared/shared_file.txt" + When user "Brian" restores the file with original path "/Shares/renamed_shared/shared_file.txt" using the trashbin API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Brian" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Brian" the file with original path "/Shares/renamed_shared/shared_file.txt" should not exist in the trashbin + And user "Brian" should see the following elements + | /Shares/renamed_shared/ | + | /Shares/renamed_shared/shared_file.txt | + And the content of file "/Shares/renamed_shared/shared_file.txt" for user "Brian" should be "file to delete" + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: restoring a file to a read-only folder + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "shareFolderParent" + And user "Brian" has shared folder "shareFolderParent" with user "Alice" with permissions "read" + And user "Alice" has accepted share "/shareFolderParent" offered by user "Brian" + And as "Alice" folder "/Shares/shareFolderParent" should exist + And user "Alice" has deleted file "/textfile0.txt" + When user "Alice" restores the file with original path "/textfile0.txt" to "/Shares/shareFolderParent/textfile0.txt" using the trashbin API + Then the HTTP status code should be "403" + And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin + And as "Alice" file "/Shares/shareFolderParent/textfile0.txt" should not exist + And as "Brian" file "/shareFolderParent/textfile0.txt" should not exist + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | + + + Scenario Outline: restoring a file to a read-only sub-folder + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "shareFolderParent" + And user "Brian" has created folder "shareFolderParent/shareFolderChild" + And user "Brian" has shared folder "shareFolderParent" with user "Alice" with permissions "read" + And user "Alice" has accepted share "/shareFolderParent" offered by user "Brian" + And as "Alice" folder "/Shares/shareFolderParent/shareFolderChild" should exist + And user "Alice" has deleted file "/textfile0.txt" + When user "Alice" restores the file with original path "/textfile0.txt" to "/Shares/shareFolderParent/shareFolderChild/textfile0.txt" using the trashbin API + Then the HTTP status code should be "403" + And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin + And as "Alice" file "/Shares/shareFolderParent/shareFolderChild/textfile0.txt" should not exist + And as "Brian" file "/shareFolderParent/shareFolderChild/textfile0.txt" should not exist + Examples: + | dav-path | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav-path | + | spaces | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinSkip.feature b/tests/acceptance/features/coreApiTrashbin/trashbinSkip.feature new file mode 100644 index 00000000000..4fe1104b4fa --- /dev/null +++ b/tests/acceptance/features/coreApiTrashbin/trashbinSkip.feature @@ -0,0 +1,323 @@ +@api @files_trashbin-app-required @notToImplementOnOCIS +Feature: files and folders can be deleted completely skipping the trashbin + As an admin + I want to configure some files to be deleted without the trashbin + So that I can control my trashbin space and which files are kept in that space + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "simple-folder" + And user "Alice" has created folder "lorem-folder" + + + Scenario Outline: Skip trashbin based on extensions + Given the administrator has set the following file extensions to be skipped from the trashbin + | extension | + | dat | + | php | + | go | + And using DAV path + And user "Alice" has uploaded file with content "sample delete file 1" to "sample.txt" + And user "Alice" has uploaded file with content "sample delete file 2" to "sample.dat" + And user "Alice" has uploaded file with content "sample delete file 3" to "sample.php" + And user "Alice" has uploaded file with content "sample delete file 4" to "sample.go" + And user "Alice" has uploaded file with content "sample delete file 5" to "sample.py" + When user "Alice" deletes the following files + | path | + | sample.txt | + | sample.dat | + | sample.php | + | sample.go | + | sample.py | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" file "sample.txt" should exist in the trashbin + And as "Alice" file "sample.py" should exist in the trashbin + But as "Alice" the file with original path "/sample.dat" should not exist in the trashbin + And as "Alice" the file with original path "/sample.php" should not exist in the trashbin + And as "Alice" the file with original path "/sample.go" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Skip trashbin based on extensions - file in a folder + Given the administrator has set the following file extensions to be skipped from the trashbin + | extension | + | dat | + | php | + | go | + And using DAV path + And user "Alice" has uploaded file with content "sample delete file 1" to "PARENT/sample.txt" + And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/sample.dat" + And user "Alice" has uploaded file with content "sample delete file 3" to "PARENT/sample.php" + And user "Alice" has uploaded file with content "sample delete file 4" to "PARENT/sample.go" + And user "Alice" has uploaded file with content "sample delete file 5" to "PARENT/sample.py" + When user "Alice" deletes the following files + | path | + | PARENT/sample.txt | + | PARENT/sample.dat | + | PARENT/sample.php | + | PARENT/sample.go | + | PARENT/sample.py | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the file with original path "/PARENT/sample.txt" should exist in the trashbin + And as "Alice" the file with original path "/PARENT/sample.py" should exist in the trashbin + But as "Alice" the file with original path "/PARENT/sample.dat" should not exist in the trashbin + And as "Alice" the file with original path "/PARENT/sample.php" should not exist in the trashbin + And as "Alice" the file with original path "/PARENT/sample.go" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Skip trashbin based on extensions - match is case-insensitive + Given the administrator has set the following file extensions to be skipped from the trashbin + | extension | + | dat | + | php | + | go | + And using DAV path + And user "Alice" has uploaded file with content "sample delete file 1" to "sample.TXT" + And user "Alice" has uploaded file with content "sample delete file 1" to "sample.txt" + And user "Alice" has uploaded file with content "sample delete file 2" to "sample.DAT" + And user "Alice" has uploaded file with content "sample delete file 2" to "sample.dat" + And user "Alice" has uploaded file with content "sample delete file 3" to "sample.PHP" + And user "Alice" has uploaded file with content "sample delete file 3" to "sample.php" + And user "Alice" has uploaded file with content "sample delete file 4" to "sample.GO" + And user "Alice" has uploaded file with content "sample delete file 4" to "sample.go" + And user "Alice" has uploaded file with content "sample delete file 5" to "sample.PY" + And user "Alice" has uploaded file with content "sample delete file 5" to "sample.py" + When user "Alice" deletes the following files + | path | + | sample.TXT | + | sample.txt | + | sample.DAT | + | sample.dat | + | sample.PHP | + | sample.php | + | sample.GO | + | sample.go | + | sample.PY | + | sample.py | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the file with original path "/sample.TXT" should exist in the trashbin + And as "Alice" the file with original path "/sample.txt" should exist in the trashbin + And as "Alice" the file with original path "/sample.PY" should exist in the trashbin + And as "Alice" the file with original path "/sample.py" should exist in the trashbin + But as "Alice" the file with original path "/sample.DAT" should not exist in the trashbin + And as "Alice" the file with original path "/sample.dat" should not exist in the trashbin + And as "Alice" the file with original path "/sample.PHP" should not exist in the trashbin + And as "Alice" the file with original path "/sample.php" should not exist in the trashbin + And as "Alice" the file with original path "/sample.GO" should not exist in the trashbin + And as "Alice" the file with original path "/sample.go" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Skip trashbin based on extensions when deleting the parent folder - skip-by-extension rules should not be applied + Given the administrator has set the following file extensions to be skipped from the trashbin + | extension | + | dat | + | php | + | go | + And using DAV path + And user "Alice" has uploaded file with content "sample delete file 1" to "PARENT/sample.txt" + And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/sample.dat" + And user "Alice" has uploaded file with content "sample delete file 3" to "PARENT/sample.php" + And user "Alice" has uploaded file with content "sample delete file 4" to "PARENT/sample.go" + And user "Alice" has uploaded file with content "sample delete file 5" to "PARENT/sample.py" + When user "Alice" deletes folder "PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "PARENT/sample.txt" should exist in the trashbin + And as "Alice" the file with original path "PARENT/sample.py" should exist in the trashbin + And as "Alice" the file with original path "PARENT/sample.dat" should exist in the trashbin + And as "Alice" the file with original path "PARENT/sample.php" should exist in the trashbin + And as "Alice" the file with original path "PARENT/sample.go" should exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Skip trashbin based on directory + Given the administrator has set the following directories to be skipped from the trashbin + | directory | + | PARENT | + | simple-folder | + And using DAV path + And user "Alice" has uploaded file with content "sample delete file 1" to "sample.txt" + And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/sample.dat" + And user "Alice" has uploaded file with content "sample delete file 3" to "simple-folder/sample.php" + And user "Alice" has uploaded file with content "sample delete file 4" to "simple-folder/sample.go" + And user "Alice" has uploaded file with content "sample delete file 5" to "lorem-folder/sample.py" + When user "Alice" deletes the following files + | path | + | sample.txt | + | PARENT/sample.dat | + | simple-folder/sample.php | + | simple-folder/sample.go | + | lorem-folder/sample.py | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the file with original path "sample.txt" should exist in the trashbin + And as "Alice" the file with original path "lorem-folder/sample.py" should exist in the trashbin + And as "Alice" the file with original path "PARENT/sample.dat" should not exist in the trashbin + But as "Alice" the file with original path "simple-folder/sample.php" should not exist in the trashbin + And as "Alice" the file with original path "simple-folder/sample.go" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Skip trashbin based on directory should match only the root folder name + Given the administrator has set the following directories to be skipped from the trashbin + | directory | + | simple-folder | + And using DAV path + And user "Alice" has created folder "PARENT/simple-folder" + And user "Alice" has uploaded file with content "sample delete file 1" to "PARENT/p.txt" + And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/simple-folder/sub.txt" + And user "Alice" has uploaded file with content "sample delete file 3" to "simple-folder/s.txt" + When user "Alice" deletes folder "PARENT" using the WebDAV API + And user "Alice" deletes folder "simple-folder" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the file with original path "PARENT/p.txt" should exist in the trashbin + And as "Alice" the file with original path "PARENT/simple-folder/sub.txt" should exist in the trashbin + But as "Alice" the file with original path "simple-folder/s.txt" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Delete a file in a folder skipped from trashbin + Given the administrator has set the following directories to be skipped from the trashbin + | directory | + | PARENT | + And using DAV path + And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/sample.dat" + When user "Alice" deletes file "PARENT/sample.dat" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "/PARENT" should not exist in the trashbin + And as "Alice" the file with original path "/PARENT/sample.dat" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Delete a file with same name as folder skipped from trashbin + Given the administrator has set the following directories to be skipped from the trashbin + | directory | + | skipFile | + And using DAV path + And user "Alice" has uploaded file with content "sample delete file 2" to "skipFile" + When user "Alice" deletes file "skipFile" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "skipFile" should exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Delete a file from a folder skipped from trashbin but different case + Given the administrator has set the following directories to be skipped from the trashbin + | directory | + | parent | + And using DAV path + And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/lorem.txt" + When user "Alice" deletes file "PARENT/lorem.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "PARENT/lorem.txt" should exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Skip file from trashbin based on size threshold + Given the administrator has set the trashbin skip size threshold to "10" + And using DAV path + And user "Alice" has uploaded file with content "sample" to "lorem.txt" + And user "Alice" has uploaded file with content "sample delete file" to "lorem.dat" + When user "Alice" deletes file "/lorem.txt" using the WebDAV API + And user "Alice" deletes file "/lorem.dat" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the file with original path "lorem.txt" should exist in the trashbin + But as "Alice" the file with original path "lorem.dat" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Skip file from trashbin based on size threshold - file in a folder + Given the administrator has set the trashbin skip size threshold to "10" + And using DAV path + And user "Alice" has uploaded file with content "sample" to "PARENT/lorem.txt" + And user "Alice" has uploaded file with content "sample delete file" to "PARENT/lorem.dat" + When user "Alice" deletes file "PARENT/lorem.txt" using the WebDAV API + And user "Alice" deletes file "PARENT/lorem.dat" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the file with original path "PARENT/lorem.txt" should exist in the trashbin + But as "Alice" the file with original path "PARENT/lorem.dat" should not exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Skip file from trashbin based on size threshold when deleting the parent folder - skip-by-size rules should not be applied + Given the administrator has set the trashbin skip size threshold to "10" + And using DAV path + And user "Alice" has uploaded file with content "sample" to "PARENT/lorem.txt" + And user "Alice" has uploaded file with content "sample delete file" to "PARENT/lorem.dat" + When user "Alice" deletes folder "PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" the file with original path "PARENT/lorem.txt" should exist in the trashbin + And as "Alice" the file with original path "PARENT/lorem.dat" should exist in the trashbin + Examples: + | dav-path | + | new | + + + Scenario Outline: Delete files when multiple skip trashbin rules are set + Given the administrator has set the following directories to be skipped from the trashbin + | directory | + | PARENT | + And the administrator has set the following file extensions to be skipped from the trashbin + | extension | + | dat | + And the administrator has set the trashbin skip size threshold to "20" + And using DAV path + # files that match none of the skip trashbin rules + And user "Alice" has uploaded file with content "sample" to "sample.txt" + And user "Alice" has uploaded file with content "sample" to "lorem-folder/sample.go" + # files that match just the "extension" skip trashbin rule + And user "Alice" has uploaded file with content "sample delete 1" to "sample.dat" + And user "Alice" has uploaded file with content "sample delete 3" to "lorem-folder/sample.dat" + # files that match just the "directory" skip trashbin rule + And user "Alice" has uploaded file with content "sample delete 2" to "PARENT/sample.txt" + # files that match just the "size threshold" skip trashbin rule + And user "Alice" has uploaded file with content "sample delete file long 2" to "simple-folder/sample.php" + # files that match 2 skip trashbin rules + And user "Alice" has uploaded file with content "sample delete file long 1" to "PARENT/sample.lis" + # files that match all 3 skip trashbin rules + And user "Alice" has uploaded file with content "sample delete file long 1" to "PARENT/sample.dat" + When user "Alice" deletes the following files + | path | + | sample.txt | + | lorem-folder/sample.go | + | sample.dat | + | lorem-folder/sample.dat | + | PARENT/sample.txt | + | simple-folder/sample.php | + | PARENT/sample.lis | + | PARENT/sample.dat | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the file with original path "sample.txt" should exist in the trashbin + And as "Alice" the file with original path "lorem-folder/sample.go" should exist in the trashbin + But as "Alice" the file with original path "sample.dat" should not exist in the trashbin + And as "Alice" the file with original path "lorem-folder/sample.dat" should not exist in the trashbin + And as "Alice" the file with original path "PARENT/sample.txt" should not exist in the trashbin + And as "Alice" the file with original path "simple-folder/sample.php" should not exist in the trashbin + And as "Alice" the file with original path "PARENT/sample.lis" should not exist in the trashbin + And as "Alice" the file with original path "PARENT/sample.dat" should not exist in the trashbin + Examples: + | dav-path | + | new | diff --git a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature new file mode 100644 index 00000000000..950f2fdc537 --- /dev/null +++ b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature @@ -0,0 +1,591 @@ +@api @files_trashbin-app-required @issue-ocis-reva-52 +Feature: Restore deleted files/folders + As a user + I would like to restore files/folders + So that I can recover accidentally deleted files/folders in ownCloud + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "file to delete" to "/textfile0.txt" + + @smokeTest + Scenario Outline: A deleted file can be restored + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "parent text" to "/PARENT/parent.txt" + And user "Alice" has uploaded file with content "text file 1" to "/textfile1.txt" + And user "Alice" has deleted file "/textfile0.txt" + And as "Alice" file "/textfile0.txt" should exist in the trashbin + When user "Alice" restores the file with original path "/textfile0.txt" using the trashbin API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" the file with original path "/textfile0.txt" should not exist in the trashbin + And the content of file "/textfile0.txt" for user "Alice" should be "file to delete" + And user "Alice" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /PARENT/parent.txt | + | /textfile0.txt | + | /textfile1.txt | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A file deleted from a folder can be restored to the original folder + Given using DAV path + And user "Alice" has created folder "/new-folder" + And user "Alice" has moved file "/textfile0.txt" to "/new-folder/new-file.txt" + And user "Alice" has deleted file "/new-folder/new-file.txt" + When user "Alice" restores the file with original path "/new-folder/new-file.txt" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" the file with original path "/new-folder/new-file.txt" should not exist in the trashbin + And as "Alice" file "/new-folder/new-file.txt" should exist + And the content of file "/new-folder/new-file.txt" for user "Alice" should be "file to delete" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A file deleted from a folder is restored to the original folder if the original folder was deleted and restored + Given using DAV path + And user "Alice" has created folder "/new-folder" + And user "Alice" has moved file "/textfile0.txt" to "/new-folder/new-file.txt" + And user "Alice" has deleted file "/new-folder/new-file.txt" + And user "Alice" has deleted folder "/new-folder" + When user "Alice" restores the folder with original path "/new-folder" using the trashbin API + And user "Alice" restores the file with original path "/new-folder/new-file.txt" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" the file with original path "/new-folder/new-file.txt" should not exist in the trashbin + And as "Alice" file "/new-folder/new-file.txt" should exist + And the content of file "/new-folder/new-file.txt" for user "Alice" should be "file to delete" + Examples: + | dav-path | + | old | + | new | + + @skipOnFilesClassifier @issue-files-classifier-291 + Scenario Outline: a file is deleted and restored to a new destination + Given using DAV path + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/CHILD" + And user "Alice" has uploaded file with content "to delete" to "" + And user "Alice" has deleted file "" + When user "Alice" restores the file with original path "" to "" using the trashbin API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" the file with original path "" should not exist in the trashbin + And as "Alice" file "" should exist + And as "Alice" file "" should not exist + And the content of file "" for user "Alice" should be "to delete" + Examples: + | dav-path | delete-path | restore-path | + | old | /PARENT/parent.txt | parent.txt | + | new | /PARENT/parent.txt | parent.txt | + | old | /PARENT/CHILD/child.txt | child.txt | + | new | /PARENT/CHILD/child.txt | child.txt | + | old | /textfile0.txt | PARENT/textfile0.txt | + | new | /textfile0.txt | PARENT/textfile0.txt | + + @skipOnOcV10 @issue-35974 + Scenario Outline: restoring a file to an already existing path overrides the file + Given user "Alice" has uploaded file with content "file to delete" to "/.hiddenfile0.txt" + And using DAV path + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "PARENT file content" to + And user "Alice" has deleted file + When user "Alice" restores the file with original path to using the trashbin API + Then the HTTP status code should be "204" + And as "Alice" file should exist + And the content of file for user "Alice" should be "file to delete" + Examples: + | dav-path | upload-path | delete-path | + | old | "/PARENT/textfile0.txt" | "/textfile0.txt" | + | new | "/PARENT/textfile0.txt" | "/textfile0.txt" | + | old | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" | + | new | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" | + + + Scenario Outline: A file deleted from a folder is restored to the original folder if the original folder was deleted and recreated + Given using DAV path + And user "Alice" has created folder "/new-folder" + And user "Alice" has moved file "/textfile0.txt" to "/new-folder/new-file.txt" + And user "Alice" has deleted file "/new-folder/new-file.txt" + And user "Alice" has deleted folder "/new-folder" + When user "Alice" creates folder "/new-folder" using the WebDAV API + And user "Alice" restores the file with original path "/new-folder/new-file.txt" using the trashbin API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" the file with original path "/new-folder/new-file.txt" should not exist in the trashbin + And as "Alice" file "/new-folder/new-file.txt" should exist + And the content of file "/new-folder/new-file.txt" for user "Alice" should be "file to delete" + Examples: + | dav-path | + | old | + | new | + + @local_storage @files_external-app-required @skipOnEncryptionType:user-keys @encryption-issue-42 @skip_on_objectstore + Scenario Outline: Deleting a file into external storage moves it to the trashbin and can be restored + Given using DAV path + And the administrator has invoked occ command "files:scan --all" + And user "Alice" has created folder "/local_storage/tmp" + And user "Alice" has moved file "/textfile0.txt" to "/local_storage/tmp/textfile0.txt" + And user "Alice" has deleted file "/local_storage/tmp/textfile0.txt" + And as "Alice" the folder with original path "/local_storage/tmp/textfile0.txt" should exist in the trashbin + When user "Alice" restores the folder with original path "/local_storage/tmp/textfile0.txt" using the trashbin API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" the folder with original path "/local_storage/tmp/textfile0.txt" should not exist in the trashbin + And the content of file "/local_storage/tmp/textfile0.txt" for user "Alice" should be "file to delete" + And user "Alice" should see the following elements + | /local_storage/ | + | /local_storage/tmp/ | + | /local_storage/tmp/textfile0.txt | + Examples: + | dav-path | + | old | + | new | + + @local_storage @files_external-app-required @skipOnEncryptionType:user-keys @encryption-issue-42 @skip_on_objectstore + Scenario: Deleting an updated file into external storage moves it to the trashbin and can be restored + Given using old DAV path + And the administrator has invoked occ command "files:scan --all" + And user "Alice" has created folder "/local_storage/tmp" + And user "Alice" has moved file "/textfile0.txt" to "/local_storage/tmp/textfile0.txt" + And user "Alice" has uploaded chunk file "1" of "1" with "AA" to "/local_storage/tmp/textfile0.txt" + And user "Alice" has deleted file "/local_storage/tmp/textfile0.txt" + And as "Alice" the folder with original path "/local_storage/tmp/textfile0.txt" should exist in the trashbin + When user "Alice" restores the folder with original path "/local_storage/tmp/textfile0.txt" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" the folder with original path "/local_storage/tmp/textfile0.txt" should not exist in the trashbin + And the content of file "/local_storage/tmp/textfile0.txt" for user "Alice" should be "AA" + + @local_storage @files_external-app-required @skipOnEncryptionType:user-keys @encryption-issue-42 @skip_on_objectstore @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Deleting an updated file into external storage moves it to the trashbin and can be restored with new chunking + Given using new DAV path + And the administrator has invoked occ command "files:scan --all" + And user "Alice" has created folder "/local_storage/tmp" + And user "Alice" has moved file "/textfile0.txt" to "/local_storage/tmp/textfile0.txt" + And user "Alice" has uploaded the following chunks to "/local_storage/tmp/textfile0.txt" with new chunking + | number | content | + | 1 | AA | + And user "Alice" has deleted file "/local_storage/tmp/textfile0.txt" + And as "Alice" the folder with original path "/local_storage/tmp/textfile0.txt" should exist in the trashbin + When user "Alice" restores the folder with original path "/local_storage/tmp/textfile0.txt" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" the folder with original path "/local_storage/tmp/textfile0.txt" should not exist in the trashbin + And the content of file "/local_storage/tmp/textfile0.txt" for user "Alice" should be "AA" + + @smokeTest + Scenario Outline: A deleted file cannot be restored by a different user + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has deleted file "/textfile0.txt" + When user "Brian" tries to restore the file with original path "/textfile0.txt" from the trashbin of user "Alice" using the trashbin API + Then the HTTP status code should be "" + And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin + And user "Alice" should not see the following elements + | /textfile0.txt | + @skipOnOcis + Examples: + | dav-path | status-code | + | old | 401 | + | new | 401 | + @skipOnOcV10 + Examples: + | dav-path | status-code | + | old | 404 | + | new | 404 | + + @smokeTest + Scenario Outline: A deleted file cannot be restored with invalid password + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has deleted file "/textfile0.txt" + When user "Alice" tries to restore the file with original path "/textfile0.txt" from the trashbin of user "Alice" using the password "invalid" and the trashbin API + Then the HTTP status code should be "401" + And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin + And user "Alice" should not see the following elements + | /textfile0.txt | + Examples: + | dav-path | + | old | + | new | + + @smokeTest + Scenario Outline: A deleted file cannot be restored without using a password + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has deleted file "/textfile0.txt" + When user "Alice" tries to restore the file with original path "/textfile0.txt" from the trashbin of user "Alice" using the password "" and the trashbin API + Then the HTTP status code should be "401" + And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin + And user "Alice" should not see the following elements + | /textfile0.txt | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: Files with strange names can be restored + Given using DAV path + And user "Alice" has uploaded file with content "file original content" to "" + And user "Alice" has deleted file "" + And user "Alice" restores the file with original path "" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" the file with original path "" should not exist in the trashbin + And as "Alice" file "" should exist + And the content of file "" for user "Alice" should be "file original content" + Examples: + | dav-path | file-to-upload | + | old | 😛 😜 🐱 🐭 ⌚️ ♀️ 🚴‍♂️ | + | new | 😛 😜 🐱 🐭 ⌚️ ♀️ 🚴‍♂️ | + | old | strängé नेपाली file | + | new | strängé नेपाली file | + | old | sample,1.txt | + | new | sample,1.txt | + + + Scenario Outline: A file deleted from a multi level sub-folder can be restored to the original folder + Given using DAV path + And user "Alice" has created folder "/new-folder" + And user "Alice" has created folder "/new-folder/folder1/" + And user "Alice" has created folder "/new-folder/folder1/folder2/" + And user "Alice" has moved file "/textfile0.txt" to "/new-folder/folder1/folder2/new-file.txt" + And user "Alice" has deleted file "/new-folder/folder1/folder2/new-file.txt" + When user "Alice" restores the file with original path "/new-folder/folder1/folder2/new-file.txt" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" the file with original path "/new-folder/folder1/folder2/new-file.txt" should not exist in the trashbin + And as "Alice" file "/new-folder/folder1/folder2/new-file.txt" should exist + And the content of file "/new-folder/folder1/folder2/new-file.txt" for user "Alice" should be "file to delete" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A deleted multi level folder can be restored including the content + Given using DAV path + And user "Alice" has created folder "/new-folder" + And user "Alice" has created folder "/new-folder/folder1/" + And user "Alice" has created folder "/new-folder/folder1/folder2/" + And user "Alice" has moved file "/textfile0.txt" to "/new-folder/folder1/folder2/new-file.txt" + And user "Alice" has deleted folder "/new-folder/" + When user "Alice" restores the folder with original path "/new-folder/" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" the file with original path "/new-folder/folder1/folder2/new-file.txt" should not exist in the trashbin + And as "Alice" file "/new-folder/folder1/folder2/new-file.txt" should exist + And the content of file "/new-folder/folder1/folder2/new-file.txt" for user "Alice" should be "file to delete" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A subfolder from a deleted multi level folder can be restored including the content + Given using DAV path + And user "Alice" has created folder "/new-folder" + And user "Alice" has created folder "/new-folder/folder1" + And user "Alice" has created folder "/new-folder/folder1/folder2" + And user "Alice" has moved file "/textfile0.txt" to "/new-folder/folder1/folder2/new-file.txt" + And user "Alice" has deleted folder "/new-folder" + When user "Alice" restores the folder with original path "/new-folder/folder1" to "/folder1" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" the file with original path "/new-folder/folder1/folder2/new-file.txt" should not exist in the trashbin + And as "Alice" the folder with original path "/new-folder/folder1" should not exist in the trashbin + And as "Alice" file "/folder1/folder2/new-file.txt" should exist + And the content of file "/folder1/folder2/new-file.txt" for user "Alice" should be "file to delete" + But as "Alice" the folder with original path "/new-folder" should exist in the trashbin + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A file from a deleted multi level sub-folder can be restored + Given using DAV path + And user "Alice" has created folder "/new-folder" + And user "Alice" has created folder "/new-folder/folder1/" + And user "Alice" has created folder "/new-folder/folder1/folder2/" + And user "Alice" has moved file "/textfile0.txt" to "/new-folder/folder1/folder2/new-file.txt" + And user "Alice" has uploaded file with content "to delete" to "/new-folder/folder1/folder2/not-restored.txt" + And user "Alice" has deleted folder "/new-folder/" + When user "Alice" restores the file with original path "/new-folder/folder1/folder2/new-file.txt" to "new-file.txt" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" the file with original path "/new-folder/folder1/folder2/new-file.txt" should not exist in the trashbin + And as "Alice" file "/new-file.txt" should exist + And the content of file "/new-file.txt" for user "Alice" should be "file to delete" + But as "Alice" the file with original path "/new-folder/folder1/folder2/not-restored.txt" should exist in the trashbin + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A deleted hidden file can be restored + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded the following files with content "hidden file" + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + And user "Alice" has deleted the following files + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + When user "Alice" restores the following files with original path + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" the files with following original paths should not exist in the trashbin + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + And as "Alice" the following files should exist + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + And the content of the following files for user "Alice" should be "hidden file" + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: restoring files with special characters + Given using DAV path + And user "Alice" has uploaded the following files with content "special character file" + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + And user "Alice" has deleted the following files + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + When user "Alice" restores the following files with original path + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" the files with following original paths should not exist in the trashbin + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + But as "Alice" the following files should exist + | path | + | qa&dev.txt | + | !@tester$^.txt | + | %file *?2.txt | + | # %ab ab?=ed.txt | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: restoring folders with special characters + Given using DAV path + And user "Alice" has created the following folders + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + And user "Alice" has deleted the following folders + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + When user "Alice" restores the following folders with original path + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" the folders with following original paths should not exist in the trashbin + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + But as "Alice" the following folders should exist + | path | + | qa&dev | + | !@tester$^ | + | %file *?2 | + | # %ab ab?=ed | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A deleted file inside a nested folder can be restored to a different location + Given using DAV path + And user "Alice" has created folder "/parent_folder" + And user "Alice" has created folder "/parent_folder/sub" + And user "Alice" has uploaded file with content "parent text" to "/parent_folder/sub/parent.txt" + And user "Alice" has deleted folder "parent_folder" + When user "Alice" restores the folder with original path "/parent_folder/sub/parent.txt" to "parent.txt" using the trashbin API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" the file with original path "/parent_folder/sub/parent.txt" should not exist in the trashbin + And the content of file "parent.txt" for user "Alice" should be "parent text" + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A deleted file inside a nested folder cannot be restored to the original location if the location doesn't exist + Given using DAV path + And user "Alice" has created folder "/parent_folder" + And user "Alice" has created folder "/parent_folder/sub" + And user "Alice" has uploaded file with content "parent text" to "/parent_folder/sub/parent.txt" + And user "Alice" has deleted folder "parent_folder" + When user "Alice" restores the folder with original path "/parent_folder/sub/parent.txt" to "/parent_folder/sub/parent.txt" using the trashbin API + Then the HTTP status code should be "409" + And as "Alice" the file with original path "/parent_folder/sub/parent.txt" should exist in the trashbin + And user "Alice" should not see the following elements + | /parent_folder/ | + | /parent_folder/sub/ | + | /parent_folder/sub/parent.txt | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A deleted file inside a nested folder can be restored to the original location if the location exists + Given using DAV path + And user "Alice" has created folder "/parent_folder" + And user "Alice" has created folder "/parent_folder/sub" + And user "Alice" has uploaded file with content "parent text" to "/parent_folder/sub/parent.txt" + And user "Alice" has deleted folder "parent_folder" + And user "Alice" has created folder "/parent_folder" + And user "Alice" has created folder "/parent_folder/sub" + When user "Alice" restores the folder with original path "/parent_folder/sub/parent.txt" using the trashbin API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" the file with original path "/parent_folder/sub/parent.txt" should not exist in the trashbin + And the content of file "/parent_folder/sub/parent.txt" for user "Alice" should be "parent text" + And user "Alice" should see the following elements + | /parent_folder/ | + | /parent_folder/sub/ | + | /parent_folder/sub/parent.txt | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A deleted file inside a nested folder cannot be restored without the destination + Given using DAV path + And user "Alice" has created folder "/parent_folder" + And user "Alice" has created folder "/parent_folder/sub" + And user "Alice" has uploaded file with content "parent text" to "/parent_folder/sub/parent.txt" + And user "Alice" has deleted folder "parent_folder" + When user "Alice" restores the folder with original path "/parent_folder/sub/parent.txt" without specifying the destination using the trashbin API + Then the HTTP status code should be "400" + And as "Alice" the file with original path "/parent_folder/sub/parent.txt" should exist in the trashbin + And user "Alice" should not see the following elements + | /parent_folder/ | + | /parent_folder/sub/ | + | /parent_folder/sub/parent.txt | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: A deleted file cannot be restored without the destination + Given using DAV path + And user "Alice" has uploaded file with content "parent text" to "/parent.txt" + And user "Alice" has deleted file "parent.txt" + When user "Alice" restores the folder with original path "parent.txt" without specifying the destination using the trashbin API + Then the HTTP status code should be "400" + And as "Alice" the file with original path "parent.txt" should exist in the trashbin + And user "Alice" should not see the following elements + | /parent.txt | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: restoring folders with dot in the name + Given using DAV path + And user "Alice" has created the following folders + | path | + | /fo. | + | /fo.1 | + | /fo...1.. | + | /... | + | /..fo | + | /fo.xyz | + | /fo.exe | + And user "Alice" has deleted the following folders + | path | + | /fo. | + | /fo.1 | + | /fo...1.. | + | /... | + | /..fo | + | /fo.xyz | + | /fo.exe | + When user "Alice" restores the following folders with original path + | path | + | /fo. | + | /fo.1 | + | /fo...1.. | + | /... | + | /..fo | + | /fo.xyz | + | /fo.exe | + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" the folders with following original paths should not exist in the trashbin + | path | + | /fo. | + | /fo.1 | + | /fo...1.. | + | /... | + | /..fo | + | /fo.xyz | + | /fo.exe | + But as "Alice" the following folders should exist + | path | + | /fo. | + | /fo.1 | + | /fo...1.. | + | /... | + | /..fo | + | /fo.xyz | + | /fo.exe | + Examples: + | dav-path | + | old | + | new | diff --git a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestoreOc10Issue35974.feature b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestoreOc10Issue35974.feature new file mode 100644 index 00000000000..3989f7d6e14 --- /dev/null +++ b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestoreOc10Issue35974.feature @@ -0,0 +1,34 @@ +@api @files_trashbin-app-required @issue-ocis-reva-52 @notToImplementOnOCIS +Feature: Restore deleted files/folders + As a user + I would like to restore files/folders + So that I can recover accidentally deleted files/folders in ownCloud + + @issue-35974 + Scenario Outline: restoring a file to an already existing path overrides the file + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "file to delete" to "/textfile0.txt" + And user "Alice" has uploaded file with content "file to delete" to "/.hiddenfile0.txt" + And using DAV path + And user "Alice" has created folder "/PARENT" + And user "Alice" has uploaded file with content "PARENT file content" to + And user "Alice" has deleted file + When user "Alice" restores the file with original path to using the trashbin API + Then the HTTP status code should be "204" + # Sometimes is found in the trashbin. Should it? Or not? + # That seems to be what happens when the restore-overwrite happens properly, + # The original seems to be "deleted" and so goes to the trashbin + #And as "Alice" the file with original path should not exist in the trashbin + And as "Alice" file should exist + # sometimes the restore from trashbin does overwrite the existing file, but sometimes it does not. That is also surprising. + # the current observed behavior is that if the original ended up in the trashbin, + # then the new has the "file to delete" content. + # otherwise has its old content + And the content of file for user "Alice" if the file is also in the trashbin should be "file to delete" otherwise "PARENT file content" + #And the content of file for user "Alice" should be "file to delete" + Examples: + | dav-path | upload-path | delete-path | + | old | "/PARENT/textfile0.txt" | "/textfile0.txt" | + | new | "/PARENT/textfile0.txt" | "/textfile0.txt" | + | old | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" | + | new | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" | diff --git a/tests/acceptance/features/coreApiVersions/fileVersionAuthor.feature b/tests/acceptance/features/coreApiVersions/fileVersionAuthor.feature new file mode 100644 index 00000000000..dd04dbbaecc --- /dev/null +++ b/tests/acceptance/features/coreApiVersions/fileVersionAuthor.feature @@ -0,0 +1,260 @@ +@api @files_versions-app-required @issue-ocis-reva-275 + +Feature: file versions remember the author of each version + + Background: + Given using OCS API version "2" + And using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And the administrator has enabled the file version storage feature + + @skip_on_objectstore + Scenario: enable file versioning and check the history of changes from multiple users + Given user "David" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + And user "Alice" has shared folder "/test" with user "Carol" with permissions "all" + And user "Alice" has shared folder "/test" with user "David" with permissions "all" + And user "Alice" has uploaded file with content "uploaded content alice" to "/test/textfile0.txt" + And user "Brian" has uploaded file with content "uploaded content brian" to "/test/textfile0.txt" + And user "Carol" has uploaded file with content "uploaded content carol" to "/test/textfile0.txt" + And user "David" has uploaded file with content "uploaded content david" to "/test/textfile0.txt" + When user "Alice" gets the number of versions of file "/test/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "3" + And the content of version index "1" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content carol" + And the content of version index "2" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content brian" + And the content of version index "3" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content alice" + And as users "Alice,Brian,Carol,David" the authors of the versions of file "/test/textfile0.txt" should be: + | index | author | + | 1 | Carol | + | 2 | Brian | + | 3 | Alice | + + @skip_on_objectstore + Scenario: enable file versioning and check the history of changes from multiple users for shared folder in the group + Given user "Alice" has created folder "/test" + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has shared folder "/test" with group "grp1" + And user "Alice" has uploaded file with content "uploaded content alice" to "/test/textfile0.txt" + And user "Brian" has uploaded file with content "uploaded content brian" to "/test/textfile0.txt" + And user "Carol" has uploaded file with content "uploaded content carol" to "/test/textfile0.txt" + When user "Alice" gets the number of versions of file "/test/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "2" + And the content of version index "1" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content brian" + And the content of version index "2" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content alice" + And as users "Alice,Brian,Carol" the authors of the versions of file "/test/textfile0.txt" should be: + | index | author | + | 1 | Brian | + | 2 | Alice | + + @skip_on_objectstore + Scenario: enable file versioning and check the history of changes from multiple users for shared file in the group + Given group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has uploaded file with content "uploaded content alice" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with group "grp1" + And user "Brian" has uploaded file with content "uploaded content brian" to "/textfile0.txt" + And user "Carol" has uploaded file with content "uploaded content carol" to "/textfile0.txt" + When user "Alice" gets the number of versions of file "textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "2" + And the content of version index "1" of file "/textfile0.txt" for user "Alice" should be "uploaded content brian" + And the content of version index "2" of file "/textfile0.txt" for user "Alice" should be "uploaded content alice" + And as users "Alice,Brian,Carol" the authors of the versions of file "/textfile0.txt" should be: + | index | author | + | 1 | Brian | + | 2 | Alice | + + @skip_on_objectstore @skipOnEncryption @issue-encryption-321 + Scenario: enable file versioning and check the history of changes from multiple users while moving file in/out of a subfolder + Given user "Alice" has created folder "/test" + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has shared folder "/test" with group "grp1" + And user "Alice" has uploaded file with content "uploaded content alice" to "/test/textfile0.txt" + And user "Brian" has uploaded file with content "uploaded content brian" to "/test/textfile0.txt" + And user "Carol" has uploaded file with content "uploaded content carol" to "/test/textfile0.txt" + And user "Brian" has moved file "/test/textfile0.txt" to "/textfile0.txt" + And user "Brian" has uploaded file with content "uploaded content brian after moving file outside subfolder" to "/textfile0.txt" + And user "Brian" has moved file "/textfile0.txt" to "/test/textfile0.txt" + When user "Alice" gets the number of versions of file "/test/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "3" + And the content of version index "1" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content carol" + And the content of version index "2" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content brian" + And the content of version index "3" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content alice" + And as users "Alice,Brian,Carol" the authors of the versions of file "/test/textfile0.txt" should be: + | index | author | + | 1 | Carol | + | 2 | Brian | + | 3 | Alice | + + @skip_on_objectstore + Scenario: enable file versioning and check the history of changes from multiple users after renaming file by sharer + Given group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has uploaded file with content "uploaded content alice" to "/exist.txt" + And user "Alice" has shared file "/exist.txt" with group "grp1" + And user "Brian" has uploaded file with content "uploaded content brian" to "/exist.txt" + And user "Carol" has uploaded file with content "uploaded content carol" to "/exist.txt" + And user "Alice" has moved file "/exist.txt" to "/textfile0.txt" + When user "Alice" gets the number of versions of file "textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "2" + And the content of version index "1" of file "/textfile0.txt" for user "Alice" should be "uploaded content brian" + And the content of version index "2" of file "/textfile0.txt" for user "Alice" should be "uploaded content alice" + And as user "Alice" the authors of the versions of file "/textfile0.txt" should be: + | index | author | + | 1 | Brian | + | 2 | Alice | + And as users "Brian,Carol" the authors of the versions of file "/exist.txt" should be: + | index | author | + | 1 | Brian | + | 2 | Alice | + + @skip_on_objectstore + Scenario: enable file versioning and check the history of changes in sharer after renaming file by sharee + Given group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has uploaded file with content "uploaded content alice" to "/exist.txt" + And user "Alice" has shared file "/exist.txt" with group "grp1" + And user "Brian" has uploaded file with content "uploaded content brian" to "/exist.txt" + And user "Carol" has uploaded file with content "uploaded content carol" to "/exist.txt" + And user "Brian" has moved file "/exist.txt" to "/textfile0.txt" + When user "Alice" gets the number of versions of file "exist.txt" + Then the HTTP status code should be "207" + And the number of versions should be "2" + And the content of version index "1" of file "/exist.txt" for user "Alice" should be "uploaded content brian" + And the content of version index "2" of file "/exist.txt" for user "Alice" should be "uploaded content alice" + And as users "Alice,Carol" the authors of the versions of file "/exist.txt" should be: + | index | author | + | 1 | Brian | + | 2 | Alice | + And as user "Brian" the authors of the versions of file "/textfile0.txt" should be: + | index | author | + | 1 | Brian | + | 2 | Alice | + + @skip_on_objectstore + Scenario: enable file versioning and check the history of changes from multiple users when reshared after unshared by sharer + Given user "Alice" has created folder "/test" + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has shared folder "/test" with group "grp1" + And user "Alice" has uploaded file with content "uploaded content alice" to "/test/textfile0.txt" + And user "Brian" has uploaded file with content "uploaded content brian" to "/test/textfile0.txt" + And user "Carol" has uploaded file with content "uploaded content carol" to "/test/textfile0.txt" + And user "Alice" has deleted the last share + And user "Alice" has uploaded file with content "uploaded content alice after unshared folder" to "/test/textfile0.txt" + And user "Alice" has shared folder "/test" with group "grp1" + When user "Alice" gets the number of versions of file "/test/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "3" + And the content of version index "1" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content carol" + And the content of version index "2" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content brian" + And the content of version index "3" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content alice" + And as users "Alice,Brian,Carol" the authors of the versions of file "/test/textfile0.txt" should be: + | index | author | + | 1 | Carol | + | 2 | Brian | + | 3 | Alice | + + @skip_on_objectstore + Scenario: enable file versioning and check the history of changes from multiple users who have a matching folder/file + Given user "David" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/test" + And user "Brian" has uploaded file with content "duplicate brian" to "/test/textfile0.txt" + And user "Brian" has uploaded file with content "overwrite brian" to "/test/textfile0.txt" + And user "Carol" has created folder "/test" + And user "Carol" has uploaded file with content "duplicate carol" to "/test/textfile0.txt" + And user "Alice" has created folder "/test" + And user "Alice" has shared folder "/test" with user "Brian" with permissions "all" + And user "Alice" has shared folder "/test" with user "Carol" with permissions "all" + And user "Alice" has shared folder "/test" with user "David" with permissions "all" + And user "Alice" has uploaded file with content "uploaded content alice" to "/test/textfile0.txt" + And user "Brian" has uploaded file with content "uploaded content brian" to "/test (2)/textfile0.txt" + And user "Carol" has uploaded file with content "uploaded content carol" to "/test (2)/textfile0.txt" + And user "David" has uploaded file with content "uploaded content david" to "/test/textfile0.txt" + When user "Alice" gets the number of versions of file "/test/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "3" + And the content of version index "1" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content carol" + And the content of version index "2" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content brian" + And the content of version index "3" of file "/test/textfile0.txt" for user "Alice" should be "uploaded content alice" + And as users "Alice,David" the authors of the versions of file "/test/textfile0.txt" should be: + | index | author | + | 1 | Carol | + | 2 | Brian | + | 3 | Alice | + And as users "Brian,Carol" the authors of the versions of file "/test (2)/textfile0.txt" should be: + | index | author | + | 1 | Carol | + | 2 | Brian | + | 3 | Alice | + When user "Brian" gets the number of versions of file "/test/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "1" + And the content of version index "1" of file "/test/textfile0.txt" for user "Brian" should be "duplicate brian" + And as user "Brian" the authors of the versions of file "/test/textfile0.txt" should be: + | index | author | + | 1 | Brian | + When user "Carol" gets the number of versions of file "/test/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "0" + + @skip_on_objectstore + Scenario: enable file versioning and check the history of changes from multiple users who have a matching file + Given user "David" has been created with default attributes and without skeleton files + And user "Brian" has uploaded file with content "duplicate brian" to "/textfile0.txt" + And user "Brian" has uploaded file with content "overwrite brian" to "/textfile0.txt" + And user "Carol" has uploaded file with content "duplicate carol" to "/textfile0.txt" + And user "Alice" has uploaded file with content "uploaded content alice" to "/textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Alice" has shared file "/textfile0.txt" with user "Carol" + And user "Alice" has shared file "/textfile0.txt" with user "David" + And user "Brian" has uploaded file with content "uploaded content brian" to "/textfile0 (2).txt" + And user "Carol" has uploaded file with content "uploaded content carol" to "/textfile0 (2).txt" + And user "David" has uploaded file with content "uploaded content david" to "/textfile0.txt" + When user "Alice" gets the number of versions of file "/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "3" + And the content of version index "1" of file "/textfile0.txt" for user "Alice" should be "uploaded content carol" + And the content of version index "2" of file "/textfile0.txt" for user "Alice" should be "uploaded content brian" + And the content of version index "3" of file "/textfile0.txt" for user "Alice" should be "uploaded content alice" + And as users "Alice,David" the authors of the versions of file "/textfile0.txt" should be: + | index | author | + | 1 | Carol | + | 2 | Brian | + | 3 | Alice | + And as users "Brian,Carol" the authors of the versions of file "/textfile0 (2).txt" should be: + | index | author | + | 1 | Carol | + | 2 | Brian | + | 3 | Alice | + When user "Brian" gets the number of versions of file "/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "1" + And the content of version index "1" of file "/textfile0.txt" for user "Brian" should be "duplicate brian" + And as user "Brian" the authors of the versions of file "/textfile0.txt" should be: + | index | author | + | 1 | Brian | + When user "Carol" gets the number of versions of file "/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "0" diff --git a/tests/acceptance/features/coreApiVersions/fileVersions.feature b/tests/acceptance/features/coreApiVersions/fileVersions.feature new file mode 100644 index 00000000000..e2f6a0ce6f2 --- /dev/null +++ b/tests/acceptance/features/coreApiVersions/fileVersions.feature @@ -0,0 +1,533 @@ +@api @files_versions-app-required @issue-ocis-reva-275 + +Feature: dav-versions + + Background: + Given using OCS API version "2" + And using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario: Upload file and no version is available + When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the version folder of file "/davtest.txt" for user "Alice" should contain "0" elements + + @issue-ocis-reva-17 @issue-ocis-reva-56 + Scenario: Upload file and no version is available using various chunking methods (except new chunking) + When user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code should be "200" + And the version folder of file "/davtest.txt-olddav-regular" for user "Alice" should contain "0" elements + And the version folder of file "/davtest.txt-newdav-regular" for user "Alice" should contain "0" elements + And the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "0" elements + + @issue-ocis-reva-17 @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload file and no version is available using new chunking + When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "201" + And the version folder of file "/davtest.txt" for user "Alice" should contain "0" elements + + @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload file and no version is available using async upload + Given the administrator has enabled async operations + When user "Alice" uploads file "filesForUpload/davtest.txt" asynchronously to "/davtest.txt" in 3 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "202" + And the version folder of file "/davtest.txt" for user "Alice" should contain "0" elements + + @smokeTest + Scenario: Upload a file twice and versions are available + When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API + And user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 204" respectively + And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element + And the content length of file "/davtest.txt" with version index "1" for user "Alice" in versions folder should be "8" + + @issue-ocis-reva-17 @issue-ocis-reva-56 + Scenario: Upload a file twice and versions are available using various chunking methods (except new chunking) + When user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms except new chunking using the WebDAV API + And user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms except new chunking using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "200" + And the version folder of file "/davtest.txt-olddav-regular" for user "Alice" should contain "1" element + And the version folder of file "/davtest.txt-newdav-regular" for user "Alice" should contain "1" element + And the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "1" element + + @issue-ocis-reva-17 @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload a file twice and versions are available using new chunking + When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" in 2 chunks with new chunking and using the WebDAV API + And user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" in 2 chunks with new chunking and using the WebDAV API + Then the HTTP status code of responses on each endpoint should be "201, 204" respectively + And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element + + @issue-ocis-reva-17 @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Scenario: Upload a file twice and versions are available using async upload + Given the administrator has enabled async operations + When user "Alice" uploads file "filesForUpload/davtest.txt" asynchronously to "/davtest.txt" in 2 chunks with new chunking and using the WebDAV API + And user "Alice" uploads file "filesForUpload/davtest.txt" asynchronously to "/davtest.txt" in 3 chunks with new chunking and using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "202" + And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element + + @smokeTest + Scenario: Remove a file + Given user "Alice" has uploaded file "filesForUpload/davtest.txt" to "/davtest.txt" + And user "Alice" has uploaded file "filesForUpload/davtest.txt" to "/davtest.txt" + And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element + And user "Alice" has deleted file "/davtest.txt" + When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the version folder of file "/davtest.txt" for user "Alice" should contain "0" elements + + @smokeTest + Scenario: Restore a file and check, if the content is now in the current file + Given user "Alice" has uploaded file with content "Test Content." to "/davtest.txt" + And user "Alice" has uploaded file with content "Content Test Updated." to "/davtest.txt" + And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element + When user "Alice" restores version index "1" of file "/davtest.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/davtest.txt" for user "Alice" should be "Test Content." + + @smokeTest @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-278 + Scenario: Restore a file back to bigger content and check, if the content is now in the current file + Given user "Alice" has uploaded file with content "Back To The Future." to "/davtest.txt" + And user "Alice" has uploaded file with content "Update Content." to "/davtest.txt" + And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element + When user "Alice" restores version index "1" of file "/davtest.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/davtest.txt" for user "Alice" should be "Back To The Future." + + @smokeTest @skipOnStorage:ceph @files_primary_s3-issue-161 @issue-ocis-reva-17 @issue-ocis-reva-56 + Scenario Outline: Uploading a chunked file does create the correct version that can be restored + Given using DAV path + And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt" + When user "Alice" uploads file "filesForUpload/davtest.txt" to "/textfile0.txt" in 2 chunks using the WebDAV API + And user "Alice" uploads file "filesForUpload/lorem.txt" to "/textfile0.txt" in 3 chunks using the WebDAV API +# HTTP status code is different for old (201) and new (204) WebDav API when uploading in chunks + Then the HTTP status code of responses on all endpoints should be "" + And the version folder of file "/textfile0.txt" for user "Alice" should contain "2" elements + When user "Alice" restores version index "1" of file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textfile0.txt" for user "Alice" should be "Dav-Test" + Examples: + | dav-path | status-code | + | old | 201 | + @notToImplementOnOCIS @newChunking @issue-ocis-1321 + Examples: + | dav-path | status-code | + | new | 204 | + + @skipOnStorage:ceph @files_primary_s3-issue-161 @notToImplementOnOCIS @newChunking @issue-ocis-1321 @issue-ocis-reva-17 @issue-ocis-reva-56 @skipOnStorage:scality + Scenario: Uploading a file asynchronously does create the correct version that can be restored + Given the administrator has enabled async operations + And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt" + When user "Alice" uploads file "filesForUpload/davtest.txt" asynchronously to "textfile0.txt" in 2 chunks using the WebDAV API + And user "Alice" uploads file "filesForUpload/lorem.txt" asynchronously to "textfile0.txt" in 2 chunks using the WebDAV API + And user "Alice" restores version index "1" of file "/textfile0.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "202" + And the version folder of file "/textfile0.txt" for user "Alice" should contain "2" elements + And the content of file "/textfile0.txt" for user "Alice" should be "Dav-Test" + + @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-156 + Scenario: Restore a file and check, if the content and correct checksum is now in the current file + Given user "Alice" has uploaded file with content "AAAAABBBBBCCCCC" and checksum "MD5:45a72715acdd5019c5be30bdbb75233e" to "/davtest.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/davtest.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" + And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element + When user "Alice" restores version index "1" of file "/davtest.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/davtest.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And as user "Alice" the webdav checksum of "/davtest.txt" via propfind should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df" + + + Scenario: User cannot access meta folder of a file which is owned by somebody else + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "123" to "/davtest.txt" + And we save it into "FILEID" + When user "Brian" sends HTTP method "PROPFIND" to URL "/remote.php/dav/meta/<>" + Then the HTTP status code should be "400" or "404" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: User can access meta folder of a file which is owned by somebody else but shared with that user + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "123" to "/davtest.txt" + And user "Alice" has uploaded file with content "456789" to "/davtest.txt" + And we save it into "FILEID" + When user "Alice" creates a share using the sharing API with settings + | path | /davtest.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read | + Then the HTTP status code should be "200" + And the version folder of fileId "<>" for user "Brian" should contain "1" element + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharer of a file can see the old version information when the sharee changes the content of the file + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "First content" to "sharefile.txt" + And user "Alice" has shared file "sharefile.txt" with user "Brian" + When user "Brian" has uploaded file with content "Second content" to "/sharefile.txt" + Then the HTTP status code should be "204" + And the version folder of file "/sharefile.txt" for user "Alice" should contain "1" element + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharer of a file can restore the original content of a shared file after the file has been modified by the sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "First content" to "sharefile.txt" + And user "Alice" has shared file "sharefile.txt" with user "Brian" + And user "Brian" has uploaded file with content "Second content" to "/sharefile.txt" + When user "Alice" restores version index "1" of file "/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharer can restore a file inside a shared folder modified by sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Alice" has uploaded file with content "First content" to "/sharingfolder/sharefile.txt" + And user "Brian" has uploaded file with content "Second content" to "/sharingfolder/sharefile.txt" + When user "Alice" restores version index "1" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharee can restore a file inside a shared folder modified by sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Alice" has uploaded file with content "First content" to "/sharingfolder/sharefile.txt" + And user "Brian" has uploaded file with content "Second content" to "/sharingfolder/sharefile.txt" + When user "Brian" restores version index "1" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharer can restore a file inside a shared folder created by sharee and modified by sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has uploaded file with content "First content" to "/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "Second content" to "/sharingfolder/sharefile.txt" + When user "Alice" restores version index "1" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharee can restore a file inside a shared folder created by sharee and modified by sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has uploaded file with content "First content" to "/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "Second content" to "/sharingfolder/sharefile.txt" + When user "Brian" restores version index "1" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharer can restore a file inside a shared folder created by sharee and modified by sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt" + And user "Brian" has uploaded file with content "new content" to "/sharingfolder/sharefile.txt" + When user "Alice" restores version index "1" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/sharingfolder/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharee can restore a file inside a shared folder created by sharer and modified by sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Alice" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "new content" to "/sharingfolder/sharefile.txt" + When user "Brian" restores version index "1" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/sharingfolder/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharee can restore a file inside a shared folder created by sharer and modified by sharer, when the folder has been moved by the sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Alice" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "new content" to "/sharingfolder/sharefile.txt" + And user "Brian" has created folder "/received" + And user "Brian" has moved folder "/sharingfolder" to "/received/sharingfolder" + When user "Brian" restores version index "1" of file "/received/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/received/sharingfolder/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharee can restore a shared file created and modified by sharer, when the file has been moved by the sharee (file is at the top level of the sharer) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "old content" to "/sharefile.txt" + And user "Alice" has uploaded file with content "new content" to "/sharefile.txt" + And user "Alice" has shared file "/sharefile.txt" with user "Brian" + And user "Brian" has created folder "/received" + And user "Brian" has moved file "/sharefile.txt" to "/received/sharefile.txt" + When user "Brian" restores version index "1" of file "/received/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/received/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharee can restore a shared file created and modified by sharer, when the file has been moved by the sharee (file is inside a folder of the sharer) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "new content" to "/sharingfolder/sharefile.txt" + And user "Alice" has shared file "/sharingfolder/sharefile.txt" with user "Brian" + And user "Brian" has created folder "/received" + And user "Brian" has moved file "/sharefile.txt" to "/received/sharefile.txt" + When user "Brian" restores version index "1" of file "/received/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/received/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required @issue-ocis-1289 @issue-ocis-1321 @notToImplementOnOCIS + Scenario: sharer can restore a file inside a group shared folder modified by sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with group "grp1" + And user "Alice" has uploaded file with content "First content" to "/sharingfolder/sharefile.txt" + And user "Brian" has uploaded file with content "Second content" to "/sharingfolder/sharefile.txt" + And user "Carol" has uploaded file with content "Third content" to "/sharingfolder/sharefile.txt" + When user "Alice" restores version index "2" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + And the content of file "/sharingfolder/sharefile.txt" for user "Carol" should be "First content" + + @files_sharing-app-required @notToImplementOnOCIS @issue-ocis-1238 + Scenario Outline: Moving a file (with versions) into a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "" has uploaded file with content "test data 1" to "/testfile.txt" + And user "" has uploaded file with content "test data 2" to "/testfile.txt" + And user "" has uploaded file with content "test data 3" to "/testfile.txt" + When user "" moves file "/testfile.txt" to "/testshare/testfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testshare/testfile.txt" for user "Alice" should be "test data 3" + And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data 3" + And as "" file "/testfile.txt" should not exist + And the version folder of file "/testshare/testfile.txt" for user "Alice" should contain "2" elements + And the version folder of file "/testshare/testfile.txt" for user "Brian" should contain "2" elements + Examples: + | dav_version | mover | + | old | Alice | + | new | Alice | + | old | Brian | + | new | Brian | + + @files_sharing-app-required @notToImplementOnOCIS @issue-ocis-1238 + Scenario Outline: Moving a file (with versions) out of a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "test data 1" to "/testshare/testfile.txt" + And user "Brian" has uploaded file with content "test data 2" to "/testshare/testfile.txt" + And user "Brian" has uploaded file with content "test data 3" to "/testshare/testfile.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + When user "" moves file "/testshare/testfile.txt" to "/testfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testfile.txt" for user "" should be "test data 3" + And as "Alice" file "/testshare/testfile.txt" should not exist + And as "Brian" file "/testshare/testfile.txt" should not exist + And the version folder of file "/testfile.txt" for user "" should contain "2" elements + Examples: + | dav_version | mover | + | old | Alice | + | new | Alice | + | old | Brian | + | new | Brian | + + @files_sharing-app-required @issue-ocis-1238 @notToImplementOnOCIS + Scenario: Receiver tries to get file versions of unshared file from the sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt" + And user "Alice" has uploaded file with content "textfile1" to "textfile1.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + When user "Brian" tries to get versions of file "textfile1.txt" from "Alice" + Then the HTTP status code should be "404" + And the value of the item "//s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" + + @skipOnStorage:ceph @files_primary_s3-issue-161 @files_sharing-app-required @notToImplementOnOCIS + Scenario: Receiver tries get file versions of shared file from the sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 1" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 2" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 3" to "textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + When user "Brian" tries to get versions of file "textfile0.txt" from "Alice" + Then the HTTP status code should be "207" + And the number of versions should be "3" + + + Scenario: User cannot access meta folder of a file which does not exist + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" sends HTTP method "PROPFIND" to URL "/remote.php/dav/meta/MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU2OjhjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA==" + Then the HTTP status code should be "400" or "404" + + + Scenario Outline: User cannot access meta folder of a file with invalid fileid + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" sends HTTP method "PROPFIND" to URL "/remote.php/dav/meta//v" + Then the HTTP status code should be "400" or "404" + Examples: + | file-id | decoded-value | comment | + | MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3PThjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA== | 1284d238-aa92-42ce-bdc4-0b0000009157=8ccd2751-90a4-40f2-b9f3-61edf84421f4 | with = sign | + | MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OGNjZDI3NTEtOTBhNC00MGYyLWI5ZjMtNjFlZGY4NDQyMWY0 | 1284d238-aa92-42ce-bdc4-0b00000091578ccd2751-90a4-40f2-b9f3-61edf84421f4 | no = sign | + | c29tZS1yYW5kb20tZmlsZUlkPWFub3RoZXItcmFuZG9tLWZpbGVJZA== | some-random-fileId=another-random-fileId | some random string | + | MTI4NGQyMzgtYWE5Mi00MmNlLWJkxzQtMGIwMDAwMDA5MTU2OjhjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA== | 1284d238-aa92-42ce-bd�4-0b0000009156:8ccd2751-90a4-40f2-b9f3-61edf84421f4 | with : and � sign | + + + Scenario: the version history is preserved when a file is renamed + Given user "Alice" has uploaded file with content "old content" to "/textfile.txt" + And user "Alice" has uploaded file with content "new content" to "/textfile.txt" + And user "Alice" has moved file "/textfile.txt" to "/renamedfile.txt" + When user "Alice" restores version index "1" of file "/renamedfile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/renamedfile.txt" for user "Alice" should be "old content" + + @issue-ocis-1238 + Scenario: User can access version number after moving a file + Given user "Alice" has created folder "testFolder" + And user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 1" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 2" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 3" to "textfile0.txt" + When user "Alice" moves file "textfile0.txt" to "/testFolder/textfile0.txt" using the WebDAV API + And user "Alice" gets the number of versions of file "/testFolder/textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "3" + + + Scenario: Original file has version number 0 + Given user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt" + When user "Alice" gets the number of versions of file "textfile0.txt" + Then the HTTP status code should be "207" + And the number of versions should be "0" + + @issue-ocis-1234 + Scenario: the number of etag elements in response changes according to version of the file + Given user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 1" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 2" to "textfile0.txt" + When user "Alice" gets the number of versions of file "textfile0.txt" + Then the HTTP status code should be "207" + And the number of etag elements in the response should be "2" + And the number of versions should be "2" + + + Scenario: download old versions of a file + Given user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 1" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 2" to "textfile0.txt" + When user "Alice" downloads the version of file "textfile0.txt" with the index "1" + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Disposition | attachment; filename*=UTF-8''textfile0.txt; filename="textfile0.txt" | + And the downloaded content should be "version 1" + When user "Alice" downloads the version of file "textfile0.txt" with the index "2" + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Disposition | attachment; filename*=UTF-8''textfile0.txt; filename="textfile0.txt" | + And the downloaded content should be "uploaded content" + + @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-463 + Scenario: download an old version of a restored file + Given user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 1" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 2" to "textfile0.txt" + And user "Alice" has restored version index "1" of file "textfile0.txt" + When user "Alice" downloads the version of file "textfile0.txt" with the index "1" + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Disposition | attachment; filename*=UTF-8''textfile0.txt; filename="textfile0.txt" | + And the downloaded content should be "version 2" + When user "Alice" downloads the version of file "textfile0.txt" with the index "2" + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Disposition | attachment; filename*=UTF-8''textfile0.txt; filename="textfile0.txt" | + And the downloaded content should be "uploaded content" + + + Scenario: User can retrieve meta information of a root folder + When user "Alice" retrieves the meta information of file "/" using the meta API + Then the HTTP status code should be "207" + And the single response should contain a property "oc:meta-path-for-user" with value "/" + + + Scenario: User can retrieve meta information of a file + Given user "Alice" has uploaded file with content "123" to "/davtest.txt" + When user "Alice" retrieves the meta information of file "/davtest.txt" using the meta API + Then the HTTP status code should be "207" + And the single response should contain a property "oc:meta-path-for-user" with value "/davtest.txt" + + + Scenario: User can retrieve meta information of a file inside folder + Given user "Alice" has created folder "testFolder" + And user "Alice" has uploaded file with content "123" to "/testFolder/davtest.txt" + When user "Alice" retrieves the meta information of file "/testFolder/davtest.txt" using the meta API + Then the HTTP status code should be "207" + And the single response should contain a property "oc:meta-path-for-user" with value "/testFolder/davtest.txt" + + + Scenario: User cannot retrieve meta information of a file which is owned by somebody else + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "123" to "/davtest.txt " + And we save it into "FILEID" + When user "Brian" retrieves the meta information of fileId "<>" using the meta API + Then the HTTP status code should be "404" + + + Scenario Outline: User cannot retrieve meta information of a file that does not exist + When user "Alice" retrieves the meta information of fileId "" using the meta API + Then the HTTP status code should be "400" or "404" + Examples: + | file-id | decoded-value | comment | + | MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3PThjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA== | 1284d238-aa92-42ce-bdc4-0b0000009157=8ccd2751-90a4-40f2-b9f3-61edf84421f4 | with = sign | + | MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OGNjZDI3NTEtOTBhNC00MGYyLWI5ZjMtNjFlZGY4NDQyMWY0 | 1284d238-aa92-42ce-bdc4-0b00000091578ccd2751-90a4-40f2-b9f3-61edf84421f4 | no = sign | + | c29tZS1yYW5kb20tZmlsZUlkPWFub3RoZXItcmFuZG9tLWZpbGVJZA== | some-random-fileId=another-random-fileId | some random string | + | MTI4NGQyMzgtYWE5Mi00MmNlLWJkxzQtMGIwMDAwMDA5MTU2OjhjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA== | 1284d238-aa92-42ce-bd�4-0b0000009156:8ccd2751-90a4-40f2-b9f3-61edf84421f4 | with : and � sign | + + + Scenario: File versions sets back after getting deleted and restored from trashbin + Given user "Alice" has uploaded file with content "Old Test Content." to "/davtest.txt" + And user "Alice" has uploaded file with content "New Test Content." to "/davtest.txt" + And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element + And user "Alice" has deleted file "/davtest.txt" + And as "Alice" file "/davtest.txt" should exist in the trashbin + When user "Alice" restores the file with original path "/davtest.txt" using the trashbin API + Then the HTTP status code should be "201" + And as "Alice" file "/davtest.txt" should exist + And the content of file "/davtest.txt" for user "Alice" should be "New Test Content." + And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element + When user "Alice" restores version index "1" of file "/davtest.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/davtest.txt" for user "Alice" should be "Old Test Content." diff --git a/tests/acceptance/features/coreApiVersions/fileVersionsSharingToShares.feature b/tests/acceptance/features/coreApiVersions/fileVersionsSharingToShares.feature new file mode 100644 index 00000000000..c53de028988 --- /dev/null +++ b/tests/acceptance/features/coreApiVersions/fileVersionsSharingToShares.feature @@ -0,0 +1,324 @@ +@api @files_versions-app-required @issue-ocis-reva-275 + +Feature: dav-versions + + Background: + Given using OCS API version "2" + And using new DAV path + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario: Upload file and no version is available + When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API + Then the version folder of file "/davtest.txt" for user "Alice" should contain "0" elements + + @files_sharing-app-required + Scenario: User can access meta folder of a file which is owned by somebody else but shared with that user + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "123" to "/davtest.txt" + And user "Alice" has uploaded file with content "456789" to "/davtest.txt" + And we save it into "FILEID" + And user "Alice" has created a share with settings + | path | /davtest.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read | + When user "Brian" accepts share "/davtest.txt" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the version folder of fileId "<>" for user "Brian" should contain "1" element + + @files_sharing-app-required + Scenario: sharer of a file can see the old version information when the sharee changes the content of the file + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "First content" to "sharefile.txt" + And user "Alice" has shared file "sharefile.txt" with user "Brian" + And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" + When user "Brian" uploads file with content "Second content" to "/Shares/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the version folder of file "/Shares/sharefile.txt" for user "Brian" should contain "1" element + And the version folder of file "/sharefile.txt" for user "Alice" should contain "1" element + + @files_sharing-app-required + Scenario: sharer of a file can restore the original content of a shared file after the file has been modified by the sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "First content" to "sharefile.txt" + And user "Alice" has shared file "sharefile.txt" with user "Brian" + And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" + And user "Brian" has uploaded file with content "Second content" to "/Shares/sharefile.txt" + When user "Alice" restores version index "1" of file "/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/Shares/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required + Scenario: sharer can restore a file inside a shared folder modified by sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has accepted share "/sharingfolder" offered by user "Alice" + And user "Alice" has uploaded file with content "First content" to "/sharingfolder/sharefile.txt" + And user "Brian" has uploaded file with content "Second content" to "/Shares/sharingfolder/sharefile.txt" + When user "Alice" restores version index "1" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required + Scenario: sharee can restore a file inside a shared folder modified by sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has accepted share "/sharingfolder" offered by user "Alice" + And user "Alice" has uploaded file with content "First content" to "/sharingfolder/sharefile.txt" + And user "Brian" has uploaded file with content "Second content" to "/Shares/sharingfolder/sharefile.txt" + When user "Brian" restores version index "1" of file "/Shares/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required + Scenario: sharer can restore a file inside a shared folder created by sharee and modified by sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has accepted share "/sharingfolder" offered by user "Alice" + And user "Brian" has uploaded file with content "First content" to "/Shares/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "Second content" to "/sharingfolder/sharefile.txt" + When user "Alice" restores version index "1" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required + Scenario: sharee can restore a file inside a shared folder created by sharee and modified by sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has accepted share "/sharingfolder" offered by user "Alice" + And user "Brian" has uploaded file with content "First content" to "/Shares/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "Second content" to "/sharingfolder/sharefile.txt" + When user "Brian" restores version index "1" of file "/Shares/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + + @files_sharing-app-required + Scenario: sharer can restore a file inside a shared folder created by sharee and modified by sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has accepted share "/sharingfolder" offered by user "Alice" + And user "Brian" has uploaded file with content "old content" to "/Shares/sharingfolder/sharefile.txt" + And user "Brian" has uploaded file with content "new content" to "/Shares/sharingfolder/sharefile.txt" + When user "Alice" restores version index "1" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required + Scenario: sharee can restore a file inside a shared folder created by sharer and modified by sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has accepted share "/sharingfolder" offered by user "Alice" + And user "Alice" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "new content" to "/sharingfolder/sharefile.txt" + When user "Brian" restores version index "1" of file "/Shares/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharee can restore a file inside a shared folder created by sharer and modified by sharer, when the folder has been moved by the sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with user "Brian" + And user "Brian" has accepted share "/sharingfolder" offered by user "Alice" + And user "Alice" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "new content" to "/sharingfolder/sharefile.txt" + And user "Brian" has created folder "/received" + And user "Brian" has moved folder "/Shares/sharingfolder" to "/received/sharingfolder" + When user "Brian" restores version index "1" of file "/received/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/received/sharingfolder/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharee can restore a shared file created and modified by sharer, when the file has been moved by the sharee (file is at the top level of the sharer) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "old content" to "/sharefile.txt" + And user "Alice" has uploaded file with content "new content" to "/sharefile.txt" + And user "Alice" has shared file "/sharefile.txt" with user "Brian" + And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" + And user "Brian" has created folder "/received" + And user "Brian" has moved file "/Shares/sharefile.txt" to "/received/sharefile.txt" + When user "Brian" restores version index "1" of file "/received/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/received/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required @notToImplementOnOCIS + Scenario: sharee can restore a shared file created and modified by sharer, when the file has been moved by the sharee (file is inside a folder of the sharer) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt" + And user "Alice" has uploaded file with content "new content" to "/sharingfolder/sharefile.txt" + And user "Alice" has shared file "/sharingfolder/sharefile.txt" with user "Brian" + And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" + And user "Brian" has created folder "/received" + And user "Brian" has moved file "/Shares/sharefile.txt" to "/received/sharefile.txt" + When user "Brian" restores version index "1" of file "/received/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "old content" + And the content of file "/received/sharefile.txt" for user "Brian" should be "old content" + + @files_sharing-app-required @issue-ocis-reva-34 + Scenario: sharer can restore a file inside a group shared folder modified by sharee + Given user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "/sharingfolder" + And user "Alice" has shared folder "/sharingfolder" with group "grp1" + And user "Brian" has accepted share "/sharingfolder" offered by user "Alice" + And user "Carol" has accepted share "/sharingfolder" offered by user "Alice" + And user "Alice" has uploaded file with content "First content" to "/sharingfolder/sharefile.txt" + And user "Brian" has uploaded file with content "Second content" to "/Shares/sharingfolder/sharefile.txt" + And user "Carol" has uploaded file with content "Third content" to "/Shares/sharingfolder/sharefile.txt" + When user "Alice" restores version index "2" of file "/sharingfolder/sharefile.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content" + And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Brian" should be "First content" + And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Carol" should be "First content" + + @files_sharing-app-required @issue-ocis-reva-386 + Scenario Outline: Moving a file (with versions) into a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + And user "" has uploaded file with content "test data 1" to "/testfile.txt" + And user "" has uploaded file with content "test data 2" to "/testfile.txt" + And user "" has uploaded file with content "test data 3" to "/testfile.txt" + When user "" moves file "/testfile.txt" to "/testfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/Shares/testshare/testfile.txt" for user "Alice" should be "test data 3" + And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data 3" + And as "" file "/testfile.txt" should not exist + And the version folder of file "/Shares/testshare/testfile.txt" for user "Alice" should contain "2" elements + And the version folder of file "/testshare/testfile.txt" for user "Brian" should contain "2" elements + Examples: + | dav_version | mover | dst-folder | + | old | Alice | /Shares/testshare | + | new | Alice | /Shares/testshare | + | old | Brian | /testshare | + | new | Brian | /testshare | + + @files_sharing-app-required @issue-ocis-reva-386 + Scenario Outline: Moving a file (with versions) out of a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "test data 1" to "/testshare/testfile.txt" + And user "Brian" has uploaded file with content "test data 2" to "/testshare/testfile.txt" + And user "Brian" has uploaded file with content "test data 3" to "/testshare/testfile.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "" moves file "/testfile.txt" to "/testfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testfile.txt" for user "" should be "test data 3" + And as "Alice" file "/Shares/testshare/testfile.txt" should not exist + And as "Brian" file "/testshare/testfile.txt" should not exist + And the version folder of file "/testfile.txt" for user "" should contain "2" elements + + @notToImplementOnOCIS + Examples: + | dav_version | mover | src-folder | + | old | Alice | /Shares/testshare | + | new | Alice | /Shares/testshare | + + + Examples: + | dav_version | mover | src-folder | + | old | Brian | /testshare | + | new | Brian | /testshare | + + @files_sharing-app-required + Scenario: Receiver tries to get file versions of unshared file from the sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt" + And user "Alice" has uploaded file with content "textfile1" to "textfile1.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" tries to get versions of file "textfile1.txt" from "Alice" + Then the HTTP status code should be "404" + And the value of the item "//s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" + + @skipOnStorage:ceph @files_primary_s3-issue-161 @files_sharing-app-required + Scenario: Receiver tries get file versions of shared file from the sharer + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 1" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 2" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 3" to "textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" tries to get versions of file "textfile0.txt" from "Alice" + Then the HTTP status code should be "207" + And the number of versions should be "3" + + + Scenario: Receiver tries get file versions of shared file before receiving it + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 1" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 2" to "textfile0.txt" + And we save it into "FILEID" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + When user "Brian" tries to get versions of file "textfile0.txt" from "Alice" + Then the HTTP status code should be "404" + And the value of the item "//s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" + + + Scenario: sharer tries get file versions of shared file when the sharee changes the content of the file + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "First content" to "sharefile.txt" + And user "Alice" has shared file "sharefile.txt" with user "Brian" + And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" + When user "Brian" has uploaded file with content "Second content" to "/Shares/sharefile.txt" + Then the HTTP status code should be "204" + And the version folder of file "/Shares/sharefile.txt" for user "Brian" should contain "1" element + And the version folder of file "/sharefile.txt" for user "Alice" should contain "1" element + + + Scenario: download old versions of a shared file as share receiver + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 1" to "textfile0.txt" + And user "Alice" has uploaded file with content "version 2" to "textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + When user "Brian" downloads the version of file "/Shares/textfile0.txt" with the index "1" + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Disposition | attachment; filename*=UTF-8''textfile0.txt; filename="textfile0.txt" | + And the downloaded content should be "version 1" + When user "Brian" downloads the version of file "/Shares/textfile0.txt" with the index "2" + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Disposition | attachment; filename*=UTF-8''textfile0.txt; filename="textfile0.txt" | + And the downloaded content should be "uploaded content" diff --git a/tests/acceptance/features/coreApiWebdavDelete/deleteFile.feature b/tests/acceptance/features/coreApiWebdavDelete/deleteFile.feature new file mode 100644 index 00000000000..a7806543151 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavDelete/deleteFile.feature @@ -0,0 +1,138 @@ +@api +Feature: delete file + As a user + I want to be able to delete files + So that I can remove unwanted data + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: delete a file + Given using DAV path + And user "Alice" has uploaded file with content "to delete" to "/textfile0.txt" + When user "Alice" deletes file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/textfile0.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: delete a file when 2 files exist with different case + Given using DAV path + And user "Alice" has uploaded file with content "to delete" to "/textfile1.txt" + And user "Alice" has uploaded file with content "uploaded content" to "/TextFile1.txt" + When user "Alice" deletes file "/textfile1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/textfile1.txt" should not exist + And as "Alice" file "/TextFile1.txt" should exist + And the content of file "/TextFile1.txt" for user "Alice" should be "uploaded content" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: delete file from folder with dots in the path + Given using DAV path + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content for file name with dots" to "/" + When user "Alice" deletes file "/" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/" should not exist + Examples: + | dav_version | folder_name | file_name | + | old | /upload. | abc. | + | old | /upload. | abc . | + | old | /upload.1 | abc.txt | + | old | /upload...1.. | abc...txt.. | + | old | /... | ... | + | old | /..upload | abc | + | old | /..upload | ..abc | + | new | /upload. | abc. | + | new | /upload. | abc . | + | new | /upload.1 | abc.txt | + | new | /upload...1.. | abc...txt.. | + | new | /... | ... | + | new | /..upload | abc | + | new | /..upload | ..abc | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | file_name | + | spaces | /upload. | abc. | + | spaces | /upload...1.. | abc...txt.. | + | spaces | /upload.1 | abc.txt | + | spaces | /upload. | abc . | + | spaces | /... | ... | + | spaces | /..upload | abc | + | spaces | /..upload | ...abc | + + + Scenario Outline: delete a file with comma in the filename + Given using DAV path + And user "Alice" has uploaded file with content "file with comma in filename" to + When user "Alice" deletes file using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file should not exist + Examples: + | dav_version | filename | + | old | "sample,1.txt" | + | old | ",,,.txt" | + | old | ",,,.," | + | new | "sample,1.txt" | + | new | ",,,.txt" | + | new | ",,,.," | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | filename | + | spaces | "sample,1.txt" | + | spaces | ",,,.txt" | + | spaces | ",,,.," | + + + Scenario Outline: delete a hidden file + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded the following files with content "hidden file" + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + When user "Alice" deletes the following files + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + Then the HTTP status code of responses on all endpoints should be "204" + And as "Alice" the following files should not exist + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario: delete a file of size zero byte + Given user "Alice" has uploaded file "filesForUpload/zerobyte.txt" to "/zerobyte.txt" + When user "Alice" deletes file "/zerobyte.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/zerobyte.txt" should not exist \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature b/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature new file mode 100644 index 00000000000..65e088bf36f --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature @@ -0,0 +1,142 @@ +@api +Feature: delete folder + As a user + I want to be able to delete folders + So that I can quickly remove unwanted data + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" creates folder "/PARENT" using the WebDAV API + + @smokeTest + Scenario Outline: delete a folder + Given using DAV path + When user "Alice" deletes folder "/PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/PARENT" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-269 + Scenario Outline: delete a folder when 2 folder exist with different case + Given using DAV path + And user "Alice" has created folder "/parent" + When user "Alice" deletes folder "/PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/PARENT" should not exist + But as "Alice" folder "/parent" should exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-269 + Scenario Outline: delete a sub-folder + Given using DAV path + And user "Alice" has created folder "/PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/PARENT/parent.txt" + When user "Alice" deletes folder "/PARENT/CHILD" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/PARENT/CHILD" should not exist + But as "Alice" folder "/PARENT" should exist + And as "Alice" file "/PARENT/parent.txt" should exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @notToImplementOnOCIS + Scenario Outline: delete a folder when there is a default folder for received shares + Given using DAV path + And the administrator has set the default folder for received shares to "" + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/Received" + And user "Brian" has created folder "/Top" + And user "Brian" has created folder "/Top/ReceivedShares" + And user "Alice" has shared folder "/PARENT" with user "Brian" + When user "Brian" deletes folder "" using the WebDAV API + Then the HTTP status code should be "403" + And as "Brian" folder "/PARENT" should exist + And user "Brian" should be able to delete folder "/Received" + And user "Brian" should be able to delete folder "/Top/ReceivedShares" + And user "Brian" should be able to delete folder "/Top" + Examples: + | dav_version | share_folder | + | old | ReceivedShares | + | old | /ReceivedShares | + | new | ReceivedShares | + | new | /ReceivedShares | + + @files_sharing-app-required @notToImplementOnOCIS + Scenario Outline: delete a folder when there is a default folder for received shares that is a multi-level path + Given using DAV path + And the administrator has set the default folder for received shares to "/My/Received/Shares" + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/M" + And user "Brian" has created folder "/Received" + And user "Brian" has created folder "/Received/Shares" + And user "Alice" has shared folder "/PARENT" with user "Brian" + When user "Brian" deletes folder "/My/Received/Shares" using the WebDAV API + Then the HTTP status code should be "403" + And user "Brian" should not be able to delete folder "/My/Received" + And user "Brian" should not be able to delete folder "/My" + And as "Brian" folder "/My/Received/Shares/PARENT" should exist + But user "Brian" should be able to delete folder "/M" + And user "Brian" should be able to delete folder "/Received/Shares" + And user "Brian" should be able to delete folder "/Received" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: deleting folder with dot in the name + Given using DAV path + And user "Alice" has created folder "" + When user "Alice" deletes folder "" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "" should not exist + Examples: + | dav_version | folder_name | + | old | /fo. | + | old | /fo.1 | + | old | /fo...1.. | + | old | /... | + | old | /..fo | + | old | /fo.xyz | + | old | /fo.exe | + | new | /fo. | + | new | /fo.1 | + | new | /fo...1.. | + | new | /... | + | new | /..fo | + | new | /fo.xyz | + | new | /fo.exe | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | + | spaces | /fo. | + | spaces | /fo.1 | + | spaces | /fo...1.. | + | spaces | /... | + | spaces | /..fo | + | spaces | /fo.xyz | + | spaces | /fo.exe | diff --git a/tests/acceptance/features/coreApiWebdavDelete/deleteFolderContents.feature b/tests/acceptance/features/coreApiWebdavDelete/deleteFolderContents.feature new file mode 100644 index 00000000000..cb14fe4d4c4 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavDelete/deleteFolderContents.feature @@ -0,0 +1,39 @@ +@api +Feature: delete folder contents + As a user + I want to be able to delete all files and folders in a folder + So that I can quickly remove unwanted data + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Removing everything of a folder + Given using DAV path + And user "Alice" has created folder "/PARENT/" + And user "Alice" has created folder "/FOLDER/" + And user "Alice" has created folder "/FOLDER/SUBFOLDER" + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/textfile1.txt" + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/FOLDER/fileToDelete.txt" + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/FOLDER/SUBFOLDER/textfile0.txt" + When user "Alice" deletes everything from folder "/FOLDER/" using the WebDAV API + Then the HTTP status code should be "204" + And user "Alice" should see the following elements + | /FOLDER/ | + | /PARENT/ | + | /textfile0.txt | + | /textfile1.txt | + And user "Alice" should not see the following elements + | /FOLDER/SUBFOLDER/ | + | /FOLDER/fileToDelete.txt | + | /FOLDER/SUBFOLDER/testfile0.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavEtagPropagation1/deleteFileFolder.feature b/tests/acceptance/features/coreApiWebdavEtagPropagation1/deleteFileFolder.feature new file mode 100644 index 00000000000..8f37b93a4de --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavEtagPropagation1/deleteFileFolder.feature @@ -0,0 +1,262 @@ +@api +Feature: propagation of etags when deleting a file or folder + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has created folder "/upload" + + + Scenario Outline: deleting a file changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + When user "Alice" deletes file "/upload/sub/file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: deleting a folder changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has created folder "/upload/sub/toDelete" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + When user "Alice" deletes folder "/upload/sub/toDelete" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: deleting a folder with content changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has created folder "/upload/sub/toDelete" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/toDelete/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + When user "Alice" deletes folder "/upload/sub/toDelete" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: as share receiver deleting a file changes the etags of all parents for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + And user "Brian" has stored etag of element "/Shares/upload/sub" + When user "Brian" deletes file "/Shares/upload/sub/file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + | Brian | /Shares/upload/sub | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: as sharer deleting a file changes the etags of all parents for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + And user "Brian" has stored etag of element "/Shares/upload/sub" + When user "Alice" deletes file "/upload/sub/file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + | Brian | /Shares/upload/sub | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: as share receiver deleting a folder changes the etags of all parents for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has created folder "/upload/sub/toDelete" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + And user "Brian" has stored etag of element "/Shares/upload/sub" + When user "Brian" deletes folder "/Shares/upload/sub/toDelete" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + | Brian | /Shares/upload/sub | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: as sharer deleting a folder changes the etags of all parents for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has created folder "/upload/sub/toDelete" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + And user "Brian" has stored etag of element "/Shares/upload/sub" + When user "Alice" deletes folder "/upload/sub/toDelete" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + | Brian | /Shares/upload/sub | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: deleting a file in a publicly shared folder changes its etag for the sharer + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has created a public link share with settings + | path | upload | + | permissions | change | + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + When the public deletes file "file.txt" from the last public link share using the new public WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: deleting a folder in a publicly shared folder changes its etag for the sharer + Given using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has created a public link share with settings + | path | upload | + | permissions | change | + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + When the public deletes folder "sub" from the last public link share using the new public WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavEtagPropagation1/moveFileFolder.feature b/tests/acceptance/features/coreApiWebdavEtagPropagation1/moveFileFolder.feature new file mode 100644 index 00000000000..bd9b3a9f48c --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavEtagPropagation1/moveFileFolder.feature @@ -0,0 +1,409 @@ +@api +Feature: propagation of etags when moving files or folders + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: renaming a file inside a folder changes its etag + Given using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + When user "Alice" moves file "/upload/file.txt" to "/upload/renamed.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: moving a file from one folder to an other changes the etags of both folders + Given using DAV path + And user "Alice" has created folder "/src" + And user "Alice" has created folder "/dst" + And user "Alice" has uploaded file with content "uploaded content" to "/src/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/src" + And user "Alice" has stored etag of element "/dst" + When user "Alice" moves file "/src/file.txt" to "/dst/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /src | + | Alice | /dst | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: moving a file into a subfolder changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has created folder "/upload/sub" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + When user "Alice" moves file "/upload/file.txt" to "/upload/sub/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: renaming a folder inside a folder changes its etag + Given using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has created folder "/upload/src" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + When user "Alice" moves folder "/upload/src" to "/upload/dst" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: moving a folder from one folder to an other changes the etags of both folders + Given using DAV path + And user "Alice" has created folder "/src" + And user "Alice" has created folder "/src/folder" + And user "Alice" has created folder "/dst" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/src" + And user "Alice" has stored etag of element "/dst" + When user "Alice" moves folder "/src/folder" to "/dst/folder" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /src | + | Alice | /dst | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: moving a folder into a subfolder changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has created folder "/upload/folder" + And user "Alice" has created folder "/upload/sub" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + When user "Alice" moves folder "/upload/folder" to "/upload/sub/folder" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: as share receiver renaming a file inside a folder changes its etag for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + When user "Brian" moves file "/Shares/upload/file.txt" to "/Shares/upload/renamed.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: as sharer renaming a file inside a folder changes its etag for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + When user "Alice" moves file "/upload/file.txt" to "/upload/renamed.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: as sharer moving a file from one folder to an other changes the etags of both folders for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/src" + And user "Alice" has created folder "/dst" + And user "Alice" has uploaded file with content "uploaded content" to "/src/file.txt" + And user "Alice" has shared folder "/src" with user "Brian" + And user "Brian" has accepted share "/src" offered by user "Alice" + And user "Alice" has shared folder "/dst" with user "Brian" + And user "Brian" has accepted share "/dst" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/src" + And user "Alice" has stored etag of element "/dst" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/src" + And user "Brian" has stored etag of element "/Shares/dst" + When user "Alice" moves file "/src/file.txt" to "/dst/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /src | + | Alice | /dst | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/src | + | Brian | /Shares/dst | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: as share receiver moving a file from one folder to an other changes the etags of both folders for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/src" + And user "Alice" has created folder "/dst" + And user "Alice" has uploaded file with content "uploaded content" to "/src/file.txt" + And user "Alice" has shared folder "/src" with user "Brian" + And user "Brian" has accepted share "/src" offered by user "Alice" + And user "Alice" has shared folder "/dst" with user "Brian" + And user "Brian" has accepted share "/dst" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/src" + And user "Alice" has stored etag of element "/dst" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/src" + And user "Brian" has stored etag of element "/Shares/dst" + When user "Brian" moves file "/Shares/src/file.txt" to "/Shares/dst/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /src | + | Alice | /dst | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/src | + | Brian | /Shares/dst | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: as sharer moving a folder from one folder to an other changes the etags of both folders for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/src" + And user "Alice" has created folder "/dst" + And user "Alice" has created folder "/src/toMove" + And user "Alice" has shared folder "/src" with user "Brian" + And user "Brian" has accepted share "/src" offered by user "Alice" + And user "Alice" has shared folder "/dst" with user "Brian" + And user "Brian" has accepted share "/dst" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/src" + And user "Alice" has stored etag of element "/dst" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/src" + And user "Brian" has stored etag of element "/Shares/dst" + When user "Alice" moves folder "/src/toMove" to "/dst/toMove" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /src | + | Alice | /dst | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/src | + | Brian | /Shares/dst | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: as share receiver moving a folder from one folder to an other changes the etags of both folders for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/src" + And user "Alice" has created folder "/dst" + And user "Alice" has created folder "/src/toMove" + And user "Alice" has shared folder "/src" with user "Brian" + And user "Brian" has accepted share "/src" offered by user "Alice" + And user "Alice" has shared folder "/dst" with user "Brian" + And user "Brian" has accepted share "/dst" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/src" + And user "Alice" has stored etag of element "/dst" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/src" + And user "Brian" has stored etag of element "/Shares/dst" + When user "Brian" moves folder "/Shares/src/toMove" to "/Shares/dst/toMove" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /src | + | Alice | /dst | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/src | + | Brian | /Shares/dst | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: renaming a file in a publicly shared folder changes its etag for the sharer + Given using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has created a public link share with settings + | path | upload | + | permissions | change | + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + When the public renames file "file.txt" to "renamed.txt" from the last public link share using the new public WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: renaming a folder in a publicly shared folder changes its etag for the sharer + Given using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has created folder "/upload/sub" + And user "Alice" has created a public link share with settings + | path | upload | + | permissions | change | + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + When the public renames folder "sub" to "renamed" from the last public link share using the new public WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavEtagPropagation2/copyFileFolder.feature b/tests/acceptance/features/coreApiWebdavEtagPropagation2/copyFileFolder.feature new file mode 100644 index 00000000000..0d2be53815a --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavEtagPropagation2/copyFileFolder.feature @@ -0,0 +1,230 @@ +@api +Feature: propagation of etags when copying files or folders + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @issue-product-280 + Scenario Outline: copying a file does not change its etag + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/file.txt" + And user "Alice" has stored etag of element "/file.txt" on path "/renamedFile.txt" + When user "Alice" copies file "/file.txt" to "/renamedFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should not have changed: + | user | path | + | Alice | /file.txt | + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /renamedFile.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: copying a file inside a folder changes its etag + Given using DAV path + And user "Alice" has created folder "/folder" + And user "Alice" has uploaded file with content "uploaded content" to "file.txt" + And user "Alice" has stored etag of element "/file.txt" + And user "Alice" has stored etag of element "/folder" + And user "Alice" has stored etag of element "/file.txt" on path "/folder/renamedFile.txt" + When user "Alice" copies file "/file.txt" to "/folder/renamedFile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should not have changed: + | user | path | + | Alice | /file.txt | + And these etags should have changed: + | user | path | + | Alice | /folder/renamedFile.txt | + | Alice | /folder | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: copying a file from one folder to an other changes the etags of destination + Given using DAV path + And user "Alice" has created folder "/src" + And user "Alice" has uploaded file with content "uploaded content" to "/src/file.txt" + And user "Alice" has created folder "/dst" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/src" + And user "Alice" has stored etag of element "/dst" + When user "Alice" copies folder "/src/file.txt" to "/dst/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /dst | + And these etags should not have changed: + | user | path | + | Alice | /src | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: copying a file into a subfolder changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has created folder "/upload/sub" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/file.txt" + And user "Alice" has stored etag of element "/upload/file.txt" on path "/upload/sub/file.txt" + And user "Alice" has stored etag of element "/upload/sub" + When user "Alice" copies file "/upload/file.txt" to "/upload/sub/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + | Alice | /upload/sub/file.txt | + And these etags should not have changed: + | user | path | + | Alice | /upload/file.txt | + @issue-ocis-4091 + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: copying a file inside a publicly shared folder by public changes etag for the sharer + Given using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has created a public link share with settings + | path | upload | + | permissions | change | + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/file.txt" + And user "Alice" has stored etag of element "/upload/file.txt" on path "/upload/renamedFile.txt" + When the public copies file "file.txt" to "/renamedFile.txt" using the new public WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/renamedFile.txt | + And these etags should not have changed: + | user | path | + | Alice | /upload/file.txt | + @issue-ocis-4091 + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: as share receiver copying a file inside a folder changes its etag for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/file.txt" + And user "Alice" has stored etag of element "/upload/file.txt" on path "/upload/renamed.txt" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + And user "Brian" has stored etag of element "/Shares/upload/file.txt" + And user "Brian" has stored etag of element "/Shares/upload/file.txt" on path "/Shares/upload/renamed.txt" + When user "Brian" copies file "/Shares/upload/file.txt" to "/Shares/upload/renamed.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/renamed.txt | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + | Brian | /Shares/upload/renamed.txt | + And these etags should not have changed: + | user | path | + | Alice | /upload/file.txt | + | Brian | /Shares/upload/file.txt | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: as sharer copying a file inside a folder changes its etag for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And using DAV path + And user "Alice" has created folder "/upload" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/file.txt" + And user "Alice" has stored etag of element "/upload/file.txt" on path "/upload/renamed.txt" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + And user "Brian" has stored etag of element "/Shares/upload/file.txt" + And user "Brian" has stored etag of element "/Shares/upload/file.txt" on path "/Shares/upload/renamed.txt" + When user "Alice" copies file "/upload/file.txt" to "/upload/renamed.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/renamed.txt | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + | Brian | /Shares/upload/renamed.txt | + And these etags should not have changed: + | user | path | + | Alice | /upload/file.txt | + | Brian | /Shares/upload/file.txt | + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/coreApiWebdavEtagPropagation2/createFolder.feature b/tests/acceptance/features/coreApiWebdavEtagPropagation2/createFolder.feature new file mode 100644 index 00000000000..c907fb2f991 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavEtagPropagation2/createFolder.feature @@ -0,0 +1,131 @@ +@api +Feature: propagation of etags when creating folders + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + + @issue-product-280 + Scenario Outline: creating a folder inside a folder changes its etag + Given using DAV path + And user "Alice" has created folder "/folder" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/folder" + When user "Alice" creates folder "/folder/new" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /folder | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: creating an invalid folder inside a folder should not change any etags + Given using DAV path + And user "Alice" has created folder "/folder" + And user "Alice" has created folder "/folder/sub" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/folder" + And user "Alice" has stored etag of element "/folder/sub" + When user "Alice" creates folder "/folder/sub/.." using the WebDAV API + Then the HTTP status code should be "405" + And these etags should not have changed: + | user | path | + | Alice | / | + | Alice | /folder | + | Alice | /folder/sub | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: as share receiver creating a folder inside a folder received as a share changes its etag for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And using DAV path + And user "Alice" has created folder "/folder" + And user "Alice" has shared folder "/folder" with user "Brian" + And user "Brian" has accepted share "/folder" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/folder" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/folder" + When user "Brian" creates folder "/Shares/folder/new" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /folder | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/folder | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: as a sharer creating a folder inside a shared folder changes etag for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And using DAV path + And user "Alice" has created folder "/folder" + And user "Alice" has shared folder "/folder" with user "Brian" + And user "Brian" has accepted share "/folder" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/folder" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/folder" + When user "Alice" creates folder "/folder/new" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /folder | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/folder | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: creating a folder in a publicly shared folder changes its etag for the sharer + Given using DAV path + And user "Alice" has created folder "/folder" + And user "Alice" has created a public link share with settings + | path | folder | + | permissions | create | + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/folder" + When the public creates folder "created-by-public" using the new public WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /folder | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavEtagPropagation2/restoreFromTrash.feature b/tests/acceptance/features/coreApiWebdavEtagPropagation2/restoreFromTrash.feature new file mode 100644 index 00000000000..3536355ecf1 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavEtagPropagation2/restoreFromTrash.feature @@ -0,0 +1,94 @@ +@api +Feature: propagation of etags when restoring a file or folder from trash + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/upload" + + + Scenario Outline: restoring a file to its original location changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt" + And user "Alice" has deleted file "/upload/sub/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + When user "Alice" restores the file with original path "/upload/sub/file.txt" using the trashbin API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: restoring a file to an other location changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has created folder "/restore" + And user "Alice" has created folder "/restore/sub" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt" + And user "Alice" has deleted file "/upload/sub/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/restore" + And user "Alice" has stored etag of element "/restore/sub" + When user "Alice" restores the file with original path "/upload/sub/file.txt" to "/restore/sub/file.txt" using the trashbin API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /restore | + | Alice | /restore/sub | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: restoring a folder to its original location changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has created folder "/upload/sub/toDelete" + And user "Alice" has deleted folder "/upload/sub/toDelete" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + When user "Alice" restores the folder with original path "/upload/sub/toDelete" using the trashbin API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: restoring a folder to an other location changes the etags of all parents + Given using DAV path + And user "Alice" has created folder "/upload/sub" + And user "Alice" has created folder "/upload/sub/toDelete" + And user "Alice" has deleted folder "/upload/sub/toDelete" + And user "Alice" has created folder "/restore" + And user "Alice" has created folder "/restore/sub" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/restore" + And user "Alice" has stored etag of element "/restore/sub" + When user "Alice" restores the folder with original path "/upload/sub/toDelete" to "/restore/sub/toDelete" using the trashbin API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /restore | + | Alice | /restore/sub | + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/coreApiWebdavEtagPropagation2/restoreVersion.feature b/tests/acceptance/features/coreApiWebdavEtagPropagation2/restoreVersion.feature new file mode 100644 index 00000000000..c4c64e8f3fb --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavEtagPropagation2/restoreVersion.feature @@ -0,0 +1,24 @@ +@api @issue-product-280 +Feature: propagation of etags when restoring a version of a file + + Background: + Given using OCS API version "2" + And using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + + @skipOnStorage:ceph @skipOnStorage:scality @issue-files_primary_s3-387 + Scenario: Restoring a file changes the etags of all parents + Given user "Alice" has created folder "/upload" + And user "Alice" has created folder "/upload/sub" + And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt" + And user "Alice" has uploaded file with content "changed content" to "/upload/sub/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/sub" + When user "Alice" restores version index "1" of file "/upload/sub/file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/sub | diff --git a/tests/acceptance/features/coreApiWebdavEtagPropagation2/upload.feature b/tests/acceptance/features/coreApiWebdavEtagPropagation2/upload.feature new file mode 100644 index 00000000000..c9c96a68d10 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavEtagPropagation2/upload.feature @@ -0,0 +1,179 @@ +@api +Feature: propagation of etags when uploading data + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has set the default folder for received shares to "Shares" + And parameter "shareapi_auto_accept_share" of app "core" has been set to "no" + And user "Alice" has created folder "/upload" + + @issue-product-280 + Scenario Outline: uploading a file inside a folder changes its etag + Given using DAV path + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + When user "Alice" uploads file with content "uploaded content" to "/upload/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: overwriting a file inside a folder changes its etag + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Alice" has stored etag of element "/upload/file.txt" + When user "Alice" uploads file with content "new content" to "/upload/file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Alice | /upload/file.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-product-280 + Scenario Outline: as share receiver uploading a file inside a received shared folder should update etags for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And using DAV path + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + When user "Brian" uploads file with content "uploaded content" to "/Shares/upload/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: as sharer uploading a file inside a shared folder should update etags for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And using DAV path + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + When user "Alice" uploads file with content "uploaded content" to "/upload/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: as share receiver overwriting a file inside a received shared folder should update etags for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + When user "Brian" uploads file with content "new content" to "/Shares/upload/file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: as sharer overwriting a file inside a shared folder should update etags for all collaborators + Given user "Brian" has been created with default attributes and without skeleton files + And using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" + And user "Alice" has shared folder "/upload" with user "Brian" + And user "Brian" has accepted share "/upload" offered by user "Alice" + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + And user "Brian" has stored etag of element "/" + And user "Brian" has stored etag of element "/Shares" + And user "Brian" has stored etag of element "/Shares/upload" + When user "Alice" uploads file with content "new content" to "/upload/file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + | Brian | / | + | Brian | /Shares | + | Brian | /Shares/upload | + Examples: + | dav_version | + | old | + | new | + + @issue-product-280 + Scenario Outline: uploading a file into a publicly shared folder changes its etag for the sharer + Given using DAV path + And user "Alice" has created a public link share with settings + | path | upload | + | permissions | create | + And user "Alice" has stored etag of element "/" + And user "Alice" has stored etag of element "/upload" + When the public uploads file "file.txt" with content "new content" using the new public WebDAV API + Then the HTTP status code should be "201" + And these etags should have changed: + | user | path | + | Alice | / | + | Alice | /upload | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature b/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature new file mode 100644 index 00000000000..34850981d3c --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature @@ -0,0 +1,187 @@ +@api @issue-ocis-reva-172 +Feature: there can be only one exclusive lock on a resource + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: a second lock cannot be set on a folder when its exclusively locked + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | exclusive | + When user "Alice" locks file "textfile0.txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "423" + And 1 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | + + @notToImplementOnOCIS + Scenario Outline: if a parent resource is exclusively locked a child resource cannot be locked again + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | exclusive | + When user "Alice" locks folder "PARENT/CHILD" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "423" + And 1 locks should be reported for file "PARENT/CHILD/child.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @notToImplementOnOCIS + Scenario Outline: if a parent resource is exclusively locked with depth 0 a child resource can be locked again + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | exclusive | + | depth | 0 | + When user "Alice" locks folder "PARENT/CHILD" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And 1 locks should be reported for file "PARENT/CHILD/child.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @skipOnOcV10 @issue-34358 @notToImplementOnOCIS + Scenario Outline: if a child resource is exclusively locked a parent resource cannot be locked again + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | exclusive | + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "423" + And 1 locks should be reported for file "PARENT/CHILD/child.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @notToImplementOnOCIS + Scenario Outline: if a child resource is exclusively locked a parent resource can be locked with depth 0 + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | exclusive | + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | | + | depth | 0 | + Then the HTTP status code should be "200" + And 1 locks should be reported for file "PARENT/CHILD/child.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @files_sharing-app-required + Scenario Outline: a share receiver cannot lock a resource exclusively locked by itself + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has locked file "textfile0 (2).txt" setting the following properties + | lockscope | exclusive | + When user "Brian" locks file "textfile0 (2).txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "423" + And 1 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "textfile0 (2).txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | + + @files_sharing-app-required + Scenario Outline: a share receiver cannot lock a resource exclusively locked by the owner + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | exclusive | + When user "Brian" locks file "textfile0 (2).txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "423" + And 1 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "textfile0 (2).txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | + + @files_sharing-app-required + Scenario Outline: a share owner cannot lock a resource exclusively locked by a share receiver + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has locked file "textfile0 (2).txt" setting the following properties + | lockscope | exclusive | + When user "Alice" locks file "textfile0.txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "423" + And 1 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "textfile0 (2).txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocksOc10Issue34358.feature b/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocksOc10Issue34358.feature new file mode 100644 index 00000000000..5cd973e747c --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocksOc10Issue34358.feature @@ -0,0 +1,22 @@ +@api @notToImplementOnOCIS @issue-ocis-reva-172 +Feature: there can be only one exclusive lock on a resource + + @issue-34358 + Scenario Outline: if a child resource is exclusively locked a parent resource cannot be locked again + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And using DAV path + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | exclusive | + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And 2 locks should be reported for file "PARENT/CHILD/child.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks/folder.feature b/tests/acceptance/features/coreApiWebdavLocks/folder.feature new file mode 100644 index 00000000000..d87871b046d --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks/folder.feature @@ -0,0 +1,128 @@ +@api @issue-ocis-reva-172 +Feature: lock folders + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest @notToImplementOnOCIS + Scenario Outline: upload to a locked folder + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has locked folder "FOLDER" setting the following properties + | lockscope | | + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/FOLDER/textfile.txt" using the WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/FOLDER/textfile.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @notToImplementOnOCIS + Scenario Outline: upload to a subfolder of a locked folder + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/CHILD/textfile.txt" using the WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/PARENT/CHILD/textfile.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @smokeTest @notToImplementOnOCIS + Scenario Outline: create folder in a locked folder + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has locked folder "FOLDER" setting the following properties + | lockscope | | + When user "Alice" creates folder "/FOLDER/new-folder" using the WebDAV API + Then the HTTP status code should be "423" + And as "Alice" folder "/FOLDER/new-folder" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @notToImplementOnOCIS + Scenario Outline: create folder in a subfolder of a locked folder + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Alice" creates folder "/PARENT/CHILD/new-folder" using the WebDAV API + Then the HTTP status code should be "423" + And as "Alice" folder "/PARENT/CHILD/new-folder" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @notToImplementOnOCIS + Scenario Outline: Move file out of a locked folder + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Alice" moves file "/PARENT/parent.txt" to "/parent.txt" using the WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/parent.txt" should not exist + But as "Alice" file "/PARENT/parent.txt" should exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @notToImplementOnOCIS + Scenario Outline: Move file out of a locked sub folder one level higher into locked parent folder + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Alice" moves file "/PARENT/CHILD/child.txt" to "/PARENT/child.txt" using the WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/PARENT/child.txt" should not exist + But as "Alice" file "/PARENT/CHILD/child.txt" should exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @notToImplementOnOCIS + Scenario Outline: lockdiscovery of a locked folder + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Alice" gets the following properties of folder "PARENT" using the WebDAV API + | propertyName | + | d:lockdiscovery | + Then the HTTP status code should be "200" + And the value of the item "//d:lockroot/d:href" in the response to user "Alice" should match "" + And the value of the item "//d:locktoken/d:href" in the response to user "Alice" should match "/^opaquelocktoken:[a-z0-9-]+$/" + Examples: + | dav-path | lock-scope | lock-root | + | old | shared | /%base_path%\/remote.php\/webdav\/PARENT$/ | + | old | exclusive | /%base_path%\/remote.php\/webdav\/PARENT$/ | + | new | shared | /%base_path%\/remote.php\/dav\/files\/%username%\/PARENT$/ | + | new | exclusive | /%base_path%\/remote.php\/dav\/files\/%username%\/PARENT$/ | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavLocks/publicLink.feature b/tests/acceptance/features/coreApiWebdavLocks/publicLink.feature new file mode 100644 index 00000000000..bf020e32b22 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks/publicLink.feature @@ -0,0 +1,100 @@ +@api @smokeTest @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-172 @notToImplementOnOCIS +Feature: persistent-locking in case of a public link + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + + @smokeTest + Scenario Outline: Uploading a file into a locked public folder + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has created a public link share of folder "FOLDER" with change permission + And user "Alice" has locked folder "FOLDER" setting the following properties + | lockscope | | + When the public uploads file "/test.txt" with content "test" using the public WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/FOLDER/test.txt" should not exist + Examples: + | dav-path | lock-scope | public-webdav-api-version | + | old | shared | old | + | old | exclusive | old | + | new | shared | old | + | new | exclusive | old | + | old | shared | new | + | old | exclusive | new | + | new | shared | new | + | new | exclusive | new | + + + Scenario Outline: Uploading a file into a locked subfolder of a public folder + Given user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | | + And the public has uploaded file "test.txt" with content "test" + When the public uploads file "CHILD/test.txt" with content "test" using the public WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/PARENT/CHILD/test.txt" should not exist + But the content of file "/PARENT/test.txt" for user "Alice" should be "test" + Examples: + | public-webdav-api-version | lock-scope | + | new | shared | + | new | exclusive | + + @smokeTest + Scenario Outline: Overwrite a file inside a locked public folder + Given user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When the public uploads file "parent.txt" with content "test" using the public WebDAV API + Then the HTTP status code should be "423" + And the content of file "/PARENT/parent.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | public-webdav-api-version | lock-scope | + | new | shared | + | new | exclusive | + + + Scenario Outline: Overwrite a file inside a locked subfolder of a public folder + Given user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | | + And the public has uploaded file "parent.txt" with content "changed text" + When the public uploads file "CHILD/child.txt" with content "test" using the public WebDAV API + Then the HTTP status code should be "423" + And the content of file "/PARENT/parent.txt" for user "Alice" should be "changed text" + But the content of file "/PARENT/CHILD/child.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | public-webdav-api-version | lock-scope | + | new | shared | + | new | exclusive | + + @smokeTest + Scenario Outline: Public locking is not supported + Given user "Alice" has created a public link share of folder "PARENT" with change permission + When the public locks "/CHILD" in the last public link shared folder using the public WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "405" + And the value of the item "//s:message" in the response should be "Locking not allowed from public endpoint" + Examples: + | public-webdav-api-version | lock-scope | + | old | shared | + | old | exclusive | + + Examples: + | public-webdav-api-version | lock-scope | + | new | shared | + | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks/publicLinkLockdiscovery.feature b/tests/acceptance/features/coreApiWebdavLocks/publicLinkLockdiscovery.feature new file mode 100644 index 00000000000..da02828a22a --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks/publicLinkLockdiscovery.feature @@ -0,0 +1,127 @@ +@api @smokeTest @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-172 @notToImplementOnOCIS +Feature: LOCKDISCOVERY for public links + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + + + Scenario Outline: lockdiscovery root of public link when root is locked + Given user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When the public gets the following properties of entry "/" in the last created public link using the WebDAV API + | propertyName | + | d:lockdiscovery | + Then the HTTP status code should be "200" + And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/$/" + And the item "//d:locktoken/d:href" in the response should not exist + And the value of the item "//d:timeout" in the response should match "/Second-\d+/" + Examples: + | lock-scope | + | shared | + | exclusive | + + + Scenario Outline: lockdiscovery subfolder of a locked public link when root is locked + Given user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When the public gets the following properties of entry "/CHILD" in the last created public link using the WebDAV API + | propertyName | + | d:lockdiscovery | + Then the HTTP status code should be "200" + And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/$/" + And the item "//d:locktoken/d:href" in the response should not exist + And the value of the item "//d:timeout" in the response should match "/Second-\d+/" + Examples: + | lock-scope | + | shared | + | exclusive | + + + Scenario Outline: lockdiscovery subfolder of a public link when subfolder is locked + Given user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | | + When the public gets the following properties of entry "/CHILD" in the last created public link using the WebDAV API + | propertyName | + | d:lockdiscovery | + Then the HTTP status code should be "200" + And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/CHILD$/" + And the item "//d:locktoken/d:href" in the response should not exist + And the value of the item "//d:timeout" in the response should match "/Second-\d+/" + Examples: + | lock-scope | + | shared | + | exclusive | + + + Scenario Outline: lockdiscovery file in a subfolder of a public link when subfolder is locked + Given user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | | + When the public gets the following properties of entry "/CHILD/child.txt" in the last created public link using the WebDAV API + | propertyName | + | d:lockdiscovery | + Then the HTTP status code should be "200" + And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/CHILD$/" + And the item "//d:locktoken/d:href" in the response should not exist + And the value of the item "//d:timeout" in the response should match "/Second-\d+/" + Examples: + | lock-scope | + | shared | + | exclusive | + + + Scenario Outline: lockdiscovery file in a subfolder of a public link when root is locked + Given user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When the public gets the following properties of entry "/CHILD/child.txt" in the last created public link using the WebDAV API + | propertyName | + | d:lockdiscovery | + Then the HTTP status code should be "200" + And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/$/" + And the item "//d:locktoken/d:href" in the response should not exist + And the value of the item "//d:timeout" in the response should match "/Second-\d+/" + Examples: + | lock-scope | + | shared | + | exclusive | + + + Scenario Outline: lockdiscovery file in a subfolder of a public link when the file is locked + Given user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT/CHILD/child.txt" setting the following properties + | lockscope | | + When the public gets the following properties of entry "/CHILD/child.txt" in the last created public link using the WebDAV API + | propertyName | + | d:lockdiscovery | + Then the HTTP status code should be "200" + And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/CHILD\/child.txt$/" + And the item "//d:locktoken/d:href" in the response should not exist + And the value of the item "//d:timeout" in the response should match "/Second-\d+/" + Examples: + | lock-scope | + | shared | + | exclusive | + + + Scenario Outline: lockdiscovery file in a subfolder of a public link when the folder above the public link is locked + Given user "Alice" has created a public link share of folder "PARENT/CHILD" with change permission + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When the public gets the following properties of entry "/child.txt" in the last created public link using the WebDAV API + | propertyName | + | d:lockdiscovery | + Then the HTTP status code should be "200" + And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/$/" + And the item "//d:locktoken/d:href" in the response should not exist + And the value of the item "//d:timeout" in the response should match "/Second-\d+/" + Examples: + | lock-scope | + | shared | + | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature b/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature new file mode 100644 index 00000000000..40f7cd43663 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature @@ -0,0 +1,132 @@ +@api @issue-ocis-reva-172 +Feature: actions on a locked item are possible if the token is sent with the request + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest @notToImplementOnOCIS + Scenario Outline: rename a file in a locked folder + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Alice" moves file "/PARENT/parent.txt" to "/PARENT/renamed-file.txt" sending the locktoken of folder "PARENT" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/parent.txt" should not exist + But as "Alice" file "/PARENT/renamed-file.txt" should exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @smokeTest @notToImplementOnOCIS + Scenario Outline: move a file into a locked folder + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has locked folder "FOLDER" setting the following properties + | lockscope | | + When user "Alice" moves file "/PARENT/parent.txt" to "/FOLDER/moved-file.txt" sending the locktoken of folder "FOLDER" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/parent.txt" should not exist + But as "Alice" file "/FOLDER/moved-file.txt" should exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @smokeTest @notToImplementOnOCIS + Scenario Outline: move a file into a locked folder is impossible when using the wrong token + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has locked folder "FOLDER" setting the following properties + | lockscope | | + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | | + When user "Alice" moves file "/PARENT/parent.txt" to "/FOLDER/moved-file.txt" sending the locktoken of folder "PARENT/CHILD" using the WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/PARENT/parent.txt" should exist + But as "Alice" file "/FOLDER/moved-file.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @skipOnOcV10 @issue-34338 @files_sharing-app-required @notToImplementOnOCIS + Scenario Outline: share receiver cannot rename a file in a folder locked by the owner even when sending the locktoken + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has shared folder "/PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Brian" moves file "Shares/PARENT/parent.txt" to "Shares/PARENT/renamed-file.txt" sending the locktoken of file "PARENT" of user "Alice" using the WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/PARENT/parent.txt" should exist + But as "Alice" file "/PARENT/renamed-file.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @files_sharing-app-required @notToImplementOnOCIS + Scenario Outline: public cannot overwrite a file in a folder locked by the owner even when sending the locktoken + Given user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When the public uploads file "parent.txt" with content "test" sending the locktoken of file "PARENT" of user "Alice" using the public WebDAV API + Then the HTTP status code should be "" + And the content of file "/PARENT/parent.txt" for user "Alice" should be "ownCloud test text file parent" + Examples: + | lock-scope | webdav_api_version | http_status_code | + | shared | old | 423 | + | exclusive | old | 423 | + | shared | new | 423 | + | exclusive | new | 423 | + + @skipOnOcV10 @issue-34360 @files_sharing-app-required + Scenario Outline: two users having both a shared lock can use the resource + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "some data" to "textfile0.txt" + And user "Brian" has uploaded file with content "some data" to "textfile0.txt" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" + And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | shared | + And user "Brian" has locked file "Shares/textfile0.txt" setting the following properties + | lockscope | shared | + When user "Alice" uploads file with content "from user 0" to "textfile0.txt" sending the locktoken of file "textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "textfile0.txt" for user "Alice" should be "from user 0" + And the content of file "Shares/textfile0.txt" for user "Brian" should be "from user 0" + When user "Brian" uploads file with content "from user 1" to "Shares/textfile0.txt" sending the locktoken of file "Shares/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "textfile0.txt" for user "Alice" should be "from user 1" + And the content of file "Shares/textfile0.txt" for user "Brian" should be "from user 1" + Examples: + | dav-path | + | old | + | new | + + @personalSpace + Examples: + | dav-path | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34338.feature b/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34338.feature new file mode 100644 index 00000000000..9118ecf63c4 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34338.feature @@ -0,0 +1,25 @@ +@api @notToImplementOnOCIS @issue-ocis-reva-172 +Feature: actions on a locked item are possible if the token is sent with the request + + @issue-34338 @files_sharing-app-required + Scenario Outline: share receiver cannot rename a file in a folder locked by the owner even when sending the locktoken + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Brian" moves file "PARENT/parent.txt" to "PARENT/renamed-file.txt" sending the locktoken of file "PARENT" of user "Alice" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/PARENT/parent.txt" should not exist + But as "Alice" file "/PARENT/renamed-file.txt" should exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34360.feature b/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34360.feature new file mode 100644 index 00000000000..e9aafe396ff --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34360.feature @@ -0,0 +1,29 @@ +@api @notToImplementOnOCIS @issue-ocis-reva-172 +Feature: actions on a locked item are possible if the token is sent with the request + + @issue-34360 @files_sharing-app-required + Scenario Outline: two users having both a shared lock can use the resource + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And user "Brian" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | shared | + And user "Brian" has locked file "textfile0 (2).txt" setting the following properties + | lockscope | shared | + When user "Alice" uploads file with content "from user 0" to "textfile0.txt" sending the locktoken of file "textfile0.txt" using the WebDAV API + Then the HTTP status code should be "423" + And the content of file "textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + And the content of file "textfile0 (2).txt" for user "Brian" should be "ownCloud test text file 0" + When user "Brian" uploads file with content "from user 1" to "textfile0 (2).txt" sending the locktoken of file "textfile0 (2).txt" using the WebDAV API + Then the HTTP status code should be "423" + And the content of file "textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + And the content of file "textfile0 (2).txt" for user "Brian" should be "ownCloud test text file 0" + Examples: + | dav-path | + | old | + | new | diff --git a/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToRoot.feature b/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToRoot.feature new file mode 100644 index 00000000000..1303b620ef3 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToRoot.feature @@ -0,0 +1,110 @@ +@api @files_sharing-app-required @issue-ocis-reva-172 @issue-ocis-reva-11 @notToImplementOnOCIS +Feature: lock should propagate correctly if a share is reshared + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + And user "Alice" has created folder "PARENT" + And user "Brian" has created folder "PARENT" + And user "Carol" has created folder "PARENT" + + + Scenario Outline: upload to a share that was locked by owner + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has shared folder "PARENT (2)" with user "Carol" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Carol" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API + And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API + And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "423" + And as "Alice" file "/PARENT/textfile.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: upload overwriting to a share that was locked by owner + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Brian" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Carol" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has shared folder "PARENT (2)" with user "Carol" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Carol" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/parent.txt" using the WebDAV API + And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/parent.txt" using the WebDAV API + And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "423" + And the content of file "/PARENT/parent.txt" for user "Alice" should be "ownCloud test text file parent" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: public uploads to a reshared share that was locked by original owner + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has shared folder "PARENT (2)" with user "Carol" + And user "Carol" has created a public link share of folder "PARENT (2)" with change permission + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When the public uploads file "test.txt" with content "test" using the new public WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/PARENT/test.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: upload to a share that was locked by owner but renamed before + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has shared folder "PARENT (2)" with user "Carol" + And user "Brian" has moved folder "/PARENT (2)" to "/PARENT-renamed" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Carol" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API + And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT-renamed/textfile.txt" using the WebDAV API + And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "423" + And as "Alice" file "/PARENT/textfile.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: upload to a share that was locked by the resharing user + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has shared folder "PARENT (2)" with user "Carol" + And user "Brian" has locked folder "PARENT (2)" setting the following properties + | lockscope | | + When user "Carol" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API + And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API + And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "423" + And as "Alice" file "/PARENT/textfile.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToShares.feature b/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToShares.feature new file mode 100644 index 00000000000..32ee430b52d --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToShares.feature @@ -0,0 +1,122 @@ +@api @files_sharing-app-required @issue-ocis-reva-172 @issue-ocis-reva-11 @notToImplementOnOCIS +Feature: lock should propagate correctly if a share is reshared + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + And user "Alice" has created folder "PARENT" + And user "Brian" has created folder "PARENT" + And user "Carol" has created folder "PARENT" + + + Scenario Outline: upload to a share that was locked by owner + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has shared folder "Shares/PARENT" with user "Carol" + And user "Carol" has accepted share "/PARENT" offered by user "Brian" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Carol" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API + And user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API + And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "423" + And as "Alice" file "/PARENT/textfile.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: upload overwriting to a share that was locked by owner + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Brian" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Carol" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has shared folder "Shares/PARENT" with user "Carol" + And user "Carol" has accepted share "/PARENT" offered by user "Brian" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Carol" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/parent.txt" using the WebDAV API + And user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/parent.txt" using the WebDAV API + And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "423" + And the content of file "/PARENT/parent.txt" for user "Alice" should be "ownCloud test text file parent" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: public uploads to a reshared share that was locked by original owner + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has shared folder "Shares/PARENT" with user "Carol" + And user "Carol" has accepted share "/PARENT" offered by user "Brian" + And user "Carol" has created a public link share of folder "Shares/PARENT" with change permission + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When the public uploads file "test.txt" with content "test" using the new public WebDAV API + Then the HTTP status code should be "423" + And as "Alice" file "/PARENT/test.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: upload to a share that was locked by owner but renamed before + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has shared folder "Shares/PARENT" with user "Carol" + And user "Carol" has accepted share "/PARENT" offered by user "Brian" + And user "Brian" has moved folder "/Shares/PARENT" to "/PARENT-renamed" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Carol" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API + And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT-renamed/textfile.txt" using the WebDAV API + And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "423" + And as "Alice" file "/PARENT/textfile.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: upload to a share that was locked by the resharing user + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has shared folder "Shares/PARENT" with user "Carol" + And user "Carol" has accepted share "/PARENT" offered by user "Brian" + And user "Brian" has locked folder "Shares/PARENT" setting the following properties + | lockscope | | + When user "Carol" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API + And user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API + And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API + Then the HTTP status code of responses on all endpoints should be "423" + And as "Alice" file "/PARENT/textfile.txt" should not exist + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks2/setTimeout.feature b/tests/acceptance/features/coreApiWebdavLocks2/setTimeout.feature new file mode 100644 index 00000000000..b0c09f773ad --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks2/setTimeout.feature @@ -0,0 +1,126 @@ +@api @smokeTest @public_link_share-feature-required @issue-ocis-reva-172 @notToImplementOnOCIS +Feature: set timeouts of LOCKS + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + + + Scenario Outline: do not set timeout on folder and check the default timeout + Given using DAV path + And parameter "lock_timeout_default" of app "core" has been set to "" + And parameter "lock_timeout_max" of app "core" has been set to "" + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | exclusive | + Then the HTTP status code should be "200" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" + # consider a drift of up to 9 seconds between setting the lock and retrieving it + Examples: + | dav-path | default-timeout | max-timeout | result | + | old | 120 | 3600 | /Second-(120\|11[1-9])$/ | + | old | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | + | new | 120 | 3600 | /Second-(120\|11[1-9])$/ | + | new | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | default-timeout | max-timeout | result | + | spaces | 120 | 3600 | /Second-(120\|11[1-9])$/ | + | spaces | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | + + + Scenario Outline: set timeout on folder + Given using DAV path + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | shared | + | timeout | | + Then the HTTP status code should be "200" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" + Examples: + | dav-path | timeout | result | + | old | second-999 | /Second-\d{3}$/ | + | old | second-99999999 | /Second-\d{5}$/ | + | old | infinite | /Second-\d{5}$/ | + | old | second--1 | /Second-\d{5}$/ | + | old | second-0 | /Second-\d{4}$/ | + | new | second-999 | /Second-\d{3}$/ | + | new | second-99999999 | /Second-\d{5}$/ | + | new | infinite | /Second-\d{5}$/ | + | new | second--1 | /Second-\d{5}$/ | + | new | second-0 | /Second-\d{4}$/ | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | timeout | result | + | spaces | second-999 | /Second-\d{3}$/ | + | spaces | second-99999999 | /Second-\d{5}$/ | + | spaces | infinite | /Second-\d{5}$/ | + | spaces | second--1 | /Second-\d{5}$/ | + | spaces | second-0 | /Second-\d{4}$/ | + + + Scenario Outline: set timeout over the maximum on folder + Given using DAV path + And parameter "lock_timeout_default" of app "core" has been set to "" + And parameter "lock_timeout_max" of app "core" has been set to "" + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | shared | + | timeout | | + Then the HTTP status code should be "200" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" + Examples: + | dav-path | timeout | default-timeout | max-timeout | result | + | old | second-600 | 120 | 3600 | /Second-(600\|59[1-9])$/ | + | old | second-600 | 99999 | 3600 | /Second-(600\|59[1-9])$/ | + | old | second-10000 | 120 | 3600 | /Second-(3600\|359[1-9])$/ | + | old | second-10000 | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | + | old | infinite | 120 | 3600 | /Second-(3600\|359[1-9])$/ | + | old | infinite | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | + | new | second-600 | 120 | 3600 | /Second-(600\|59[1-9])$/ | + | new | second-600 | 99999 | 3600 | /Second-(600\|59[1-9])$/ | + | new | second-10000 | 120 | 3600 | /Second-(3600\|359[1-9])$/ | + | new | second-10000 | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | + | new | infinite | 120 | 3600 | /Second-(3600\|359[1-9])$/ | + | new | infinite | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | timeout | default-timeout | max-timeout | result | + | spaces | second-600 | 120 | 3600 | /Second-(600\|59[1-9])$/ | + | spaces | second-600 | 99999 | 3600 | /Second-(600\|59[1-9])$/ | + | spaces | second-10000 | 120 | 3600 | /Second-(3600\|359[1-9])$/ | + | spaces | second-10000 | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | + | spaces | infinite | 120 | 3600 | /Second-(3600\|359[1-9])$/ | + | spaces | infinite | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | + + @files_sharing-app-required + Scenario Outline: as owner set timeout on folder as public check it + Given using DAV path + And user "Alice" has created a public link share of folder "PARENT" + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | shared | + | timeout | | + Then the HTTP status code should be "200" + And as a public the lock discovery property "//d:timeout" of the folder "/" should match "" + And as a public the lock discovery property "//d:timeout" of the folder "/CHILD" should match "" + And as a public the lock discovery property "//d:timeout" of the folder "/parent.txt" should match "" + Examples: + | dav-path | timeout | result | + | old | second-999 | /Second-\d{3}$/ | + | old | second-99999999 | /Second-\d{5}$/ | + | old | infinite | /Second-\d{5}$/ | + | old | second--1 | /Second-\d{5}$/ | + | old | second-0 | /Second-\d{4}$/ | + | new | second-999 | /Second-\d{3}$/ | + | new | second-99999999 | /Second-\d{5}$/ | + | new | infinite | /Second-\d{5}$/ | + | new | second--1 | /Second-\d{5}$/ | + | new | second-0 | /Second-\d{4}$/ | diff --git a/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToRoot.feature b/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToRoot.feature new file mode 100644 index 00000000000..81b9602b4a2 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToRoot.feature @@ -0,0 +1,62 @@ +@api @smokeTest @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-172 @notToImplementOnOCIS +Feature: set timeouts of LOCKS on shares + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Brian" has created folder "PARENT" + And user "Brian" has created folder "PARENT/CHILD" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + + + Scenario Outline: as owner set timeout on folder as receiver check it + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | shared | + | timeout | | + Then the HTTP status code should be "200" + And as user "Brian" the lock discovery property "//d:timeout" of the folder "PARENT (2)" should match "" + And as user "Brian" the lock discovery property "//d:timeout" of the folder "PARENT (2)/CHILD" should match "" + And as user "Brian" the lock discovery property "//d:timeout" of the folder "PARENT (2)/parent.txt" should match "" + Examples: + | dav-path | timeout | result | + | old | second-999 | /Second-\d{3}$/ | + | old | second-99999999 | /Second-\d{5}$/ | + | old | infinite | /Second-\d{5}$/ | + | old | second--1 | /Second-\d{5}$/ | + | old | second-0 | /Second-\d{4}$/ | + | new | second-999 | /Second-\d{3}$/ | + | new | second-99999999 | /Second-\d{5}$/ | + | new | infinite | /Second-\d{5}$/ | + | new | second--1 | /Second-\d{5}$/ | + | new | second-0 | /Second-\d{4}$/ | + + + Scenario Outline: as share receiver set timeout on folder as owner check it + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + When user "Brian" locks folder "PARENT (2)" using the WebDAV API setting the following properties + | lockscope | shared | + | timeout | | + Then the HTTP status code should be "200" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" + Examples: + | dav-path | timeout | result | + | old | second-999 | /Second-\d{3}$/ | + | old | second-99999999 | /Second-\d{5}$/ | + | old | infinite | /Second-\d{5}$/ | + | old | second--1 | /Second-\d{5}$/ | + | old | second-0 | /Second-\d{4}$/ | + | new | second-999 | /Second-\d{3}$/ | + | new | second-99999999 | /Second-\d{5}$/ | + | new | infinite | /Second-\d{5}$/ | + | new | second--1 | /Second-\d{5}$/ | + | new | second-0 | /Second-\d{4}$/ | diff --git a/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToShares.feature b/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToShares.feature new file mode 100644 index 00000000000..34ca92e8ee6 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToShares.feature @@ -0,0 +1,66 @@ +@api @smokeTest @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-172 @notToImplementOnOCIS +Feature: set timeouts of LOCKS on shares + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Brian" has created folder "PARENT" + And user "Brian" has created folder "PARENT/CHILD" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + + + Scenario Outline: as owner set timeout on folder as receiver check it + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | shared | + | timeout | | + Then the HTTP status code should be "200" + And as user "Brian" the lock discovery property "//d:timeout" of the folder "Shares/PARENT" should match "" + And as user "Brian" the lock discovery property "//d:timeout" of the folder "Shares/PARENT/CHILD" should match "" + And as user "Brian" the lock discovery property "//d:timeout" of the folder "Shares/PARENT/parent.txt" should match "" + Examples: + | dav-path | timeout | result | + | old | second-999 | /Second-\d{3}$/ | + | old | second-99999999 | /Second-\d{5}$/ | + | old | infinite | /Second-\d{5}$/ | + | old | second--1 | /Second-\d{5}$/ | + | old | second-0 | /Second-\d{4}$/ | + | new | second-999 | /Second-\d{3}$/ | + | new | second-99999999 | /Second-\d{5}$/ | + | new | infinite | /Second-\d{5}$/ | + | new | second--1 | /Second-\d{5}$/ | + | new | second-0 | /Second-\d{4}$/ | + + + Scenario Outline: as share receiver set timeout on folder as owner check it + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" locks folder "Shares/PARENT" using the WebDAV API setting the following properties + | lockscope | shared | + | timeout | | + Then the HTTP status code should be "200" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" + And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" + Examples: + | dav-path | timeout | result | + | old | second-999 | /Second-\d{3}$/ | + | old | second-99999999 | /Second-\d{5}$/ | + | old | infinite | /Second-\d{5}$/ | + | old | second--1 | /Second-\d{5}$/ | + | old | second-0 | /Second-\d{4}$/ | + | new | second-999 | /Second-\d{3}$/ | + | new | second-99999999 | /Second-\d{5}$/ | + | new | infinite | /Second-\d{5}$/ | + | new | second--1 | /Second-\d{5}$/ | + | new | second-0 | /Second-\d{4}$/ | diff --git a/tests/acceptance/features/coreApiWebdavLocks3/independentLocks.feature b/tests/acceptance/features/coreApiWebdavLocks3/independentLocks.feature new file mode 100644 index 00000000000..5766a1592c5 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks3/independentLocks.feature @@ -0,0 +1,108 @@ +@api @issue-ocis-reva-172 +Feature: independent locks + Make sure all locks are independent and don't interact with other items that have the same name + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @notToImplementOnOCIS + Scenario Outline: locking a folder does not lock other items with the same name in other parts of the file system + Given using DAV path + And user "Alice" has created folder "locked" + And user "Alice" has created folder "locked/PARENT" + And user "Alice" has created folder "notlocked" + And user "Alice" has created folder "notlocked/PARENT" + And user "Alice" has created folder "alsonotlocked" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/alsonotlocked/PARENT" + When user "Alice" locks folder "locked/PARENT" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/PARENT/file.txt" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/alsonotlocked/PARENT" + But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/PARENT/textfile0.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @notToImplementOnOCIS + Scenario Outline: locking a folder on the root level does not lock other folders with the same name in other parts of the file system + Given using DAV path + And user "Alice" has created folder "notlocked" + And user "Alice" has created folder "notlocked/PARENT" + And user "Alice" has created folder "alsonotlocked" + And user "Alice" has created folder "alsonotlocked/PARENT" + When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "201" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/PARENT/file.txt" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/alsonotlocked/PARENT/file.txt" + But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/PARENT/textfile0.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: locking a file does not lock other items with the same name in other parts of the file system + Given using DAV path + And user "Alice" has created folder "locked" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/locked/textfile0.txt" + And user "Alice" has created folder "notlocked" + And user "Alice" has created folder "notlocked/textfile0.txt" + When user "Alice" locks file "locked/textfile0.txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/textfile0.txt/real-file.txt" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/textfile0.txt" + But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/textfile0.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | + + + Scenario Outline: locking a file/folder with git specific names does not lock other items with the same name in other parts of the file system + Given using DAV path + And user "Alice" has created folder "locked/" + And user "Alice" has created folder "locked/" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/locked//" + And user "Alice" has created folder "notlocked/" + And user "Alice" has created folder "notlocked/" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "notlocked//" + When user "Alice" locks file "locked/" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked//file.txt" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked//" + But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked//" + Examples: + | dav-path | lock-scope | foldername | filename | to-lock | + | old | shared | .git | config | .git | + | old | shared | .git | config | .git/config | + | old | exclusive | .git | config | .git | + | old | exclusive | .git | config | .git/config | + | new | shared | .git | config | .git | + | new | shared | .git | config | .git/config | + | new | exclusive | .git | config | .git | + | new | exclusive | .git | config | .git/config | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | foldername | filename | to-lock | + | spaces | shared | .git | config | .git | + | spaces | shared | .git | config | .git/config | + | spaces | exclusive | .git | config | .git | + | spaces | exclusive | .git | config | .git/config | diff --git a/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToRoot.feature b/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToRoot.feature new file mode 100644 index 00000000000..4e492f6a30b --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToRoot.feature @@ -0,0 +1,91 @@ +@api @issue-ocis-reva-172 @notToImplementOnOCIS +Feature: independent locks + Make sure all locks are independent and don't interact with other items that have the same name + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Brian" has been created with default attributes and without skeleton files + + + Scenario Outline: locking a received share does not lock other shares that had the same name on the sharer side (shares from different users) + Given using DAV path + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "toShare" + And user "Brian" has created folder "toShare" + And user "Alice" has shared folder "toShare" with user "Carol" + And user "Brian" has shared folder "toShare" with user "Carol" + When user "Carol" locks folder "/toShare" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/lorem.txt" to "/toShare (2)/file.txt" + But user "Carol" should not be able to upload file "filesForUpload/lorem.txt" to "/toShare/file.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: locking a received share does not lock other shares that had the same name on the sharer side (shares from the same user) + Given using DAV path + And user "Alice" has created folder "locked/" + And user "Alice" has created folder "locked/toShare" + And user "Alice" has created folder "notlocked/" + And user "Alice" has created folder "notlocked/toShare" + And user "Alice" has shared folder "locked/toShare" with user "Brian" + And user "Alice" has shared folder "notlocked/toShare" with user "Brian" + When user "Brian" locks folder "/toShare" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Brian" should be able to upload file "filesForUpload/lorem.txt" to "/toShare (2)/file.txt" + But user "Brian" should not be able to upload file "filesForUpload/lorem.txt" to "/toShare/file.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: locking a file in a received share does not lock other items with the same name in other received shares (shares from different users) + Given using DAV path + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FromAlice" + And user "Brian" has created folder "FromBrian" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/FromAlice/textfile0.txt" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/FromBrian/textfile0.txt" + And user "Alice" has shared folder "FromAlice" with user "Carol" + And user "Brian" has shared folder "FromBrian" with user "Carol" + When user "Carol" locks file "/FromBrian/textfile0.txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/lorem.txt" to "/FromAlice/textfile0.txt" + But user "Carol" should not be able to upload file "filesForUpload/lorem.txt" to "/FromBrian/textfile0.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: locking a file in a received share does not lock other items with the same name in other received shares (shares from same user) + Given using DAV path + And user "Alice" has created folder "locked/" + And user "Alice" has created folder "notlocked/" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "locked/textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "notlocked/textfile0.txt" + And user "Alice" has shared folder "locked" with user "Brian" + And user "Alice" has shared folder "notlocked" with user "Brian" + When user "Brian" locks file "/locked/textfile0.txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Brian" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/textfile0.txt" + But user "Brian" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/textfile0.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToShares.feature b/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToShares.feature new file mode 100644 index 00000000000..bff1b5077c1 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToShares.feature @@ -0,0 +1,113 @@ +@api @issue-ocis-reva-172 +Feature: independent locks + Make sure all locks are independent and don't interact with other items that have the same name + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And user "Brian" has been created with default attributes and without skeleton files + + @notToImplementOnOCIS + Scenario Outline: locking a received share does not lock other shares that had the same name on the sharer side (shares from different users) + Given using DAV path + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "toShare" + And user "Brian" has created folder "toShare" + And user "Alice" has shared folder "toShare" with user "Carol" + And user "Brian" has shared folder "toShare" with user "Carol" + And user "Carol" has accepted share "/toShare" offered by user "Alice" + And user "Carol" has accepted share "/toShare" offered by user "Brian" + When user "Carol" locks folder "/Shares/toShare" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/lorem.txt" to "/Shares/toShare (2)/file.txt" + But user "Carol" should not be able to upload file "filesForUpload/lorem.txt" to "/Shares/toShare/file.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @notToImplementOnOCIS + Scenario Outline: locking a received share does not lock other shares that had the same name on the sharer side (shares from the same user) + Given using DAV path + And user "Alice" has created folder "locked/" + And user "Alice" has created folder "locked/toShare" + And user "Alice" has created folder "notlocked/" + And user "Alice" has created folder "notlocked/toShare" + And user "Alice" has shared folder "locked/toShare" with user "Brian" + And user "Alice" has shared folder "notlocked/toShare" with user "Brian" + And user "Brian" has accepted the first pending share "/toShare" offered by user "Alice" + And user "Brian" has accepted the next pending share "/toShare" offered by user "Alice" + When user "Brian" locks folder "/Shares/toShare" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Brian" should be able to upload file "filesForUpload/lorem.txt" to "/Shares/toShare (2)/file.txt" + But user "Brian" should not be able to upload file "filesForUpload/lorem.txt" to "/Shares/toShare/file.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: locking a file in a received share does not lock other items with the same name in other received shares (shares from different users) + Given using DAV path + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FromAlice" + And user "Brian" has created folder "FromBrian" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/FromAlice/textfile0.txt" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/FromBrian/textfile0.txt" + And user "Alice" has shared folder "FromAlice" with user "Carol" + And user "Brian" has shared folder "FromBrian" with user "Carol" + And user "Carol" has accepted share "/FromAlice" offered by user "Alice" + And user "Carol" has accepted share "/FromBrian" offered by user "Brian" + When user "Carol" locks file "/Shares/FromBrian/textfile0.txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Carol" should be able to upload file "filesForUpload/lorem.txt" to "/Shares/FromAlice/textfile0.txt" + But user "Carol" should not be able to upload file "filesForUpload/lorem.txt" to "/Shares/FromBrian/textfile0.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | + + + Scenario Outline: locking a file in a received share does not lock other items with the same name in other received shares (shares from same user) + Given using DAV path + And user "Alice" has created folder "locked/" + And user "Alice" has created folder "notlocked/" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/locked/textfile0.txt" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/notlocked/textfile0.txt" + And user "Alice" has shared folder "locked" with user "Brian" + And user "Alice" has shared folder "notlocked" with user "Brian" + And user "Brian" has accepted share "/locked" offered by user "Alice" + And user "Brian" has accepted share "/notlocked" offered by user "Alice" + When user "Brian" locks file "/Shares/locked/textfile0.txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And user "Brian" should be able to upload file "filesForUpload/lorem.txt" to "/Shares/notlocked/textfile0.txt" + But user "Brian" should not be able to upload file "filesForUpload/lorem.txt" to "/Shares/locked/textfile0.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/lockBreakersGroups.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/lockBreakersGroups.feature new file mode 100644 index 00000000000..19d23ab32a6 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocksUnlock/lockBreakersGroups.feature @@ -0,0 +1,310 @@ +@api @issue-ocis-2413 @notToImplementOnOCIS +Feature: UNLOCK locked items + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: a group can be added as a lock breaker group + Given using DAV path + And group "grp1" has been created + When the administrator sets parameter "lock-breaker-groups" of app "core" to '["grp1"]' + Then the HTTP status code should be "200" + And group "grp1" should exist as a lock breaker group + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: more than one group can be added as a lock breaker group + Given using DAV path + And group "grp1" has been created + And group "grp2" has been created + When the administrator sets parameter "lock-breaker-groups" of app "core" to '["grp1","grp2"]' + Then the HTTP status code should be "200" + And following groups should exist as lock breaker groups + | groups | + | grp1 | + | grp2 | + Examples: + | dav-path | + | old | + | new | + + + Scenario Outline: member of the lock breakers group can unlock a locked folder shared with them + Given using DAV path + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' + And user "Brian" has been added to group "grp1" + And user "Alice" has locked folder "FOLDER" setting the following properties + | lockscope | | + And user "Alice" has shared folder "FOLDER" with user "Brian" + When user "Brian" unlocks folder "FOLDER" with the last created lock of folder "FOLDER" of user "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for folder "FOLDER" of user "Brian" by the WebDAV API + And 0 locks should be reported for folder "FOLDER" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: members of the lock breakers group can lock shared folder that was unlocked by the lock breaker group before + Given using DAV path + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' + And user "Brian" has been added to group "grp1" + And user "Alice" has locked folder "FOLDER" setting the following properties + | lockscope | | + And user "Alice" has shared folder "FOLDER" with user "Brian" + And user "Brian" has unlocked folder "FOLDER" with the last created lock of folder "FOLDER" of user "Alice" using the WebDAV API + When user "Brian" locks folder "FOLDER" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And 1 locks should be reported for folder "FOLDER" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: members of the lock breakers group can unlock a locked file shared with them + Given using DAV path + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' + And user "Brian" has been added to group "grp1" + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | | + And user "Alice" has shared file "textfile0.txt" with user "Brian" + When user "Brian" unlocks file "textfile0.txt" with the last created lock of file "textfile0.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for file "textfile0.txt" of user "Brian" by the WebDAV API + And 0 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: members of the lock breakers group can lock shared file that was unlocked by the lock breaker group before + Given using DAV path + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' + And user "Brian" has been added to group "grp1" + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | | + And user "Alice" has shared file "textfile0.txt" with user "Brian" + And user "Brian" has unlocked file "textfile0.txt" with the last created lock of folder "textfile0.txt" of user "Alice" using the WebDAV API + When user "Brian" locks file "textfile0.txt" using the WebDAV API setting the following properties + | lockscope | | + Then the HTTP status code should be "200" + And 1 locks should be reported for file "textfile0.txt" of user "Brian" by the WebDAV API + And 1 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: as a member of lock breaker group unlocking a file in a share locked by the file owner is possible + Given using DAV path + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has locked file "PARENT/parent.txt" setting the following properties + | lockscope | | + And user "Alice" has shared folder "PARENT" with user "Brian" + When user "Brian" unlocks file "PARENT/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 0 locks should be reported for file "PARENT/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: as a member of lock breaker group unlocking a folder in a share locked by the folder owner is possible + Given using DAV path + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "CHILD" + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | | + And user "Alice" has shared folder "PARENT" with user "Brian" + When user "Brian" unlocks folder "PARENT/CHILD" with the last created lock of folder "PARENT/CHILD" of user "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API + And 0 locks should be reported for folder "PARENT/CHILD" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: members of different lock breaker groups can lock and unlock same folder shared to them + Given using DAV path + And group "grp1" has been created + And group "grp2" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1","grp2"]' + And user "Carol" has been added to group "grp2" + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "PARENT" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Alice" has shared folder "PARENT" with user "Carol" + When user "Brian" unlocks folder "PARENT" with the last created lock of file "PARENT" of user "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 0 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API + And 0 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API + When user "Brian" locks folder "PARENT" using the WebDAV API setting the following properties + | lockscope | | + And 1 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 1 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API + And 1 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API + Then the HTTP status code should be "200" + When user "Carol" unlocks folder "PARENT" with the last created lock of folder "PARENT" of user "Brian" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 0 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API + And 0 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: members of different lock breaker groups can lock and unlock same file shared to them + Given using DAV path + And group "grp1" has been created + And group "grp2" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1","grp2"]' + And user "Carol" has been added to group "grp2" + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has locked file "textfile.txt" setting the following properties + | lockscope | | + And user "Alice" has shared file "textfile.txt" with user "Brian" + And user "Alice" has shared file "textfile.txt" with user "Carol" + When user "Brian" unlocks file "textfile.txt" with the last created lock of file "textfile.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for file "textfile.txt" of user "Alice" by the WebDAV API + And 0 locks should be reported for file "textfile.txt" of user "Brian" by the WebDAV API + And 0 locks should be reported for file "textfile.txt" of user "Carol" by the WebDAV API + When user "Brian" locks file "textfile.txt" using the WebDAV API setting the following properties + | lockscope | | + And 1 locks should be reported for file "textfile.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "textfile.txt" of user "Brian" by the WebDAV API + And 1 locks should be reported for file "textfile.txt" of user "Carol" by the WebDAV API + Then the HTTP status code should be "200" + When user "Carol" unlocks file "textfile.txt" with the last created lock of file "textfile.txt" of user "Brian" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for file "textfile.txt" of user "Alice" by the WebDAV API + And 0 locks should be reported for file "textfile.txt" of user "Brian" by the WebDAV API + And 0 locks should be reported for file "textfile.txt" of user "Carol" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: members of lock breaker group can unlock a folder in group sharing + Given using DAV path + And group "grp1" has been created + And group "grp2" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' + And user "Carol" has been added to group "grp2" + And user "Brian" has been added to group "grp1" + And user "Brian" has been added to group "grp2" + And user "Alice" has created folder "PARENT" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + And user "Alice" has shared folder "PARENT" with group "grp2" + When user "Carol" unlocks folder "PARENT" with the last created lock of folder "PARENT" of user "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 1 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API + And 1 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API + When user "Brian" unlocks folder "PARENT" with the last created lock of file "PARENT" of user "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 0 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API + And 0 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: members of lock breaker group can unlock a file in group sharing + Given using DAV path + And group "grp1" has been created + And group "grp2" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' + And user "Carol" has been added to group "grp2" + And user "Brian" has been added to group "grp1" + And user "Brian" has been added to group "grp2" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | | + And user "Alice" has shared file "textfile0.txt" with group "grp2" + When user "Carol" unlocks file "textfile0.txt" with the last created lock of file "textfile0.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "textfile0.txt" of user "Brian" by the WebDAV API + And 1 locks should be reported for file "textfile0.txt" of user "Carol" by the WebDAV API + When user "Brian" unlocks file "textfile0.txt" with the last created lock of file "textfile0.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API + And 0 locks should be reported for file "textfile0.txt" of user "Brian" by the WebDAV API + And 0 locks should be reported for file "textfile0.txt" of user "Carol" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature new file mode 100644 index 00000000000..61a65a40f62 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature @@ -0,0 +1,138 @@ +@api @issue-ocis-reva-172 +Feature: UNLOCK locked items + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @smokeTest @notToImplementOnOCIS + Scenario Outline: unlock a single lock set by the user itself + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Alice" unlocks the last created lock of folder "PARENT" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 0 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API + And 0 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: unlock one of multiple locks set by the user itself + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | shared | + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | shared | + When user "Alice" unlocks the last created lock of file "textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And 1 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API + Examples: + | dav-path | + | old | + | new | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | + | spaces | + + @notToImplementOnOCIS + Scenario Outline: unlocking a file that was locked by the user locking the folder above is not possible + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has locked folder "PARENT/CHILD" setting the following properties + | lockscope | | + When user "Alice" unlocks file "PARENT/CHILD/child.txt" with the last created lock of folder "PARENT/CHILD" using the WebDAV API + Then the HTTP status code should be "204" + And 1 locks should be reported for file "PARENT/CHILD/child.txt" of user "Alice" by the WebDAV API + And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @skipOnOcV10 @issue-34302 @files_sharing-app-required + Scenario Outline: as public unlocking a file in a share that was locked by the file owner is not possible. To unlock use the owners locktoken + Given user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked file "PARENT/parent.txt" setting the following properties + | lockscope | | + When the public unlocks file "/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + Examples: + | lock-scope | + | shared | + | exclusive | + + @notToImplementOnOCIS + Scenario Outline: unlocking a file or folder does not unlock another folder with the same name in another part of the file system + Given using DAV path + And user "Alice" has created folder "locked" + And user "Alice" has created folder "locked/PARENT" + And user "Alice" has created folder "notlocked" + And user "Alice" has created folder "notlocked/PARENT" + And user "Alice" has created folder "alsonotlocked" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/alsonotlocked/PARENT" + And user "Alice" has locked folder "locked/PARENT" setting the following properties + | lockscope | | + And user "Alice" has locked folder "notlocked/PARENT" setting the following properties + | lockscope | | + And user "Alice" has locked file "alsonotlocked/PARENT" setting the following properties + | lockscope | | + When user "Alice" unlocks the last created lock of folder "notlocked/PARENT" using the WebDAV API + And user "Alice" unlocks the last created lock of file "alsonotlocked/PARENT" using the WebDAV API + Then user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/PARENT/file.txt" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/alsonotlocked/PARENT" + But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/PARENT/textfile0.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: unlocking a file or folder does not unlock another file with the same name in another part of the file system + Given using DAV path + And user "Alice" has created folder "locked" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/locked/textfile0.txt" + And user "Alice" has created folder "notlocked" + And user "Alice" has created folder "notlocked/textfile0.txt" + And user "Alice" has locked file "locked/textfile0.txt" setting the following properties + | lockscope | | + And user "Alice" has locked file "notlocked/textfile0.txt" setting the following properties + | lockscope | | + And user "Alice" has locked file "textfile0.txt" setting the following properties + | lockscope | | + When user "Alice" unlocks the last created lock of file "notlocked/textfile0.txt" using the WebDAV API + And user "Alice" unlocks the last created lock of file "textfile0.txt" using the WebDAV API + Then user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/textfile0.txt/real-file.txt" + And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/textfile0.txt" + But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/textfile0.txt" + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockOc10Issue34302.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockOc10Issue34302.feature new file mode 100644 index 00000000000..957aa584772 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockOc10Issue34302.feature @@ -0,0 +1,19 @@ +@api @notToImplementOnOCIS @issue-ocis-reva-172 +Feature: UNLOCK locked items + + @issue-34302 @files_sharing-app-required + Scenario Outline: as public unlocking a file in a share that was locked by the file owner is not possible. To unlock use the owners locktoken + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has created a public link share of folder "PARENT" with change permission + And user "Alice" has locked file "PARENT/parent.txt" setting the following properties + | lockscope | | + When the public unlocks file "/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "405" + #Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + Examples: + | lock-scope | + | shared | + | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToRoot.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToRoot.feature new file mode 100644 index 00000000000..f12440d25fc --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToRoot.feature @@ -0,0 +1,143 @@ +@api @issue-ocis-reva-172 @files_sharing-app-required @notToImplementOnOCIS +Feature: UNLOCK locked items (sharing) + + Background: + Given these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + + + Scenario Outline: as share receiver unlocking a shared file locked by the file owner is not possible. To unlock use the owners locktoken + Given using DAV path + And user "Alice" has locked file "PARENT/parent.txt" setting the following properties + | lockscope | | + And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" + When user "Brian" unlocks file "parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: as share receiver unlocking a file in a share locked by the file owner is not possible. To unlock use the owners locktoken + Given using DAV path + And user "Brian" has created folder "PARENT" + And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + And user "Alice" has locked file "PARENT/parent.txt" setting the following properties + | lockscope | | + And user "Alice" has shared folder "PARENT" with user "Brian" + When user "Brian" unlocks file "PARENT (2)/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "PARENT (2)/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: as share receiver unlocking a shared folder locked by the file owner is not possible. To unlock use the owners locktoken + Given using DAV path + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + And user "Alice" has shared folder "PARENT" with user "Brian" + When user "Brian" unlocks folder "PARENT" with the last created lock of folder "PARENT" of user "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And 3 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 3 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API + And 2 locks should be reported for folder "PARENT/CHILD" of user "Brian" by the WebDAV API + And 1 locks should be reported for file "PARENT/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: as share receiver unlock a shared file + Given using DAV path + And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" + And user "Brian" has locked file "parent.txt" setting the following properties + | lockscope | | + When user "Brian" unlocks the last created lock of file "parent.txt" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 0 locks should be reported for file "parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: as owner unlocking a shared file locked by the receiver is not possible. To unlock use the receivers locktoken + Given using DAV path + And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" + And user "Brian" has locked file "parent.txt" setting the following properties + | lockscope | | + When user "Alice" unlocks file "PARENT/parent.txt" with the last created lock of file "parent.txt" of user "Brian" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: as owner unlocking a file in a share that was locked by the share receiver is not possible. To unlock use the receivers locktoken + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has locked file "PARENT/parent.txt" setting the following properties + | lockscope | | + When user "Alice" unlocks file "PARENT/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Brian" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "PARENT/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: as owner unlocking a shared folder locked by the share receiver is not possible. To unlock use the receivers locktoken + Given using DAV path + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has locked folder "PARENT" setting the following properties + | lockscope | | + When user "Alice" unlocks folder "PARENT" with the last created lock of folder "PARENT" of user "Brian" using the WebDAV API + Then the HTTP status code should be "403" + And 3 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 3 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API + And 2 locks should be reported for folder "PARENT/CHILD" of user "Brian" by the WebDAV API + And 1 locks should be reported for file "PARENT/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature new file mode 100644 index 00000000000..97d4507278d --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature @@ -0,0 +1,180 @@ +@api @issue-ocis-reva-172 @files_sharing-app-required +Feature: UNLOCK locked items (sharing) + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" + + + Scenario Outline: as share receiver unlocking a shared file locked by the file owner is not possible. To unlock use the owners locktoken + Given using DAV path + And user "Alice" has locked file "PARENT/parent.txt" setting the following properties + | lockscope | | + And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" + And user "Brian" has accepted share "" offered by user "Alice" + When user "Brian" unlocks file "Shares/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "Shares/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | pending_share_path | + | old | shared | /parent.txt | + | old | exclusive | /parent.txt | + | new | shared | /parent.txt | + | new | exclusive | /parent.txt | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | pending_share_path | + | spaces | shared | /parent.txt | + | spaces | exclusive | /parent.txt | + + + Scenario Outline: as share receiver unlocking a file in a share locked by the file owner is not possible. To unlock use the owners locktoken + Given using DAV path + And user "Alice" has locked file "PARENT/parent.txt" setting the following properties + | lockscope | | + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" unlocks file "Shares/PARENT/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "Shares/PARENT/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | + + @notToImplementOnOCIS + Scenario Outline: as share receiver unlocking a shared folder locked by the file owner is not possible. To unlock use the owners locktoken + Given using DAV path + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has locked folder "PARENT" setting the following properties + | lockscope | | + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + When user "Brian" unlocks folder "Shares/PARENT" with the last created lock of folder "PARENT" of user "Alice" using the WebDAV API + Then the HTTP status code should be "403" + And 3 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 3 locks should be reported for folder "Shares/PARENT" of user "Brian" by the WebDAV API + And 2 locks should be reported for folder "Shares/PARENT/CHILD" of user "Brian" by the WebDAV API + And 1 locks should be reported for file "Shares/PARENT/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + + Scenario Outline: as share receiver unlock a shared file + Given using DAV path + And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" + And user "Brian" has accepted share "" offered by user "Alice" + And user "Brian" has locked file "Shares/parent.txt" setting the following properties + | lockscope | | + When user "Brian" unlocks the last created lock of file "Shares/parent.txt" using the WebDAV API + Then the HTTP status code should be "204" + And 0 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 0 locks should be reported for file "Shares/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | pending_share_path | + | old | shared | /parent.txt | + | old | exclusive | /parent.txt | + | new | shared | /parent.txt | + | new | exclusive | /parent.txt | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | pending_share_path | + | spaces | shared | /parent.txt | + | spaces | exclusive | /parent.txt | + + + Scenario Outline: as owner unlocking a shared file locked by the receiver is not possible. To unlock use the receivers locktoken + Given using DAV path + And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" + And user "Brian" has accepted share "" offered by user "Alice" + And user "Brian" has locked file "Shares/parent.txt" setting the following properties + | lockscope | | + When user "Alice" unlocks file "PARENT/parent.txt" with the last created lock of file "Shares/parent.txt" of user "Brian" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "Shares/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | pending_share_path | + | old | shared | /parent.txt | + | old | exclusive | /parent.txt | + | new | shared | /parent.txt | + | new | exclusive | /parent.txt | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | pending_share_path | + | spaces | shared | /parent.txt | + | spaces | exclusive | /parent.txt | + + + Scenario Outline: as owner unlocking a file in a share that was locked by the share receiver is not possible. To unlock use the receivers locktoken + Given using DAV path + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has locked file "Shares/PARENT/parent.txt" setting the following properties + | lockscope | | + When user "Alice" unlocks file "PARENT/parent.txt" with the last created lock of file "Shares/PARENT/parent.txt" of user "Brian" using the WebDAV API + Then the HTTP status code should be "403" + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "Shares/PARENT/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | + + @personalSpace @skipOnOcV10 + Examples: + | dav-path | lock-scope | + | spaces | shared | + | spaces | exclusive | + + @notToImplementOnOCIS + Scenario Outline: as owner unlocking a shared folder locked by the share receiver is not possible. To unlock use the receivers locktoken + Given using DAV path + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" + And user "Alice" has shared folder "PARENT" with user "Brian" + And user "Brian" has accepted share "/PARENT" offered by user "Alice" + And user "Brian" has locked folder "Shares/PARENT" setting the following properties + | lockscope | | + When user "Alice" unlocks folder "PARENT" with the last created lock of folder "Shares/PARENT" of user "Brian" using the WebDAV API + Then the HTTP status code should be "403" + And 3 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API + And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API + And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API + And 3 locks should be reported for folder "Shares/PARENT" of user "Brian" by the WebDAV API + And 2 locks should be reported for folder "Shares/PARENT/CHILD" of user "Brian" by the WebDAV API + And 1 locks should be reported for file "Shares/PARENT/parent.txt" of user "Brian" by the WebDAV API + Examples: + | dav-path | lock-scope | + | old | shared | + | old | exclusive | + | new | shared | + | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFileAsync.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFileAsync.feature new file mode 100644 index 00000000000..fa35764eafb --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove1/moveFileAsync.feature @@ -0,0 +1,278 @@ +@api @issue-ocis-reva-14 @notToImplementOnOCIS +Feature: move (rename) file + As a user + I want to be able to move and rename files asynchronously + So that I can manage my file system + + Background: + Given using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And the administrator has enabled async operations + + + Scenario Outline: Moving a file + Given user "Alice" has created folder "FOLDER" + When user "Alice" moves file "/textfile0.txt" asynchronously to "/FOLDER/" using the WebDAV API + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + | ETag | /^"[0-9a-f]{1,32}"$/ | + And the content of file "/FOLDER/" for user "Alice" should be "ownCloud test text file 0" + And user "Alice" should not see the following elements + | /textfile0.txt | + Examples: + | destination-file-name | + | नेपाली.txt | + | strängé file.txt | + | C++ file.cpp | + | file #2.txt | + | file ?2.txt | + | sample,1.txt | + + + Scenario: Moving and overwriting a file + Given user "Alice" has uploaded file with content "Welcome to move" to "/fileToMove.txt" + When user "Alice" moves file "/fileToMove.txt" asynchronously to "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + | ETag | /^"[0-9a-f]{1,32}"$/ | + And the content of file "/textfile0.txt" for user "Alice" should be "Welcome to move" + And user "Alice" should not see the following elements + | /fileToMove.txt | + + + Scenario: Moving (renaming) a file to be only different case + When user "Alice" moves file "/textfile0.txt" asynchronously to "/TextFile0.txt" using the WebDAV API + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + | ETag | /^"[0-9a-f]{1,32}"$/ | + And the content of file "/TextFile0.txt" for user "Alice" should be "ownCloud test text file 0" + And user "Alice" should not see the following elements + | /textfile0.txt | + + + Scenario: Moving (renaming) a file to a file with only different case to an existing file + Given user "Alice" has uploaded file with content "ownCloud test text file 1" to "textfile1.txt" + When user "Alice" moves file "/textfile1.txt" asynchronously to "/TextFile0.txt" using the WebDAV API + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + | ETag | /^"[0-9a-f]{1,32}"$/ | + And the content of file "/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + And the content of file "/TextFile0.txt" for user "Alice" should be "ownCloud test text file 1" + And user "Alice" should not see the following elements + | /textfile1.txt | + + + Scenario: Moving (renaming) a file to a file in a folder with only different case to an existing file + Given user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + When user "Alice" moves file "/textfile0.txt" asynchronously to "/PARENT/Parent.txt" using the WebDAV API + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + | ETag | /^"[0-9a-f]{1,32}"$/ | + And the content of file "/PARENT/parent.txt" for user "Alice" should be "ownCloud test text file parent" + And the content of file "/PARENT/Parent.txt" for user "Alice" should be "ownCloud test text file 0" + And user "Alice" should not see the following elements + | /textfile0.txt | + + @files_sharing-app-required + Scenario: Moving a file to a folder with no permissions + Given user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | read | + | shareWith | Alice | + When user "Alice" moves file "/textfile0.txt" asynchronously to "/testshare/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "202" + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^error$/ | + | errorCode | /^403$/ | + And user "Alice" downloads file "/testshare/textfile0.txt" using the WebDAV API + And the HTTP status code should be "404" + And user "Alice" should see the following elements + | /textfile0.txt | + + @files_sharing-app-required + Scenario: Moving a file to overwrite a file in a folder with no permissions + Given user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "Welcome to overwrite" to "/fileToCopy.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | read | + | shareWith | Alice | + And user "Brian" has copied file "/fileToCopy.txt" to "/testshare/overwritethis.txt" + When user "Alice" moves file "/textfile0.txt" asynchronously to "/testshare/overwritethis.txt" using the WebDAV API + Then the HTTP status code should be "202" + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^error$/ | + | errorCode | /^403$/ | + And the content of file "/testshare/overwritethis.txt" for user "Alice" should be "Welcome to overwrite" + And user "Alice" should see the following elements + | /textfile0.txt | + + + Scenario: move file into a not-existing folder + When user "Alice" moves file "/textfile0.txt" asynchronously to "/not-existing/not-existing-file.txt" using the WebDAV API + Then the HTTP status code should be "202" + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^error$/ | + | errorCode | /^409$/ | + | errorMessage | /^The destination node is not found$/ | + And user "Alice" should see the following elements + | /textfile0.txt | + + + Scenario: rename a file into an invalid filename + When user "Alice" moves file "/textfile0.txt" asynchronously to "/a\\a" using the WebDAV API + Then the HTTP status code should be "400" + And user "Alice" should see the following elements + | /textfile0.txt | + + + Scenario: Renaming a file to a path with extension .part should not be possible + When user "Alice" moves file "/textfile0.txt" asynchronously to "/textfile0.part" using the WebDAV API + Then the HTTP status code should be "400" + And user "Alice" should see the following elements + | /textfile0.txt | + But user "Alice" should not see the following elements + | /textfile0.part | + + + Scenario: Checking file id after a move + Given user "Alice" has stored id of file "/textfile0.txt" + And user "Alice" has created folder "FOLDER" + When user "Alice" moves file "/textfile0.txt" asynchronously to "/FOLDER/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "202" + And user "Alice" file "/FOLDER/textfile0.txt" should have the previously stored id + And user "Alice" should not see the following elements + | /textfile0.txt | + + + Scenario: disabled async operations leads to original behavior + Given the administrator has disabled async operations + And user "Alice" has created folder "FOLDER" + When user "Alice" moves file "/textfile0.txt" asynchronously to "/FOLDER/fileToMove.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the following headers should not be set + | header | + | OC-JobStatus-Location | + And the content of file "/FOLDER/fileToMove.txt" for user "Alice" should be "ownCloud test text file 0" + + + Scenario Outline: enabling async operations does no difference to normal MOVE - Moving a file + Given the administrator has enabled async operations + And user "Alice" has created folder "FOLDER" + And using DAV path + When user "Alice" moves file "/textfile0.txt" to "/FOLDER/fileToMove.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/fileToMove.txt" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: enabling async operations does no difference to normal MOVE - Moving and overwriting a file + Given the administrator has enabled async operations + And user "Alice" has uploaded file with content "Welcome to ownCloud" to "/fileToMove.txt" + And using DAV path + When user "Alice" moves file "/fileToMove.txt" to "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textfile0.txt" for user "Alice" should be "Welcome to ownCloud" + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required + Scenario Outline: enabling async operations does no difference to normal MOVE - Moving a file to a folder with no permissions + Given the administrator has enabled async operations + And using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | read | + | shareWith | Alice | + When user "Alice" moves file "/textfile0.txt" to "/testshare/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should not be able to download file "/testshare/textfile0.txt" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: enabling async operations does no difference to normal MOVE - move file into a not-existing folder + Given the administrator has enabled async operations + And using DAV path + When user "Alice" moves file "/textfile0.txt" to "/not-existing/fileToMove.txt" using the WebDAV API + Then the HTTP status code should be "409" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: enabling async operations does no difference to normal MOVE - rename a file into an invalid filename + Given the administrator has enabled async operations + And using DAV path + When user "Alice" moves file "/textfile0.txt" to "/a\\a" using the WebDAV API + Then the HTTP status code should be "400" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: enabling async operations does no difference to normal MOVE - rename a file into a banned filename + Given the administrator has enabled async operations + And using DAV path + When user "Alice" moves file "/textfile0.txt" to "/.htaccess" using the WebDAV API + Then the HTTP status code should be "403" + Examples: + | dav_version | + | old | + | new | + + #this does not work if firewall app is enabled + #and it also does not work with the php-dev server + @skipOnFirewall + Scenario: Moving and overwriting a file with lazyops + #need to slowdown the request for longer than the timeout + #when doing LazyOps the server does not close the connection + #so we timeout the request and check the job-status + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToMove.txt" + And the HTTP-Request-timeout is set to 5 seconds + And the MOVE DAV requests are slowed down by 10 seconds + When user "Alice" moves file "/fileToMove.txt" asynchronously to "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^started$/ | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFileToBlacklistedNameAsync.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFileToBlacklistedNameAsync.feature new file mode 100644 index 00000000000..9f31a815df8 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove1/moveFileToBlacklistedNameAsync.feature @@ -0,0 +1,55 @@ +@api @issue-ocis-reva-14 @notToImplementOnOCIS +Feature: users cannot move (rename) a file to a blacklisted name + As an administrator + I want to be able to prevent users from moving (renaming) files to specified file names + So that I can prevent unwanted file names existing in the cloud storage + + Background: + Given using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And the administrator has enabled async operations + + + Scenario: rename a file to a filename that is banned by default + When user "Alice" moves file "/textfile0.txt" asynchronously to "/.htaccess" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should see the following elements + | /textfile0.txt | + + + Scenario: rename a file to a banned filename + Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" + When user "Alice" moves file "/textfile0.txt" asynchronously to "/blacklisted-file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should see the following elements + | /textfile0.txt | + + + Scenario: rename a file to a filename that matches (or not) blacklisted_files_regex + Given user "Alice" has created folder "FOLDER" + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + And the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" moves file "/textfile0.txt" asynchronously to these filenames using the webDAV API then the results should be as listed + | filename | http-code | exists | + | .ext | 403 | no | + | filename.ext | 403 | no | + | bannedfilename.txt | 403 | no | + | containsbannedstring | 403 | no | + | this-ContainsBannedString.txt | 403 | no | + | /FOLDER/.ext | 403 | no | + | /FOLDER/filename.ext | 403 | no | + | /FOLDER/bannedfilename.txt | 403 | no | + | /FOLDER/containsbannedstring | 403 | no | + | /FOLDER/this-ContainsBannedString.txt | 403 | no | + | .extension | 202 | yes | + | filename.txt | 202 | yes | + | bannedfilename | 202 | yes | + | bannedfilenamewithoutdot | 202 | yes | + | not-contains-banned-string.txt | 202 | yes | + | /FOLDER/.extension | 202 | yes | + | /FOLDER/filename.txt | 202 | yes | + | /FOLDER/bannedfilename | 202 | yes | + | /FOLDER/bannedfilenamewithoutdot | 202 | yes | + | /FOLDER/not-contains-banned-string.txt | 202 | yes | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFileToExcludedDirectoryAsync.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFileToExcludedDirectoryAsync.feature new file mode 100644 index 00000000000..40942abb222 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove1/moveFileToExcludedDirectoryAsync.feature @@ -0,0 +1,59 @@ +@api @issue-ocis-reva-14 @notToImplementOnOCIS +Feature: users cannot move (rename) a file to or into an excluded directory + As an administrator + I want to be able to exclude directories (folders) from being processed. Any attempt to rename an existing file or folder to one of those names should be refused. + So that I can have directories on my cloud server storage that are not available for syncing. + + Background: + Given using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And the administrator has enabled async operations + + + Scenario: rename a file to an excluded directory name + Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" moves file "/textfile0.txt" asynchronously to "/.github" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should see the following elements + | /textfile0.txt | + + + Scenario: rename a file to an excluded directory name inside a parent directory + Given user "Alice" has created folder "FOLDER" + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" moves file "/textfile0.txt" asynchronously to "/FOLDER/.github" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should see the following elements + | /textfile0.txt | + + + Scenario: rename a file to a filename that matches (or not) excluded_directories_regex + Given user "Alice" has created folder "FOLDER" + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + And the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" moves file "/textfile0.txt" asynchronously to these filenames using the webDAV API then the results should be as listed + | filename | http-code | exists | + | endswith.bad | 403 | no | + | thisendswith.bad | 403 | no | + | .git | 403 | no | + | .github | 403 | no | + | containsvirusinthename | 403 | no | + | this-containsvirusinthename.txt | 403 | no | + | /FOLDER/endswith.bad | 403 | no | + | /FOLDER/thisendswith.bad | 403 | no | + | /FOLDER/.git | 403 | no | + | /FOLDER/.github | 403 | no | + | /FOLDER/containsvirusinthename | 403 | no | + | /FOLDER/this-containsvirusinthename.txt | 403 | no | + | endswith.badandotherstuff | 202 | yes | + | thisendswith.badandotherstuff | 202 | yes | + | name.git | 202 | yes | + | name.github | 202 | yes | + | not-contains-virus-in-the-name.txt | 202 | yes | + | /FOLDER/endswith.badandotherstuff | 202 | yes | + | /FOLDER/thisendswith.badandotherstuff | 202 | yes | + | /FOLDER/name.git | 202 | yes | + | /FOLDER/name.github | 202 | yes | + | /FOLDER/not-contains-virus-in-the-name.txt | 202 | yes | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFolder.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFolder.feature new file mode 100644 index 00000000000..bd8cd64dacd --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove1/moveFolder.feature @@ -0,0 +1,201 @@ +@api @issue-ocis-reva-14 +Feature: move (rename) folder + As a user + I want to be able to move and rename folders + So that I can quickly manage my file system + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Renaming a folder to a backslash should return an error + Given using DAV path + And user "Alice" has created folder "/testshare" + When user "Alice" moves folder "/testshare" to "\" using the WebDAV API + Then the HTTP status code should be "400" + And user "Alice" should see the following elements + | /testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Renaming a folder beginning with a backslash should return an error + Given using DAV path + And user "Alice" has created folder "/testshare" + When user "Alice" moves folder "/testshare" to "\testshare" using the WebDAV API + Then the HTTP status code should be "400" + And user "Alice" should see the following elements + | /testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Renaming a folder including a backslash encoded should return an error + Given using DAV path + And user "Alice" has created folder "/testshare" + When user "Alice" moves folder "/testshare" to "/hola\hola" using the WebDAV API + Then the HTTP status code should be "400" + And user "Alice" should see the following elements + | /testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Move a folder into an other one + Given using DAV path + And user "Alice" has created folder "/testshare" + And user "Alice" has created folder "/an-other-folder" + When user "Alice" moves folder "/testshare" to "/an-other-folder/testshare" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should not see the following elements + | /testshare/ | + And user "Alice" should see the following elements + | /an-other-folder/testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Move a folder into a nonexistent one + Given using DAV path + And user "Alice" has created folder "/testshare" + When user "Alice" moves folder "/testshare" to "/not-existing/testshare" using the WebDAV API + Then the HTTP status code should be "409" + And user "Alice" should see the following elements + | /testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: renaming folder with dots in the path + Given using DAV path + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "/abc.txt" + When user "Alice" moves folder "" to "/uploadFolder" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/uploadFolder/abc.txt" for user "Alice" should be "uploaded content for file name ending with a dot" + Examples: + | dav_version | folder_name | + | old | /upload. | + | old | /upload.1 | + | old | /upload...1.. | + | old | /... | + | old | /..upload | + | new | /upload. | + | new | /upload.1 | + | new | /upload...1.. | + | new | /... | + | new | /..upload | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | + | spaces | /upload. | + | spaces | /upload.1 | + | spaces | /upload...1.. | + | spaces | /... | + | spaces | /..upload | + + @issue-ocis-3023 + Scenario Outline: Moving a folder into a sub-folder of itself + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has created folder "PARENT/CHILD" + And user "Alice" has uploaded file with content "parent text" to "/PARENT/parent.txt" + And user "Alice" has uploaded file with content "child text" to "/PARENT/CHILD/child.txt" + When user "Alice" moves folder "/PARENT" to "/PARENT/CHILD/PARENT" using the WebDAV API + Then the HTTP status code should be "409" + And the content of file "/PARENT/parent.txt" for user "Alice" should be "parent text" + And the content of file "/PARENT/CHILD/child.txt" for user "Alice" should be "child text" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @skipOnOcis + Scenario Outline: Moving a folder out of a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created folder "/testshare/testsubfolder" + And user "Brian" has uploaded file with content "test data" to "/testshare/testsubfolder/testfile.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + When user "" moves folder "/testshare/testsubfolder" to "/testsubfolder" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testsubfolder/testfile.txt" for user "" should be "test data" + And as "Alice" folder "/testshare/testsubfolder" should not exist + And as "Brian" folder "/testshare/testsubfolder" should not exist + Examples: + | dav_version | mover | + | old | Alice | + | old | Brian | + | new | Alice | + | new | Brian | + + @files_sharing-app-required @skipOnOcis + Scenario Outline: Moving a folder into a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "" has created folder "/testsubfolder" + And user "" has uploaded file with content "test data" to "/testsubfolder/testfile.txt" + When user "" moves folder "/testsubfolder" to "/testshare/testsubfolder" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testshare/testsubfolder/testfile.txt" for user "Alice" should be "test data" + And the content of file "/testshare/testsubfolder/testfile.txt" for user "Brian" should be "test data" + And as "" file "/testsubfolder" should not exist + Examples: + | dav_version | mover | + | old | Alice | + | old | Brian | + | new | Alice | + | new | Brian | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFolderToBlacklistedName.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFolderToBlacklistedName.feature new file mode 100644 index 00000000000..e412b6444d1 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove1/moveFolderToBlacklistedName.feature @@ -0,0 +1,87 @@ +@api @issue-ocis-reva-14 +Feature: users cannot move (rename) a folder to a blacklisted name + As an administrator + I want to be able to prevent users from moving (renaming) folders to specified names + So that I can prevent unwanted folder names existing in the cloud storage + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Rename a folder to a name that is banned by default + Given using DAV path + And user "Alice" has created folder "/testshare" + When user "Alice" moves folder "/testshare" to "/.htaccess" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should see the following elements + | /testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Rename a folder to a banned name + Given using DAV path + And user "Alice" has created folder "/testshare" + And the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" + When user "Alice" moves folder "/testshare" to "/blacklisted-file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should see the following elements + | /testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: rename a folder to a folder name that matches (or not) blacklisted_files_regex + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created folder "/FOLDER" + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + And the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Brian" moves folder "/testshare" to these foldernames using the webDAV API then the results should be as listed + | foldername | http-code | exists | + | .ext | 403 | no | + | filename.ext | 403 | no | + | bannedfilename.txt | 403 | no | + | containsbannedstring | 403 | no | + | this-ContainsBannedString.txt | 403 | no | + | /FOLDER/.ext | 403 | no | + | /FOLDER/filename.ext | 403 | no | + | /FOLDER/bannedfilename.txt | 403 | no | + | /FOLDER/containsbannedstring | 403 | no | + | /FOLDER/this-ContainsBannedString.txt | 403 | no | + | .extension | 201 | yes | + | filename.txt | 201 | yes | + | bannedfilename | 201 | yes | + | bannedfilenamewithoutdot | 201 | yes | + | not-contains-banned-string.txt | 201 | yes | + | /FOLDER/.extension | 201 | yes | + | /FOLDER/filename.txt | 201 | yes | + | /FOLDER/bannedfilename | 201 | yes | + | /FOLDER/bannedfilenamewithoutdot | 201 | yes | + | /FOLDER/not-contains-banned-string.txt | 201 | yes | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFolderToExcludedDirectory.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFolderToExcludedDirectory.feature new file mode 100644 index 00000000000..84c846a16ae --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove1/moveFolderToExcludedDirectory.feature @@ -0,0 +1,90 @@ +@api @issue-ocis-reva-14 +Feature: users cannot move (rename) a folder to or into an excluded directory + As an administrator + I want to be able to exclude directories (folders) from being processed. Any attempt to rename an existing folder to one of those names should be refused. + So that I can have directories on my cloud server storage that are not available for syncing. + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Rename a folder to an excluded directory name + Given using DAV path + And user "Alice" has created folder "/testshare" + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" moves folder "/testshare" to "/.github" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should see the following elements + | /testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Rename a folder to an excluded directory name inside a parent directory + Given using DAV path + And user "Alice" has created folder "/testshare" + And user "Alice" has created folder "/FOLDER" + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" moves folder "/testshare" to "/FOLDER/.github" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should see the following elements + | /testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: rename a folder to a folder name that matches (or not) excluded_directories_regex + Given using DAV path + And user "Alice" has created folder "/testshare" + And user "Alice" has created folder "/FOLDER" + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + And the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" moves folder "/testshare" to these foldernames using the webDAV API then the results should be as listed + | foldername | http-code | exists | + | endswith.bad | 403 | no | + | thisendswith.bad | 403 | no | + | .git | 403 | no | + | .github | 403 | no | + | containsvirusinthename | 403 | no | + | this-containsvirusinthename.txt | 403 | no | + | /FOLDER/endswith.bad | 403 | no | + | /FOLDER/thisendswith.bad | 403 | no | + | /FOLDER/.git | 403 | no | + | /FOLDER/.github | 403 | no | + | /FOLDER/containsvirusinthename | 403 | no | + | /FOLDER/this-containsvirusinthename.txt | 403 | no | + | endswith.badandotherstuff | 201 | yes | + | thisendswith.badandotherstuff | 201 | yes | + | name.git | 201 | yes | + | name.github | 201 | yes | + | not-contains-virus-in-the-name.txt | 201 | yes | + | /FOLDER/endswith.badandotherstuff | 201 | yes | + | /FOLDER/thisendswith.badandotherstuff | 201 | yes | + | /FOLDER/name.git | 201 | yes | + | /FOLDER/name.github | 201 | yes | + | /FOLDER/not-contains-virus-in-the-name.txt | 201 | yes | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavMove2/moveFile.feature b/tests/acceptance/features/coreApiWebdavMove2/moveFile.feature new file mode 100644 index 00000000000..9255feef2fd --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove2/moveFile.feature @@ -0,0 +1,580 @@ +@api +Feature: move (rename) file + As a user + I want to be able to move and rename files + So that I can manage my file system + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: Moving a file + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + When user "Alice" moves file "/textfile0.txt" to "/FOLDER/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/FOLDER/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest + Scenario Outline: Moving and overwriting a file + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 1" to "textfile1.txt" + When user "Alice" moves file "/textfile0.txt" to "/textfile1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/textfile1.txt" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Moving (renaming) a file to be only different case + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + When user "Alice" moves file "/textfile0.txt" to "/TextFile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/textfile0.txt" should not exist + And the content of file "/TextFile0.txt" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest + Scenario Outline: Moving (renaming) a file to a file with only different case to an existing file + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 1" to "textfile1.txt" + When user "Alice" moves file "/textfile1.txt" to "/TextFile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + And the content of file "/TextFile0.txt" for user "Alice" should be "ownCloud test text file 1" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Moving (renaming) a file to a file in a folder with only different case to an existing file + Given using DAV path + And user "Alice" has created folder "PARENT" + And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 1" to "textfile1.txt" + When user "Alice" moves file "/textfile1.txt" to "/PARENT/Parent.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/PARENT/parent.txt" for user "Alice" should be "ownCloud test text file parent" + And the content of file "/PARENT/Parent.txt" for user "Alice" should be "ownCloud test text file 1" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @skipOnOcis + Scenario Outline: Moving a file into a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "" has uploaded file with content "test data" to "/testfile.txt" + When user "" moves file "/testfile.txt" to "/testshare/testfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testshare/testfile.txt" for user "Alice" should be "test data" + And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data" + And as "" file "/testfile.txt" should not exist + Examples: + | dav_version | mover | + | old | Alice | + | new | Alice | + | old | Brian | + | new | Brian | + + @files_sharing-app-required @skipOnOcis + Scenario Outline: Moving a file out of a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "test data" to "/testshare/testfile.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + When user "" moves file "/testshare/testfile.txt" to "/testfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testfile.txt" for user "" should be "test data" + And as "Alice" file "/testshare/testfile.txt" should not exist + And as "Brian" file "/testshare/testfile.txt" should not exist + Examples: + | dav_version | mover | + | old | Alice | + | new | Alice | + | old | Brian | + | new | Brian | + + @files_sharing-app-required @skipOnOcis + Scenario Outline: Moving a file to a shared folder with no permissions + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | read | + | shareWith | Alice | + When user "Alice" moves file "/textfile0.txt" to "/testshare/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should not be able to download file "/testshare/textfile0.txt" + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required @skipOnOcis + Scenario Outline: Moving a file to overwrite a file in a shared folder with no permissions + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "Welcome to ownCloud" to "fileToCopy.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | read | + | shareWith | Alice | + And user "Brian" has copied file "/fileToCopy.txt" to "/testshare/overwritethis.txt" + When user "Alice" moves file "/textfile0.txt" to "/testshare/overwritethis.txt" using the WebDAV API + Then the HTTP status code should be "403" + And the content of file "/testshare/overwritethis.txt" for user "Alice" should be "Welcome to ownCloud" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: move file into a not-existing folder + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToMove.txt" + When user "Alice" moves file "/fileToMove.txt" to "/not-existing/fileToMove.txt" using the WebDAV API + Then the HTTP status code should be "409" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-211 + Scenario Outline: rename a file into an invalid filename + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToRename.txt" + When user "Alice" moves file "/fileToRename.txt" to "/a\\a" using the WebDAV API + Then the HTTP status code should be "400" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Checking file id after a move + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has stored id of file "/textfile0.txt" + When user "Alice" moves file "/textfile0.txt" to "/FOLDER/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" file "/FOLDER/textfile0.txt" should have the previously stored id + And user "Alice" should not see the following elements + | /textfile0.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @skipOnOcis + Scenario Outline: Checking file id after a move between received shares + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/folderA" + And user "Alice" has created folder "/folderB" + And user "Alice" has shared folder "/folderA" with user "Brian" + And user "Alice" has shared folder "/folderB" with user "Brian" + And user "Brian" has created folder "/folderA/ONE" + And user "Brian" has stored id of folder "/folderA/ONE" + And user "Brian" has created folder "/folderA/ONE/TWO" + When user "Brian" moves folder "/folderA/ONE" to "/folderB/ONE" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/folderA" should exist + And as "Brian" folder "/folderA/ONE" should not exist + # yes, a weird bug used to make this one fail + And as "Brian" folder "/folderA/ONE/TWO" should not exist + And as "Brian" folder "/folderB/ONE" should exist + And as "Brian" folder "/folderB/ONE/TWO" should exist + And user "Brian" folder "/folderB/ONE" should have the previously stored id + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-reva-211 + Scenario Outline: Renaming a file to a path with extension .part should not be possible + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToRename.txt" + When user "Alice" moves file "/fileToRename.txt" to "/welcome.part" using the WebDAV API + Then the HTTP status code should be "400" + And the DAV exception should be "OCA\DAV\Connector\Sabre\Exception\InvalidPath" + And the DAV message should be "Can`t upload files with extension .part because these extensions are reserved for internal use." + And the DAV reason should be "Can`t upload files with extension .part because these extensions are reserved for internal use." + And user "Alice" should see the following elements + | /fileToRename.txt | + But user "Alice" should not see the following elements + | /fileToRename.part | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @sqliteDB + Scenario Outline: renaming to a file with special characters + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 1" to "textfile1.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 2" to "textfile2.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 3" to "textfile3.txt" + When user "Alice" moves the following file using the WebDAV API + | source | destination | + | /textfile0.txt | *a@b#c$e%f&g* | + | /textfile1.txt | 1 2 3##.## | + | /textfile2.txt | file[2] | + | /textfile3.txt | file [ 3 ] | + Then the HTTP status code of responses on all endpoints should be "201" + And the content of file "*a@b#c$e%f&g*" for user "Alice" should be "ownCloud test text file 0" + And the content of file "1 2 3##.##" for user "Alice" should be "ownCloud test text file 1" + And the content of file "file[2]" for user "Alice" should be "ownCloud test text file 2" + And the content of file "file [ 3 ]" for user "Alice" should be "ownCloud test text file 3" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-265 + #after fixing the issues merge this Scenario into the one above + Scenario Outline: renaming to a file with question mark in its name + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + When user "Alice" moves file "/textfile0.txt" to "/" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | renamed_file | + | old | #oc ab?cd=ef# | + | new | #oc ab?cd=ef# | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | renamed_file | + | spaces | #oc ab?cd=ef# | + + + Scenario Outline: renaming file with dots in the path + Given using DAV path + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "/" + When user "Alice" moves file "/" to "/abc.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/abc.txt" should exist + Examples: + | dav_version | folder_name | file_name | + | old | /upload. | abc. | + | old | /upload. | abc . | + | old | /upload.1 | abc | + | old | /upload...1.. | abc...txt.. | + | old | /... | abcd.txt | + | old | /..upload | ..abc | + | new | /upload. | abc. | + | new | /upload. | abc . | + | new | /upload.1 | ..abc.txt | + | new | /upload...1.. | abc...txt.. | + | new | /... | ... | + | new | /..upload | ..abc | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | file_name | + | spaces | /upload. | abc. | + | spaces | /upload. | abc . | + | spaces | /upload.1 | abc | + | spaces | /upload...1.. | abc...txt.. | + | spaces | /... | abcd.txt | + | spaces | /... | ... | + + @smokeTest + Scenario Outline: user tries to move a file that doesnt exist into a folder + Given using DAV path + And user "Alice" has created folder "FOLDER" + When user "Alice" moves file "/doesNotExist.txt" to "/FOLDER/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "404" + And as "Alice" file "/FOLDER/textfile0.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest + Scenario Outline: user tries to rename a file that doesnt exist + Given using DAV path + When user "Alice" moves file "/doesNotExist.txt" to "/exist.txt" using the WebDAV API + Then the HTTP status code should be "404" + And as "Alice" file "/exist.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Moving a hidden file + Given using DAV path + And user "Alice" has created folder "FOLDER" + And user "Alice" has uploaded the following files with content "hidden file" + | path | + | .hidden_file101 | + | /FOLDER/.hidden_file102 | + When user "Alice" moves the following files using the WebDAV API + | from | to | + | .hidden_file101 | /FOLDER/.hidden_file101 | + | /FOLDER/.hidden_file102 | .hidden_file102 | + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" the following files should exist + | path | + | .hidden_file102 | + | /FOLDER/.hidden_file101 | + And the content of the following files for user "Alice" should be "hidden file" + | path | + | .hidden_file102 | + | /FOLDER/.hidden_file101 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Renaming to/from a hidden file + Given using DAV path + And user "Alice" has uploaded the following files with content "hidden file" + | path | + | .hidden_file101 | + | hidden_file101.txt | + When user "Alice" moves the following files using the WebDAV API + | from | to | + | .hidden_file101 | hidden_file102.txt | + | hidden_file101.txt | .hidden_file102 | + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" the following files should exist + | path | + | .hidden_file102 | + | hidden_file102.txt | + And the content of the following files for user "Alice" should be "hidden file" + | path | + | .hidden_file102 | + | hidden_file102.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Moving a file (deep moves with various folder and file names) + Given using DAV path + And user "Alice" has created folder "" + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "//" + When user "Alice" moves file "//" to "//" using the WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "//" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | source_folder | source_file | target_folder | target_file | + | old | text | file.txt | 0 | file.txt | + | old | text | file.txt | 1 | file.txt | + | old | 0 | file.txt | text | file.txt | + | old | 1 | file.txt | text | file.txt | + | old | texta | 0 | textb | file.txt | + | old | texta | 1 | textb | file.txt | + | old | texta | file.txt | textb | 0 | + | old | texta | file.txt | textb | 1 | + | new | text | file.txt | 0 | file.txt | + | new | text | file.txt | 1 | file.txt | + | new | 0 | file.txt | text | file.txt | + | new | 1 | file.txt | text | file.txt | + | new | texta | 0 | textb | file.txt | + | new | texta | 1 | textb | file.txt | + | new | texta | file.txt | textb | 0 | + | new | texta | file.txt | textb | 1 | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | source_folder | source_file | target_folder | target_file | + | spaces | text | file.txt | 0 | file.txt | + | spaces | text | file.txt | 1 | file.txt | + | spaces | 0 | file.txt | text | file.txt | + | spaces | 1 | file.txt | text | file.txt | + | spaces | texta | 0 | textb | file.txt | + | spaces | texta | 1 | textb | file.txt | + | spaces | texta | file.txt | textb | 0 | + | spaces | texta | file.txt | textb | 1 | + + + Scenario Outline: Moving a file from a folder to the root + Given using DAV path + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "//" + When user "Alice" moves file "//" to "/" using the WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "/" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | source_folder | source_file | target_file | + | old | 0 | file.txt | file.txt | + | old | 1 | file.txt | file.txt | + | old | texta | 0 | file.txt | + | old | texta | 1 | file.txt | + | old | texta | file.txt | 0 | + | old | texta | file.txt | 1 | + | new | 0 | file.txt | file.txt | + | new | 1 | file.txt | file.txt | + | new | texta | 0 | file.txt | + | new | texta | 1 | file.txt | + | new | texta | file.txt | 0 | + | new | texta | file.txt | 0 | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | source_folder | source_file | target_file | + | spaces | 0 | file.txt | file.txt | + | spaces | 1 | file.txt | file.txt | + | spaces | texta | 0 | file.txt | + | spaces | texta | 1 | file.txt | + | spaces | texta | file.txt | 0 | + | spaces | texta | file.txt | 0 | + + + Scenario Outline: move a file of size zero byte + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/zerobyte.txt" to "/zerobyte.txt" + And user "Alice" has created folder "/testZeroByte" + When user "Alice" moves file "/zerobyte.txt" to "/testZeroByte/zerobyte.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/testZeroByte/zerobyte.txt" should exist + And as "Alice" file "/zerobyte.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: rename a file of size zero byte + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/zerobyte.txt" to "/zerobyte.txt" + When user "Alice" moves file "/zerobyte.txt" to "/rename_zerobyte.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/rename_zerobyte.txt" should exist + And as "Alice" file "/zerobyte.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavMove2/moveFileToBlacklistedName.feature b/tests/acceptance/features/coreApiWebdavMove2/moveFileToBlacklistedName.feature new file mode 100644 index 00000000000..6aaea8d7573 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove2/moveFileToBlacklistedName.feature @@ -0,0 +1,80 @@ +@api +Feature: users cannot move (rename) a file to a blacklisted name + As an administrator + I want to be able to prevent users from moving (renaming) files to specified file names + So that I can prevent unwanted file names existing in the cloud storage + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + + @issue-ocis-reva-211 + Scenario Outline: rename a file to a filename that is banned by default + Given using DAV path + When user "Alice" moves file "/textfile0.txt" to "/.htaccess" using the WebDAV API + Then the HTTP status code should be "403" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: rename a file to a banned filename + Given using DAV path + And the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" + When user "Alice" moves file "/textfile0.txt" to "/blacklisted-file.txt" using the WebDAV API + Then the HTTP status code should be "403" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: rename a file to a filename that matches (or not) blacklisted_files_regex + Given using DAV path + And user "Alice" has created folder "FOLDER" + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + And the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" moves file "/textfile0.txt" to these filenames using the webDAV API then the results should be as listed + | filename | http-code | exists | + | .ext | 403 | no | + | filename.ext | 403 | no | + | bannedfilename.txt | 403 | no | + | containsbannedstring | 403 | no | + | this-ContainsBannedString.txt | 403 | no | + | /FOLDER/.ext | 403 | no | + | /FOLDER/filename.ext | 403 | no | + | /FOLDER/bannedfilename.txt | 403 | no | + | /FOLDER/containsbannedstring | 403 | no | + | /FOLDER/this-ContainsBannedString.txt | 403 | no | + | .extension | 201 | yes | + | filename.txt | 201 | yes | + | bannedfilename | 201 | yes | + | bannedfilenamewithoutdot | 201 | yes | + | not-contains-banned-string.txt | 201 | yes | + | /FOLDER/.extension | 201 | yes | + | /FOLDER/filename.txt | 201 | yes | + | /FOLDER/bannedfilename | 201 | yes | + | /FOLDER/bannedfilenamewithoutdot | 201 | yes | + | /FOLDER/not-contains-banned-string.txt | 201 | yes | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavMove2/moveFileToExcludedDirectory.feature b/tests/acceptance/features/coreApiWebdavMove2/moveFileToExcludedDirectory.feature new file mode 100644 index 00000000000..05e848f39e6 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove2/moveFileToExcludedDirectory.feature @@ -0,0 +1,84 @@ +@api @issue-ocis-reva-14 +Feature: users cannot move (rename) a file to or into an excluded directory + As an administrator + I want to be able to exclude directories (folders) from being processed. Any attempt to rename an existing file to one of those names should be refused. + So that I can have directories on my cloud server storage that are not available for syncing. + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + + + Scenario Outline: rename a file to an excluded directory name + Given using DAV path + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" moves file "/textfile0.txt" to "/.github" using the WebDAV API + Then the HTTP status code should be "403" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: rename a file to an excluded directory name inside a parent directory + Given using DAV path + And user "Alice" has created folder "FOLDER" + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" moves file "/textfile0.txt" to "/FOLDER/.github" using the WebDAV API + Then the HTTP status code should be "403" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: rename a file to a filename that matches (or not) excluded_directories_regex + Given using DAV path + And user "Alice" has created folder "FOLDER" + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + And the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" moves file "/textfile0.txt" to these filenames using the webDAV API then the results should be as listed + | filename | http-code | exists | + | endswith.bad | 403 | no | + | thisendswith.bad | 403 | no | + | .git | 403 | no | + | .github | 403 | no | + | containsvirusinthename | 403 | no | + | this-containsvirusinthename.txt | 403 | no | + | /FOLDER/endswith.bad | 403 | no | + | /FOLDER/thisendswith.bad | 403 | no | + | /FOLDER/.git | 403 | no | + | /FOLDER/.github | 403 | no | + | /FOLDER/containsvirusinthename | 403 | no | + | /FOLDER/this-containsvirusinthename.txt | 403 | no | + | endswith.badandotherstuff | 201 | yes | + | thisendswith.badandotherstuff | 201 | yes | + | name.git | 201 | yes | + | name.github | 201 | yes | + | not-contains-virus-in-the-name.txt | 201 | yes | + | /FOLDER/endswith.badandotherstuff | 201 | yes | + | /FOLDER/thisendswith.badandotherstuff | 201 | yes | + | /FOLDER/name.git | 201 | yes | + | /FOLDER/name.github | 201 | yes | + | /FOLDER/not-contains-virus-in-the-name.txt | 201 | yes | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature b/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature new file mode 100644 index 00000000000..9e5f929f6d6 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature @@ -0,0 +1,222 @@ +@api @files_sharing-app-required @skipOnOcV10 +Feature: move (rename) file + As a user + I want to be able to move and rename files + So that I can manage my file system + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Moving a file into a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "" has uploaded file with content "test data" to "/testfile.txt" + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "" moves file "/testfile.txt" to "/testfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/Shares/testshare/testfile.txt" for user "Alice" should be "test data" + And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data" + And as "" file "/testfile.txt" should not exist + Examples: + | dav_version | mover | destination_folder | + | old | Alice | /Shares/testshare | + | old | Brian | /testshare | + | new | Alice | /Shares/testshare | + | new | Brian | /testshare | + + + Scenario Outline: Moving a file out of a shared folder as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "test data" to "/testshare/testfile.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Brian" moves file "/testshare/testfile.txt" to "/testfile.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testfile.txt" for user "Brian" should be "test data" + And as "Alice" file "/Shares/testshare/testfile.txt" should not exist + And as "Brian" file "/testshare/testfile.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Can not move a file out of a shared folder as the sharee + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "test data" to "/testshare/testfile.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Alice" moves file "/Shares/testshare/testfile.txt" to "/testfile.txt" using the WebDAV API + Then the HTTP status code should be "502" + And as "Alice" file "/Shares/testshare/testfile.txt" should exist + And as "Brian" file "/testshare/testfile.txt" should exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Moving a folder into a shared folder as the sharee and as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "" has created folder "/testsubfolder" + And user "" has uploaded file with content "test data" to "/testsubfolder/testfile.txt" + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "" moves folder "/testsubfolder" to "/testsubfolder" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/Shares/testshare/testsubfolder/testfile.txt" for user "Alice" should be "test data" + And the content of file "/testshare/testsubfolder/testfile.txt" for user "Brian" should be "test data" + And as "" file "/testsubfolder" should not exist + Examples: + | dav_version | mover | destination_folder | + | old | Alice | /Shares/testshare | + | old | Brian | /testshare | + | new | Alice | /Shares/testshare | + | new | Brian | /testshare | + + + Scenario Outline: Moving a folder out of a shared folder as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created the following folders + | path | + | /testshare | + | /testshare/testsubfolder | + And user "Brian" has uploaded file with content "test data" to "/testshare/testsubfolder/testfile.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Brian" moves folder "/testshare/testsubfolder" to "/testsubfolder" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/testsubfolder/testfile.txt" for user "Brian" should be "test data" + And as "Alice" folder "/testshare/testsubfolder" should not exist + And as "Brian" folder "/testshare/testsubfolder" should not exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Moving a folder out of a shared folder as the sharee + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created the following folders + | path | + | /testshare | + | /testshare/testsubfolder | + And user "Brian" has uploaded file with content "test data" to "/testshare/testsubfolder/testfile.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Alice" moves folder "/Shares/testshare/testsubfolder" to "/testsubfolder" using the WebDAV API + Then the HTTP status code should be "502" + And as "Alice" folder "/Shares/testshare/testsubfolder" should exist + And as "Brian" folder "/testshare/testsubfolder" should exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Moving a file to a shared folder with no permissions + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | read | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Alice" moves file "/textfile0.txt" to "/Shares/testshare/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should not be able to download file "/Shares/testshare/textfile0.txt" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Moving a file to overwrite a file in a shared folder with no permissions + Given using DAV path + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "Welcome to ownCloud" to "fileToCopy.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | read | + | shareWith | Alice | + And user "Brian" has copied file "/fileToCopy.txt" to "/testshare/overwritethis.txt" + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Alice" moves file "/textfile0.txt" to "/Shares/testshare/overwritethis.txt" using the WebDAV API + Then the HTTP status code should be "403" + And the content of file "/Shares/testshare/overwritethis.txt" for user "Alice" should be "Welcome to ownCloud" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Checking file id after a move between received shares + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created the following folders + | path | + | /folderA | + | /folderB | + And user "Alice" has shared folder "/folderA" with user "Brian" + And user "Alice" has shared folder "/folderB" with user "Brian" + And user "Brian" has accepted share "/folderA" offered by user "Alice" + And user "Brian" has accepted share "/folderB" offered by user "Alice" + And user "Brian" has created the following folders + | path | + | /Shares/folderA/ONE | + | /Shares/folderA/ONE/TWO | + And user "Brian" has stored id of folder "/Shares/folderA/ONE" + When user "Brian" moves folder "/Shares/folderA/ONE" to "/Shares/folderB/ONE" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/folderA" should exist + And as "Brian" folder "/Shares/folderA/ONE" should not exist + And as "Brian" folder "/Shares/folderA/ONE/TWO" should not exist + And as "Brian" folder "/Shares/folderB/ONE" should exist + And as "Brian" folder "/Shares/folderB/ONE/TWO" should exist + And user "Brian" folder "/Shares/folderB/ONE" should have the previously stored id + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature b/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature new file mode 100644 index 00000000000..76e436229a8 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature @@ -0,0 +1,342 @@ +@api +Feature: download file + As a user + I want to be able to download files + So that I can work wih local copies of files on my client system + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has uploaded file with content "Welcome this is just an example file for developers." to "/welcome.txt" + + @smokeTest + Scenario Outline: download a file + Given using DAV path + When user "Alice" downloads file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded content should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-12 + Scenario Outline: download a file with range + Given using DAV path + When user "Alice" downloads file "/welcome.txt" with range "bytes=24-50" using the WebDAV API + Then the HTTP status code should be "206" + And the downloaded content should be "example file for developers" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: download a file larger than 4MB (ref: https://github.com/sabre-io/http/pull/119 ) + Given using DAV path + And user "Alice" has uploaded file "/file9000000.txt" ending with "text at end of file" of size 9000000 bytes + When user "Alice" downloads file "/file9000000.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the size of the downloaded file should be 9000000 bytes + And the downloaded content should end with "text at end of file" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest @notToImplementOnOCIS + Scenario Outline: Downloading a file should serve security headers + Given using DAV path + When user "Alice" downloads file "/welcome.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Disposition | attachment; filename*=UTF-8''welcome.txt; filename="welcome.txt" | + | Content-Security-Policy | default-src 'none'; | + | X-Content-Type-Options | nosniff | + | X-Download-Options | noopen | + | X-Frame-Options | SAMEORIGIN | + | X-Permitted-Cross-Domain-Policies | none | + | X-Robots-Tag | none | + | X-XSS-Protection | 0 | + And the downloaded content should start with "Welcome" + Examples: + | dav_version | + | old | + | new | + + @notToImplementOnOCIS + Scenario Outline: Doing a GET with a web login should work without CSRF token on the new backend + Given using DAV path + And user "Alice" has logged in to a web-style session + When the client sends a "GET" to "/remote.php/dav/files/%username%/welcome.txt" of user "Alice" without requesttoken + Then the HTTP status code should be "200" + And the downloaded content should start with "Welcome" + Examples: + | dav_version | + | old | + | new | + + @notToImplementOnOCIS + Scenario Outline: Doing a GET with a web login should work with CSRF token on the new backend + Given using DAV path + And user "Alice" has logged in to a web-style session + When the client sends a "GET" to "/remote.php/dav/files/%username%/welcome.txt" of user "Alice" with requesttoken + Then the HTTP status code should be "200" + And the downloaded content should start with "Welcome" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Get the size of a file + Given using DAV path + And user "Alice" has uploaded file with content "This is a test file" to "test-file.txt" + When user "Alice" gets the size of file "test-file.txt" using the WebDAV API + Then the HTTP status code should be "207" + And the size of the file should be "19" + + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-98 + Scenario Outline: Get the content-length response header of a pdf file + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/simple.pdf" to "/simple.pdf" + When user "Alice" downloads file "/simple.pdf" using the WebDAV API + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Length | 9622 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-98 + Scenario Outline: Get the content-length response header of an image file + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/testavatar.png" to "/testavatar.png" + When user "Alice" downloads file "/testavatar.png" using the WebDAV API + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Length | 35323 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Download a file with comma in the filename + Given using DAV path + And user "Alice" has uploaded file with content "file with comma in filename" to + When user "Alice" downloads file using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded content should be "file with comma in filename" + Examples: + | dav_version | filename | + | old | "sample,1.txt" | + | old | ",,,.txt" | + | old | ",,,.," | + | new | "sample,1.txt" | + | new | ",,,.txt" | + | new | ",,,.," | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | filename | + | spaces | "sample,1.txt" | + | spaces | ",,,.txt" | + | spaces | ",,,.," | + + + Scenario Outline: download a file with single part ranges + Given using DAV path + When user "Alice" downloads file "/welcome.txt" with range "bytes=0-51" using the WebDAV API + Then the HTTP status code should be "206" + And the following headers should be set + | header | value | + | Content-Length | 52 | + | Content-Range | bytes 0-51/52 | + And the downloaded content should be "Welcome this is just an example file for developers." + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: download a file with multipart ranges + Given using DAV path + When user "Alice" downloads file "/welcome.txt" with range "bytes=0-6, 40-51" using the WebDAV API + Then the HTTP status code should be "206" or "200" + And if the HTTP status code was "206" then the following headers should match these regular expressions + | Content-Length | /\d+/ | + | Content-Type | /^multipart\/byteranges; boundary=[a-zA-Z0-9_.-]*$/ | + And if the HTTP status code was "206" then the downloaded content for multipart byterange should be: + """ + Content-type: text/plain;charset=UTF-8 + Content-range: bytes 0-6/52 + + Welcome + + Content-type: text/plain;charset=UTF-8 + Content-range: bytes 40-51/52 + + developers. + """ + But if the HTTP status code was "200" then the downloaded content should be "Welcome this is just an example file for developers." + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: download a file with last byte range out of bounds + Given using DAV path + When user "Alice" downloads file "/welcome.txt" with range "bytes=0-55" using the WebDAV API + Then the HTTP status code should be "206" + And the downloaded content should be "Welcome this is just an example file for developers." + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: download a range at the end of a file + Given using DAV path + When user "Alice" downloads file "/welcome.txt" with range "bytes=-11" using the WebDAV API + Then the HTTP status code should be "206" + And the downloaded content should be "developers." + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: download a file with range out of bounds + Given using DAV path + When user "Alice" downloads file "/welcome.txt" with range "bytes=55-60" using the WebDAV API + Then the HTTP status code should be "416" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: download hidden files + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded the following files with content "hidden file" + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + When user "Alice" downloads the following files using the WebDAV API + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + Then the HTTP status code of responses on all endpoints should be "200" + And the content of the following files for user "Alice" should be "hidden file" + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest @skipOnOcV10 + Scenario Outline: Downloading a file should serve security headers + Given using DAV path + When user "Alice" downloads file "/welcome.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the following headers should be set + | header | value | + | Content-Disposition | attachment; filename*=UTF-8''welcome.txt; filename="welcome.txt" | + | Content-Security-Policy | default-src 'none'; | + | X-Content-Type-Options | nosniff | + | X-Download-Options | noopen | + | X-Frame-Options | SAMEORIGIN | + | X-Permitted-Cross-Domain-Policies | none | + | X-Robots-Tag | none | + | X-XSS-Protection | 1; mode=block | + And the downloaded content should start with "Welcome" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario: download a zero byte size file + Given user "Alice" has uploaded file "filesForUpload/zerobyte.txt" to "/zerobyte.txt" + When user "Alice" downloads file "/zerobyte.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the size of the downloaded file should be 0 bytes \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavOperations/listFiles.feature b/tests/acceptance/features/coreApiWebdavOperations/listFiles.feature new file mode 100644 index 00000000000..b91ec668af3 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavOperations/listFiles.feature @@ -0,0 +1,433 @@ +@api +Feature: list files + As a user + I want to be able to list my files and folders (resources) + So that I can understand my file structure in owncloud + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created the following folders + | path | + | simple-folder | + | simple-folder/simple-folder1 | + | simple-folder/simple-empty-folder | + | simple-folder/simple-folder1/simple-folder2 | + And user "Alice" has uploaded the following files with content "simple-test-content" + | path | + | textfile0.txt | + | welcome.txt | + | simple-folder/textfile0.txt | + | simple-folder/welcome.txt | + | simple-folder/simple-folder1/textfile0.txt | + | simple-folder/simple-folder1/welcome.txt | + | simple-folder/simple-folder1/simple-folder2/textfile0.txt | + | simple-folder/simple-folder1/simple-folder2/welcome.txt | + + + Scenario Outline: Get the list of resources in the root folder with depth 0 + Given using DAV path + When user "Alice" lists the resources in "/" with depth "0" using the WebDAV API + Then the HTTP status code should be "207" + And the last DAV response for user "Alice" should not contain these nodes + | name | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + | simple-folder/welcome.txt | + | simple-folder/textfile0.txt | + | simple-folder/simple-empty-folder | + | simple-folder/simple-folder1 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Get the list of resources in the root folder with depth 1 + Given using DAV path + When user "Alice" lists the resources in "/" with depth "1" using the WebDAV API + Then the HTTP status code should be "207" + And the last DAV response for user "Alice" should contain these nodes + | name | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + And the last DAV response for user "Alice" should not contain these nodes + | name | + | simple-folder/welcome.txt | + | simple-folder/textfile0.txt | + | simple-folder/simple-empty-folder | + | simple-folder/simple-folder1 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @depthInfinityPropfindEnabled + Scenario Outline: Get the list of resources in the root folder with depth infinity + Given using DAV path + And the administrator has set depth_infinity_allowed to 1 + When user "Alice" lists the resources in "/" with depth "infinity" using the WebDAV API + Then the HTTP status code should be "207" + And the last DAV response for user "Alice" should contain these nodes + | name | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + | simple-folder/textfile0.txt | + | simple-folder/welcome.txt | + | simple-folder/simple-empty-folder/ | + | simple-folder/simple-folder1/ | + | simple-folder/simple-folder1/simple-folder2 | + | simple-folder/simple-folder1/textfile0.txt | + | simple-folder/simple-folder1/welcome.txt | + | simple-folder/simple-folder1/simple-folder2/textfile0.txt | + | simple-folder/simple-folder1/simple-folder2/welcome.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Get the list of resources in a folder with depth 0 + Given using DAV path + When user "Alice" lists the resources in "/simple-folder" with depth "0" using the WebDAV API + Then the HTTP status code should be "207" + And the last DAV response for user "Alice" should contain these nodes + | name | + | simple-folder/ | + And the last DAV response for user "Alice" should not contain these nodes + | name | + | simple-folder/welcome.txt | + | simple-folder/textfile0.txt | + | simple-folder/simple-empty-folder | + | simple-folder/simple-folder1 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Get the list of resources in a folder with depth 1 + Given using DAV path + When user "Alice" lists the resources in "/simple-folder" with depth "1" using the WebDAV API + Then the HTTP status code should be "207" + And the last DAV response for user "Alice" should contain these nodes + | name | + | simple-folder/welcome.txt | + | simple-folder/textfile0.txt | + | simple-folder/simple-empty-folder | + | simple-folder/simple-folder1 | + And the last DAV response for user "Alice" should not contain these nodes + | name | + | simple-folder/simple-folder1/simple-folder2 | + | simple-folder/simple-folder1/textfile0.txt | + | simple-folder/simple-folder1/welcome.txt | + | simple-folder/simple-folder1/simple-folder2/textfile0.txt | + | simple-folder/simple-folder1/simple-folder2/welcome.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @depthInfinityPropfindEnabled + Scenario Outline: Get the list of resources in a folder with depth infinity + Given using DAV path + And the administrator has set depth_infinity_allowed to 1 + When user "Alice" lists the resources in "/simple-folder" with depth "infinity" using the WebDAV API + Then the HTTP status code should be "207" + And the last DAV response for user "Alice" should contain these nodes + | name | + | /simple-folder/textfile0.txt | + | /simple-folder/welcome.txt | + | /simple-folder/simple-folder1/ | + | simple-folder/simple-folder1/simple-folder2 | + | simple-folder/simple-folder1/textfile0.txt | + | simple-folder/simple-folder1/welcome.txt | + | simple-folder/simple-folder1/simple-folder2/textfile0.txt | + | simple-folder/simple-folder1/simple-folder2/welcome.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Get the list of resources in a folder shared through public link with depth 0 + Given using DAV path + And user "Alice" has created the following folders + | path | + | /simple-folder/simple-folder1/simple-folder2/simple-folder3 | + | /simple-folder/simple-folder1/simple-folder2/simple-folder3/simple-folder4 | + And user "Alice" has created a public link share of folder "simple-folder" + When the public lists the resources in the last created public link with depth "0" using the WebDAV API + Then the HTTP status code should be "207" + And the last public link DAV response should not contain these nodes + | name | + | /textfile0.txt | + | /welcome.txt | + | /simple-folder1/ | + | /simple-folder1/welcome.txt | + | /simple-folder1/simple-folder2 | + | /simple-folder1/textfile0.txt | + | /simple-folder1/simple-folder2/textfile0.txt | + | /simple-folder1/simple-folder2/welcome.txt | + | /simple-folder1/simple-folder2/simple-folder3 | + | /simple-folder1/simple-folder2/simple-folder3/simple-folder4 | + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | dav_version | + | old | + + Examples: + | dav_version | + | new | + + + Scenario Outline: Get the list of resources in a folder shared through public link with depth 1 + Given using DAV path + And user "Alice" has created the following folders + | path | + | /simple-folder/simple-folder1/simple-folder2/simple-folder3 | + | /simple-folder/simple-folder1/simple-folder2/simple-folder3/simple-folder4 | + And user "Alice" has created a public link share of folder "simple-folder" + When the public lists the resources in the last created public link with depth "1" using the WebDAV API + Then the HTTP status code should be "207" + And the last public link DAV response should contain these nodes + | name | + | /textfile0.txt | + | /welcome.txt | + | /simple-folder1/ | + And the last public link DAV response should not contain these nodes + | name | + | /simple-folder1/simple-folder2/textfile0.txt | + | /simple-folder1/simple-folder2/welcome.txt | + | /simple-folder1/simple-folder2/simple-folder3 | + | /simple-folder1/welcome.txt | + | /simple-folder1/simple-folder2 | + | /simple-folder1/textfile0.txt | + | /simple-folder1/simple-folder2/simple-folder3/simple-folder4 | + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | dav_version | + | old | + + Examples: + | dav_version | + | new | + + @depthInfinityPropfindEnabled + Scenario Outline: Get the list of resources in a folder shared through public link with depth infinity + Given using DAV path + And the administrator has set depth_infinity_allowed to 1 + And user "Alice" has created the following folders + | path | + | /simple-folder/simple-folder1/simple-folder2/simple-folder3 | + | /simple-folder/simple-folder1/simple-folder2/simple-folder3/simple-folder4 | + And user "Alice" has created a public link share of folder "simple-folder" + When the public lists the resources in the last created public link with depth "infinity" using the WebDAV API + Then the HTTP status code should be "207" + And the last public link DAV response should contain these nodes + | name | + | /textfile0.txt | + | /welcome.txt | + | /simple-folder1/ | + | /simple-folder1/welcome.txt | + | /simple-folder1/simple-folder2 | + | /simple-folder1/textfile0.txt | + | /simple-folder1/simple-folder2/textfile0.txt | + | /simple-folder1/simple-folder2/welcome.txt | + | /simple-folder1/simple-folder2/simple-folder3 | + | /simple-folder1/simple-folder2/simple-folder3/simple-folder4 | + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | dav_version | + | old | + + Examples: + | dav_version | + | new | + + + Scenario Outline: Get the list of files in the trashbin with depth 0 + Given using DAV path + And user "Alice" has deleted the following resources + | path | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + When user "Alice" lists the resources in the trashbin with depth "0" using the WebDAV API + Then the HTTP status code should be "207" + And the trashbin DAV response should not contain these nodes + | name | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + | simple-folder/textfile0.txt | + | simple-folder/welcome.txt | + | simple-folder/simple-folder1/textfile0.txt | + | simple-folder/simple-folder1/welcome.txt | + | simple-folder/simple-folder1/simple-folder2/textfile0.txt | + | simple-folder/simple-folder1/simple-folder2/welcome.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Get the list of files in the trashbin with depth 1 + Given using DAV path + And user "Alice" has deleted the following resources + | path | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + When user "Alice" lists the resources in the trashbin with depth "1" using the WebDAV API + Then the HTTP status code should be "207" + And the trashbin DAV response should contain these nodes + | name | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + And the trashbin DAV response should not contain these nodes + | name | + | simple-folder/textfile0.txt | + | simple-folder/welcome.txt | + | simple-folder/simple-folder1/textfile0.txt | + | simple-folder/simple-folder1/welcome.txt | + | simple-folder/simple-folder1/simple-folder2/textfile0.txt | + | simple-folder/simple-folder1/simple-folder2/welcome.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @depthInfinityPropfindEnabled + Scenario Outline: Get the list of files in the trashbin with depth infinity + Given using DAV path + And the administrator has set depth_infinity_allowed to 1 + And user "Alice" has deleted the following resources + | path | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + When user "Alice" lists the resources in the trashbin with depth "infinity" using the WebDAV API + Then the HTTP status code should be "207" + And the trashbin DAV response should contain these nodes + | name | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + | simple-folder/textfile0.txt | + | simple-folder/welcome.txt | + | simple-folder/simple-folder1/textfile0.txt | + | simple-folder/simple-folder1/welcome.txt | + | simple-folder/simple-folder1/simple-folder2/textfile0.txt | + | simple-folder/simple-folder1/simple-folder2/welcome.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @depthInfinityPropfindDisabled + Scenario Outline: Get the list of resources in the root folder with depth infinity when depth infinity is not allowed + Given using DAV path + When user "Alice" lists the resources in "/" with depth "infinity" using the WebDAV API + Then the HTTP status code should be "412" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @depthInfinityPropfindDisabled + Scenario Outline: Get the list of resources in a folder shared through public link with depth infinity when depth infinity is not allowed + Given using DAV path + And user "Alice" has created the following folders + | path | + | /simple-folder/simple-folder1/simple-folder2/simple-folder3 | + | /simple-folder/simple-folder1/simple-folder2/simple-folder3/simple-folder4 | + And user "Alice" has created a public link share of folder "simple-folder" + When the public lists the resources in the last created public link with depth "infinity" using the WebDAV API + Then the HTTP status code should be "412" + @notToImplementOnOCIS @issue-ocis-2079 + Examples: + | dav_version | + | old | + + Examples: + | dav_version | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @depthInfinityPropfindDisabled + Scenario Outline: Get the list of files in the trashbin with depth infinity when depth infinity is not allowed + Given using DAV path + And user "Alice" has deleted the following resources + | path | + | textfile0.txt | + | welcome.txt | + | simple-folder/ | + When user "Alice" lists the resources in the trashbin with depth "infinity" using the WebDAV API + Then the HTTP status code should be "412" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavOperations/propfind.feature b/tests/acceptance/features/coreApiWebdavOperations/propfind.feature new file mode 100644 index 00000000000..7994cdcf58d --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavOperations/propfind.feature @@ -0,0 +1,50 @@ +@api +Feature: PROPFIND + + @issue-ocis-751 + Scenario Outline: PROPFIND to "/remote.php/dav/(files|spaces)" + Given user "Alice" has been created with default attributes and without skeleton files + When user "Alice" requests "" with "PROPFIND" using basic auth + Then the HTTP status code should be "405" + Examples: + | dav_path | + | /remote.php/dav/files | + + @skipOnOcV10 @personalSpace + Examples: + | dav_path | + | /remote.php/dav/spaces | + + + Scenario Outline: PROPFIND to "/remote.php/dav/(files|spaces)" with depth header + Given user "Alice" has been created with default attributes and without skeleton files + And the administrator has set depth_infinity_allowed to + When user "Alice" requests "" with "PROPFIND" using basic auth and with headers + | header | value | + | depth | | + Then the HTTP status code should be "" + @notToImplementOnOCIS @depthInfinityPropfindEnabled + Examples: + | dav_path | depth_infinity_allowed | depth | http_status | + | /remote.php/dav/files/alice | 1 | 0 | 207 | + | /remote.php/dav/files/alice | 1 | infinity | 207 | + @notToImplementOnOCIS @depthInfinityPropfindDisabled + Examples: + | dav_path | depth_infinity_allowed | depth | http_status | + | /remote.php/dav/files/alice | 0 | 0 | 207 | + | /remote.php/dav/files/alice | 0 | infinity | 412 | + @skipOnOcV10 @depthInfinityPropfindEnabled + Examples: + | dav_path | depth_infinity_allowed | depth | http_status | + | /remote.php/dav/files/alice | 1 | 0 | 207 | + | /remote.php/dav/files/alice | 1 | infinity | 207 | + @skipOnOcV10 @personalSpace @depthInfinityPropfindDisabled + Examples: + | dav_path | depth_infinity_allowed | depth | http_status | + | /remote.php/dav/spaces/%spaceid% | 0 | 0 | 207 | + | /remote.php/dav/spaces/%spaceid% | 0 | infinity | 207 | + @skipOnOcV10 @personalSpace @depthInfinityPropfindEnabled + Examples: + | dav_path | depth_infinity_allowed | depth | http_status | + | /remote.php/dav/spaces/%spaceid% | 1 | 0 | 207 | + | /remote.php/dav/spaces/%spaceid% | 1 | infinity | 207 | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavOperations/refuseAccess.feature b/tests/acceptance/features/coreApiWebdavOperations/refuseAccess.feature new file mode 100644 index 00000000000..cb51ce29abe --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavOperations/refuseAccess.feature @@ -0,0 +1,41 @@ +@api +Feature: refuse access + As an administrator + I want to refuse access to unauthenticated and disabled users + So that I can secure the system + + Background: + Given using OCS API version "1" + + @smokeTest + Scenario Outline: Unauthenticated call + # cannot perform with spaces WebDAV due to the absence of user + Given using DAV path + When an unauthenticated client connects to the DAV endpoint using the WebDAV API + Then the HTTP status code should be "401" + And there should be no duplicate headers + And the following headers should be set + | header | value | + | WWW-Authenticate | Basic realm="%productname%", charset="UTF-8" | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: A disabled user cannot use webdav + Given using DAV path + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has been disabled + When user "Alice" downloads file "/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "401" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavOperations/search.feature b/tests/acceptance/features/coreApiWebdavOperations/search.feature new file mode 100644 index 00000000000..d9ffa46766b --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavOperations/search.feature @@ -0,0 +1,337 @@ +@api @issue-ocis-reva-39 +Feature: Search + As a user + I would like to be able to search for files + So that I can find needed files quickly + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/just-a-folder" + And user "Alice" has created folder "/फनी näme" + And user "Alice" has created folder "/upload folder" + And user "Alice" has created folder "/upload😀 😁" + And user "Alice" has uploaded file with content "does-not-matter" to "/upload.txt" + And user "Alice" has uploaded file with content "does-not-matter" to "/a-image.png" + And user "Alice" has uploaded file with content "does-not-matter" to "/just-a-folder/upload.txt" + And user "Alice" has uploaded file with content "does-not-matter" to "/just-a-folder/lolol.txt" + And user "Alice" has uploaded file with content "does-not-matter" to "/just-a-folder/a-image.png" + And user "Alice" has uploaded file with content "does-not-matter" to "/just-a-folder/uploadÜठिF.txt" + And user "Alice" has uploaded file with content "does-not-matter" to "/फनी näme/upload.txt" + And user "Alice" has uploaded file with content "does-not-matter" to "/फनी näme/a-image.png" + And user "Alice" has uploaded file with content "does-not-matter" to "/upload😀 😁/upload😀 😁.txt" + And user "Alice" has uploaded file with content "file with comma in filename" to "/upload😀 😁/upload,1.txt" + + @smokeTest + Scenario Outline: search for entry by pattern + Given using DAV path + When user "Alice" searches for "upload" using the WebDAV API + Then the HTTP status code should be "207" + And the search result of user "Alice" should contain these entries: + | /upload.txt | + | /just-a-folder/upload.txt | + | /upload folder | + | /just-a-folder/uploadÜठिF.txt | + | /फनी näme/upload.txt | + | /upload😀 😁 | + | /upload😀 😁/upload😀 😁.txt | + | /upload😀 😁/upload,1.txt | + But the search result of user "Alice" should not contain these entries: + | /a-image.png | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: search for entries by only some letters from the middle of the entry name + Given using DAV path + And user "Alice" has created folder "FOLDER" + When user "Alice" searches for "ol" using the WebDAV API + Then the HTTP status code should be "207" + And the search result should contain "4" entries + And the search result of user "Alice" should contain these entries: + | /just-a-folder | + | /upload folder | + | /FOLDER | + | /just-a-folder/lolol.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: search for files by extension + Given using DAV path + When user "Alice" searches for "png" using the WebDAV API + Then the HTTP status code should be "207" + And the search result of user "Alice" should contain these entries: + | /a-image.png | + | /just-a-folder/a-image.png | + | /फनी näme/a-image.png | + But the search result of user "Alice" should not contain these entries: + | /upload.txt | + | /just-a-folder/upload.txt | + | /just-a-folder/uploadÜठिF.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: search with empty field + Given using DAV path + When user "Alice" searches for "" using the WebDAV API + Then the HTTP status code should be "400" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: limit returned search entries + Given using DAV path + When user "Alice" searches for "upload" and limits the results to "3" items using the WebDAV API + Then the HTTP status code should be "207" + And the search result of user "Alice" should contain any "3" of these entries: + | /just-a-folder/upload.txt | + | /just-a-folder/uploadÜठिF.txt | + | /upload folder | + | /upload.txt | + | /फनी näme/upload.txt | + | /upload😀 😁 | + | /upload😀 😁/upload😀 😁.txt | + | /upload😀 😁/upload,1.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: limit returned search entries to only 1 entry + Given using DAV path + When user "Alice" searches for "upload" and limits the results to "1" items using the WebDAV API + Then the HTTP status code should be "207" + And the search result of user "Alice" should contain any "1" of these entries: + | /just-a-folder/upload.txt | + | /just-a-folder/uploadÜठिF.txt | + | /upload folder | + | /upload.txt | + | /फनी näme/upload.txt | + | /upload😀 😁 | + | /upload😀 😁/upload😀 😁.txt | + | /upload😀 😁/upload,1.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: limit returned search entries to more entires than there are + Given using DAV path + When user "Alice" searches for "upload" and limits the results to "100" items using the WebDAV API + Then the HTTP status code should be "207" + And the search result should contain "8" entries + And the search result of user "Alice" should contain these entries: + | /upload.txt | + | /just-a-folder/upload.txt | + | /upload folder | + | /just-a-folder/uploadÜठिF.txt | + | /फनी näme/upload.txt | + | /upload😀 😁 | + | /upload😀 😁/upload😀 😁.txt | + | /upload😀 😁/upload,1.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-4712 + Scenario Outline: report extra properties in search entries for a file + Given using DAV path + When user "Alice" searches for "upload" using the WebDAV API requesting these properties: + | oc:fileid | + | oc:permissions | + | a:getlastmodified | + | a:getetag | + | a:getcontenttype | + | oc:size | + | oc:owner-id | + | oc:owner-display-name | + Then the HTTP status code should be "207" + And file "/upload.txt" in the search result of user "Alice" should contain these properties: + | name | value | + | {http://owncloud.org/ns}fileid | \d* | + | {http://owncloud.org/ns}permissions | ^(RDNVW\|RMDNVW)$ | + | {DAV:}getlastmodified | ^[MTWFS][uedhfriatno]{2},\s(\d){2}\s[JFMAJSOND][anebrpyulgctov]{2}\s\d{4}\s\d{2}:\d{2}:\d{2} GMT$ | + | {DAV:}getetag | ^\"[a-f0-9:\.]{1,32}\"$ | + | {DAV:}getcontenttype | text\/plain | + | {http://owncloud.org/ns}size | 15 | + | {http://owncloud.org/ns}owner-id | %username% | + | {http://owncloud.org/ns}owner-display-name | %displayname% | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-4712 + Scenario Outline: report extra properties in search entries for a folder + Given using DAV path + When user "Alice" searches for "upload" using the WebDAV API requesting these properties: + | oc:fileid | + | oc:permissions | + | a:getlastmodified | + | a:getetag | + | a:getcontenttype | + | oc:size | + | oc:owner-id | + | oc:owner-display-name | + Then the HTTP status code should be "207" + And folder "/upload folder" in the search result of user "Alice" should contain these properties: + | name | value | + | {http://owncloud.org/ns}fileid | \d* | + | {http://owncloud.org/ns}permissions | ^(RDNVCK\|RMDNVCK)$ | + | {DAV:}getlastmodified | ^[MTWFS][uedhfriatno]{2},\s(\d){2}\s[JFMAJSOND][anebrpyulgctov]{2}\s\d{4}\s\d{2}:\d{2}:\d{2} GMT$ | + | {DAV:}getetag | ^\"[a-f0-9:\.]{1,32}\"$ | + | {http://owncloud.org/ns}size | 0 | + | {http://owncloud.org/ns}owner-id | %username% | + | {http://owncloud.org/ns}owner-display-name | %displayname% | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: search for entry with emoji by pattern + Given using DAV path + When user "Alice" searches for "😀 😁" using the WebDAV API + Then the HTTP status code should be "207" + And the search result of user "Alice" should contain these entries: + | /upload😀 😁 | + | /upload😀 😁/upload😀 😁.txt | + But the search result of user "Alice" should not contain these entries: + | /a-image.png | + | /upload.txt | + | /just-a-folder/upload.txt | + | /upload folder | + | /just-a-folder/uploadÜठिF.txt | + | /फनी näme/upload.txt | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario: search for entry by tags using REPORT method + Given user "Alice" has created a "normal" tag with name "JustARegularTag1" + And user "Alice" has created a "normal" tag with name "JustARegularTag2" + And user "Alice" has added tag "JustARegularTag1" to folder "फनी näme" + And user "Alice" has added tag "JustARegularTag1" to file "upload.txt" + And user "Alice" has added tag "JustARegularTag2" to file "upload.txt" + When user "Alice" searches for resources tagged with tag "JustARegularTag1" using the webDAV API + Then the HTTP status code should be "207" + And the search result by tags for user "Alice" should contain these entries: + | फनी näme | + | upload.txt | + When user "Alice" searches for resources tagged with tag "JustARegularTag2" using the webDAV API + Then the HTTP status code should be "207" + And the search result by tags for user "Alice" should contain these entries: + | upload.txt | + + + Scenario: share a tagged resource to another internal user and sharee searches for tag using REPORT method + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created a "normal" tag with name "JustARegularTag1" + And user "Alice" has created a "normal" tag with name "JustARegularTag2" + And user "Alice" has added tag "JustARegularTag1" to folder "फनी näme" + And user "Alice" has added tag "JustARegularTag1" to file "upload.txt" + And user "Alice" has added tag "JustARegularTag2" to file "upload.txt" + And user "Alice" has shared file "फनी näme" with user "Brian" + And user "Alice" has shared file "upload.txt" with user "Brian" + When user "Brian" searches for resources tagged with tag "JustARegularTag1" using the webDAV API + Then the HTTP status code should be "207" + And the search result by tags for user "Brian" should contain these entries: + | फनी näme | + | upload.txt | + When user "Brian" searches for resources tagged with tag "JustARegularTag2" using the webDAV API + Then the HTTP status code should be "207" + And the search result by tags for user "Brian" should contain these entries: + | upload.txt | + When user "Brian" searches for resources tagged with all of the following tags using the webDAV API + | JustARegularTag1 | + | JustARegularTag2 | + Then the HTTP status code should be "207" + And as user "Brian" the response should contain file "upload.txt" + And as user "Brian" the response should not contain file "फनी näme" + + + Scenario: search for entries across various folders by tags using REPORT method + Given user "Alice" has created folder "/just-a-folder/inner-folder" + And user "Alice" has uploaded file with content "inner file" to "/just-a-folder/inner-folder/upload.txt" + And user "Alice" has created a "normal" tag with name "JustARegularTag1" + And user "Alice" has created a "normal" tag with name "JustARegularTag2" + And user "Alice" has added tag "JustARegularTag1" to folder "/just-a-folder/upload.txt" + And user "Alice" has added tag "JustARegularTag1" to file "/फनी näme/upload.txt" + And user "Alice" has added tag "JustARegularTag1" to file "/just-a-folder/inner-folder/upload.txt" + And user "Alice" has added tag "JustARegularTag2" to file "/upload😀 😁/upload,1.txt" + And user "Alice" has added tag "JustARegularTag2" to file "/upload.txt" + When user "Alice" searches for resources tagged with tag "JustARegularTag1" using the webDAV API + Then the HTTP status code should be "207" + And the search result by tags for user "Alice" should contain these entries: + | upload.txt | + | upload.txt | + | upload.txt | + When user "Alice" searches for resources tagged with tag "JustARegularTag2" using the webDAV API + Then the HTTP status code should be "207" + And the search result by tags for user "Alice" should contain these entries: + | upload,1.txt | + | upload.txt | diff --git a/tests/acceptance/features/coreApiWebdavPreviews/previews.feature b/tests/acceptance/features/coreApiWebdavPreviews/previews.feature new file mode 100644 index 00000000000..b038397f8ae --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavPreviews/previews.feature @@ -0,0 +1,278 @@ +@api @preview-extension-required +Feature: previews of files downloaded through the webdav API + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: download previews with invalid width + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + When user "Alice" downloads the preview of "/parent.txt" with width "" and height "32" using the WebDAV API + Then the HTTP status code should be "400" + And the value of the item "/d:error/s:message" in the response about user "Alice" should be "Cannot set width of 0 or smaller!" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\BadRequest" + Examples: + | width | + | 0 | + | 0.5 | + | -1 | + | false | + | true | + | A | + | %2F | + + + Scenario Outline: download previews with invalid height + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + When user "Alice" downloads the preview of "/parent.txt" with width "32" and height "" using the WebDAV API + Then the HTTP status code should be "400" + And the value of the item "/d:error/s:message" in the response about user "Alice" should be "Cannot set height of 0 or smaller!" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\BadRequest" + Examples: + | height | + | 0 | + | 0.5 | + | -1 | + | false | + | true | + | A | + | %2F | + + + Scenario: download previews of files inside sub-folders + Given user "Alice" has created folder "subfolder" + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/subfolder/parent.txt" + When user "Alice" downloads the preview of "/subfolder/parent.txt" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be "32" pixels wide and "32" pixels high + + + Scenario Outline: download previews of file types that don't support preview + Given user "Alice" has uploaded file "filesForUpload/" to "/" + When user "Alice" downloads the preview of "/" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "404" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" + Examples: + | filename | newfilename | + | simple.pdf | test.pdf | + | simple.odt | test.odt | + | new-data.zip | test.zip | + + + Scenario Outline: download previews of different image file types + Given user "Alice" has uploaded file "filesForUpload/" to "/" + When user "Alice" downloads the preview of "/" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be "32" pixels wide and "32" pixels high + Examples: + | imageName | newImageName | + | testavatar.jpg | testimage.jpg | + | testavatar.png | testimage.png | + + + Scenario: download previews of image after renaming it + Given user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "/testimage.jpg" + And user "Alice" has moved file "/testimage.jpg" to "/testimage.txt" + When user "Alice" downloads the preview of "/testimage.txt" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be "32" pixels wide and "32" pixels high + + + Scenario: download previews of shared files (to shares folder) + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + And user "Alice" has shared file "/parent.txt" with user "Brian" + And user "Brian" has accepted share "/parent.txt" offered by user "Alice" + When user "Brian" downloads the preview of "/Shares/parent.txt" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be "32" pixels wide and "32" pixels high + + @notToImplementOnOCIS + Scenario: download previews of shared files (to root) + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + And user "Alice" has shared file "/parent.txt" with user "Brian" + When user "Brian" downloads the preview of "/parent.txt" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be "32" pixels wide and "32" pixels high + + + Scenario: download previews of other users files + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + When user "Brian" downloads the preview of "/parent.txt" of "Alice" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "404" + And the value of the item "/d:error/s:message" in the response about user "Alice" should be "File not found: parent.txt in '%username%'" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" + + + Scenario: download previews of folders + Given user "Alice" has created folder "subfolder" + When user "Alice" downloads the preview of "/subfolder/" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "400" + And the value of the item "/d:error/s:message" in the response about user "Alice" should be "Unsupported file type" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\BadRequest" + + + Scenario: download previews of not-existing files + When user "Alice" downloads the preview of "/parent.txt" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "404" + And the value of the item "/d:error/s:message" in the response about user "Alice" should be "File with name parent.txt could not be located" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" + + + Scenario: Download file previews when it is disabled by the administrator + Given the administrator has updated system config key "enable_previews" with value "false" and type "boolean" + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + When user "Alice" downloads the preview of "/parent.txt" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "404" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" + + + Scenario: unset maximum size of previews + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + And the administrator has updated system config key "preview_max_x" with value "null" + And the administrator has updated system config key "preview_max_y" with value "null" + When user "Alice" downloads the preview of "/parent.txt" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "404" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" + + + Scenario: download preview of size "null" + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + And the administrator has updated system config key "preview_max_x" with value "null" + And the administrator has updated system config key "preview_max_y" with value "null" + When user "Alice" downloads the preview of "/parent.txt" with width "null" and height "null" using the WebDAV API + Then the HTTP status code should be "400" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\BadRequest" + + + Scenario Outline: download previews of different size smaller than the maximum size set + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + And the administrator has updated system config key "preview_max_x" with value "32" + And the administrator has updated system config key "preview_max_y" with value "32" + When user "Alice" downloads the preview of "/parent.txt" with width "" and height "" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be "" pixels wide and "" pixels high + Examples: + | width | height | + | 32 | 32 | + | 12 | 12 | + | 32 | 12 | + | 12 | 32 | + + + Scenario Outline: download previews of different size larger than the maximum size set + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + And the administrator has updated system config key "preview_max_x" with value "32" + And the administrator has updated system config key "preview_max_y" with value "32" + When user "Alice" downloads the preview of "/parent.txt" with width "" and height "" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be "32" pixels wide and "32" pixels high + Examples: + | width | height | + | 64 | 64 | + | 2048 | 2048 | + + + Scenario: preview content changes with the change in file content + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + And user "Alice" has downloaded the preview of "/parent.txt" with width "32" and height "32" + When user "Alice" uploads file with content "this is a file to upload" to "/parent.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Alice" the preview of "/parent.txt" with width "32" and height "32" should have been changed + + @notToImplementOnOCIS + Scenario: when owner updates a shared file, previews for sharee are also updated + Given user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + And user "Alice" has shared file "/parent.txt" with user "Brian" + And user "Brian" has downloaded the preview of "/parent.txt" with width "32" and height "32" + When user "Alice" uploads file with content "this is a file to upload" to "/parent.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Brian" the preview of "/parent.txt" with width "32" and height "32" should have been changed + + @issue-ocis-2538 + Scenario: when owner updates a shared file, previews for sharee are also updated (to shared folder) + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + And user "Alice" has shared file "/parent.txt" with user "Brian" + And user "Brian" has accepted share "/parent.txt" offered by user "Alice" + And user "Brian" has downloaded the preview of "/Shares/parent.txt" with width "32" and height "32" + When user "Alice" uploads file with content "this is a file to upload" to "/parent.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Brian" the preview of "/Shares/parent.txt" with width "32" and height "32" should have been changed + + + Scenario: it should update the preview content if the file content is updated (content with UTF chars) + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "Alice" has uploaded file with content "सिमसिमे पानी" to "/lorem.txt" + When user "Alice" downloads the preview of "/lorem.txt" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be "32" pixels wide and "32" pixels high + And the downloaded preview content should match with "सिमसिमे-पानी.png" fixtures preview content + + + Scenario: updates to a file should change the preview for both sharees and sharers + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "FOLDER" + And user "Alice" has uploaded file with content "file to upload" to "/FOLDER/lorem.txt" + And user "Alice" has shared folder "FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And user "Alice" has downloaded the preview of "/FOLDER/lorem.txt" with width "32" and height "32" + And user "Brian" has downloaded the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" + When user "Alice" uploads file "filesForUpload/lorem.txt" to "/FOLDER/lorem.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Alice" the preview of "/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + And as user "Brian" the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + When user "Brian" uploads file with content "new uploaded content" to "Shares/FOLDER/lorem.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Alice" the preview of "/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + And as user "Brian" the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + + + Scenario: updates to a group shared file should change the preview for both sharees and sharers + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And group "grp1" has been created + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp1" + And user "Alice" has created folder "FOLDER" + And user "Alice" has uploaded file with content "file to upload" to "/FOLDER/lorem.txt" + And user "Alice" has shared folder "/FOLDER" with group "grp1" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And user "Carol" has accepted share "/FOLDER" offered by user "Alice" + And user "Alice" has downloaded the preview of "/FOLDER/lorem.txt" with width "32" and height "32" + And user "Brian" has downloaded the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" + And user "Carol" has downloaded the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" + When user "Alice" uploads file "filesForUpload/lorem.txt" to "/FOLDER/lorem.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Alice" the preview of "/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + And as user "Brian" the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + And as user "Carol" the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + When user "Brian" uploads file with content "new uploaded content" to "Shares/FOLDER/lorem.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as user "Alice" the preview of "/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + And as user "Brian" the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + And as user "Carol" the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" should have been changed + + @notToImplementOnOCIS + Scenario: JPEG preview quality can be determined by config + Given user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "/testavatar_low.jpg" + And the administrator has updated system config key "previewJPEGImageDisplayQuality" with value "1" + And user "Alice" downloads the preview of "/testavatar_low.jpg" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "200" + And the requested JPEG image should have a quality value of "1" + Then user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "/testavatar_high.jpg" + And the administrator has updated system config key "previewJPEGImageDisplayQuality" with value "100" + And user "Alice" downloads the preview of "/testavatar_high.jpg" with width "32" and height "32" using the WebDAV API + Then the HTTP status code should be "200" + And the requested JPEG image should have a quality value of "100" diff --git a/tests/acceptance/features/coreApiWebdavPreviews/previewsAutoAdustedSizing.feature b/tests/acceptance/features/coreApiWebdavPreviews/previewsAutoAdustedSizing.feature new file mode 100644 index 00000000000..1246c1e91de --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavPreviews/previewsAutoAdustedSizing.feature @@ -0,0 +1,25 @@ +@api @preview-extension-required +Feature: sizing of previews of files downloaded through the webdav API + As a user + I want the aspect-ratio of previews to be preserved even when I ask for an unusual preview size + So that the previews always have a similar look-and-feel to the original file + + This is optional behavior of an implementation. OCIS happens like this, + but oC10 does not do this auto-fix of the aspect ratio. + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @skipOnOcV10 + Scenario Outline: download different sizes of previews of file + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + When user "Alice" downloads the preview of "/parent.txt" with width and height using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be pixels wide and pixels high + Examples: + | request_width | request_height | return_width | return_height | + | 1 | 1 | 16 | 16 | + | 32 | 32 | 32 | 32 | + | 1024 | 1024 | 640 | 480 | + | 1 | 1024 | 16 | 16 | + | 1024 | 1 | 640 | 480 | diff --git a/tests/acceptance/features/coreApiWebdavPreviews/previewsExactSizing.feature b/tests/acceptance/features/coreApiWebdavPreviews/previewsExactSizing.feature new file mode 100644 index 00000000000..f113a170b79 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavPreviews/previewsExactSizing.feature @@ -0,0 +1,25 @@ +@api @preview-extension-required +Feature: sizing of previews of files downloaded through the webdav API + As a user + I want previews to be the exact requested size even when I ask for an unusual preview size combination + So that the previews always have the exact size that I want as a user/client. + + This is optional behavior of an implementation. oC10 happens like this, + but OCIS does an auto-fix of the aspect ratio. + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + @skipOnOcis + Scenario Outline: download different sizes of previews of file + Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" + When user "Alice" downloads the preview of "/parent.txt" with width and height using the WebDAV API + Then the HTTP status code should be "200" + And the downloaded image should be pixels wide and pixels high + Examples: + | width | height | + | 1 | 1 | + | 32 | 32 | + | 1024 | 1024 | + | 1 | 1024 | + | 1024 | 1 | diff --git a/tests/acceptance/features/coreApiWebdavProperties1/copyFile.feature b/tests/acceptance/features/coreApiWebdavProperties1/copyFile.feature new file mode 100644 index 00000000000..72ce580e532 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavProperties1/copyFile.feature @@ -0,0 +1,887 @@ +@api +Feature: copy file + As a user + I want to be able to copy files + So that I can manage my files + + Background: + Given using OCS API version "1" + And the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has uploaded file with content "ownCloud test text file 1" to "/textfile1.txt" + And user "Alice" has created folder "/FOLDER" + + @smokeTest + Scenario Outline: Copying a file + Given using DAV path + When user "Alice" copies file "/textfile0.txt" to "/FOLDER/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/FOLDER/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest + Scenario Outline: Copying and overwriting a file + Given using DAV path + When user "Alice" copies file "/textfile0.txt" to "/textfile1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textfile1.txt" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Copying a file when 2 files exist with different case + Given using DAV path + # "/textfile1.txt" already exists in the skeleton, make another with only case differences in the file name + When user "Alice" copies file "/textfile0.txt" to "/TextFile1.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/textfile1.txt" for user "Alice" should be "ownCloud test text file 1" + And the content of file "/TextFile1.txt" for user "Alice" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @issue-ocis-reva-11 + Scenario Outline: Copying a file to a folder with no permissions + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | read | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Alice" copies file "/textfile0.txt" to "/Shares/testshare/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "403" + And user "Alice" should not be able to download file "/Shares/testshare/textfile0.txt" + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required @issue-ocis-reva-11 + Scenario Outline: Copying a file to overwrite a file into a folder with no permissions + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "ownCloud test text file 1" to "textfile1.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | read | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + And user "Brian" has copied file "textfile1.txt" to "/testshare/overwritethis.txt" + When user "Alice" copies file "/textfile0.txt" to "/Shares/testshare/overwritethis.txt" using the WebDAV API + Then the HTTP status code should be "403" + And the content of file "/Shares/testshare/overwritethis.txt" for user "Alice" should be "ownCloud test text file 1" + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-reva-15 + Scenario Outline: Copying file to a path with extension .part should not be possible + Given using DAV path + When user "Alice" copies file "/textfile1.txt" to "/textfile1.part" using the WebDAV API + Then the HTTP status code should be "400" + And the DAV exception should be "OCA\DAV\Connector\Sabre\Exception\InvalidPath" + And the DAV message should be "Can`t upload files with extension .part because these extensions are reserved for internal use." + And the DAV reason should be "Can`t upload files with extension .part because these extensions are reserved for internal use." + And user "Alice" should see the following elements + | /textfile1.txt | + But user "Alice" should not see the following elements + | /textfile1.part | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-387 + Scenario Outline: copy a file over the top of an existing folder + Given using DAV path + And user "Alice" has created folder "FOLDER/sample-folder" + When user "Alice" copies file "/textfile1.txt" to "/FOLDER" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/FOLDER" for user "Alice" should be "ownCloud test text file 1" + And as "Alice" folder "/FOLDER/sample-folder" should not exist + And as "Alice" file "/textfile1.txt" should exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-387 + Scenario Outline: copy a folder over the top of an existing file + Given using DAV path + And user "Alice" has created folder "FOLDER/sample-folder" + When user "Alice" copies folder "/FOLDER" to "/textfile1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/FOLDER/sample-folder" should exist + And as "Alice" folder "/textfile1.txt/sample-folder" should exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-387 + Scenario Outline: copy a folder into another folder at different level + Given using DAV path + And user "Alice" has created folder "FOLDER/second-level-folder" + And user "Alice" has created folder "FOLDER/second-level-folder/third-level-folder" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b/sample-folder-c" + When user "Alice" copies folder "Sample-Folder-A/sample-folder-b" to "FOLDER/second-level-folder/third-level-folder" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/Sample-Folder-A/sample-folder-b/sample-folder-c" should exist + And as "Alice" folder "/FOLDER/second-level-folder/third-level-folder/sample-folder-c" should exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-387 + Scenario Outline: copy a file into a folder at different level + Given using DAV path + And user "Alice" has created folder "FOLDER/second-level-folder" + And user "Alice" has created folder "FOLDER/second-level-folder/third-level-folder" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has uploaded file with content "sample file-c" to "Sample-Folder-A/sample-folder-b/textfile-c.txt" + When user "Alice" copies file "Sample-Folder-A/sample-folder-b/textfile-c.txt" to "FOLDER/second-level-folder" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "FOLDER/second-level-folder/third-level-folder" should not exist + And as "Alice" file "Sample-Folder-A/sample-folder-b/textfile-c.txt" should exist + And as "Alice" file "FOLDER/second-level-folder" should exist + And the content of file "FOLDER/second-level-folder" for user "Alice" should be "sample file-c" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-387 + Scenario Outline: copy a file into a file at different level + Given using DAV path + And user "Alice" has uploaded file with content "file at second level" to "FOLDER/second-level-file.txt" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has uploaded file with content "sample file-c" to "Sample-Folder-A/sample-folder-b/textfile-c.txt" + When user "Alice" copies file "Sample-Folder-A/sample-folder-b/textfile-c.txt" to "FOLDER/second-level-file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "Sample-Folder-A/sample-folder-b/textfile-c.txt" should exist + And as "Alice" file "FOLDER/second-level-file.txt" should exist + And as "Alice" file "FOLDER/textfile-c.txt" should not exist + And the content of file "FOLDER/second-level-file.txt" for user "Alice" should be "sample file-c" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-387 + Scenario Outline: copy a folder into a file at different level + Given using DAV path + And user "Alice" has created folder "FOLDER/second-level-folder" + And user "Alice" has created folder "FOLDER/second-level-folder/third-level-folder" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has uploaded file with content "sample file-c" to "Sample-Folder-A/sample-folder-b/textfile-c.txt" + When user "Alice" copies folder "FOLDER/second-level-folder" to "Sample-Folder-A/sample-folder-b/textfile-c.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "Sample-Folder-A/sample-folder-b/textfile-c.txt" should exist + And as "Alice" folder "FOLDER/second-level-folder/third-level-folder" should exist + And as "Alice" folder "Sample-Folder-A/sample-folder-b/textfile-c.txt/third-level-folder" should exist + And as "Alice" folder "Sample-Folder-A/sample-folder-b/second-level-folder" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-1239 + Scenario Outline: copy a file over the top of an existing folder received as a user share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/BRIAN-Folder" + And user "Brian" has created folder "BRIAN-Folder/sample-folder" + And user "Brian" has shared folder "BRIAN-Folder" with user "Alice" + And user "Alice" has accepted share "/BRIAN-Folder" offered by user "Brian" + When user "Alice" copies file "/textfile1.txt" to "/Shares/BRIAN-Folder" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/Shares/BRIAN-Folder" for user "Alice" should be "ownCloud test text file 1" + And as "Alice" folder "/Shares/BRIAN-Folder/sample-folder" should not exist + And as "Alice" file "/textfile1.txt" should exist + And user "Alice" should not have any received shares + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-1239 + Scenario Outline: copy a folder over the top of an existing file received as a user share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has uploaded file with content "file to share" to "/sharedfile1.txt" + And user "Brian" has shared file "/sharedfile1.txt" with user "Alice" + And user "Alice" has accepted share "/sharedfile1.txt" offered by user "Brian" + And user "Alice" has created folder "FOLDER/sample-folder" + When user "Alice" copies folder "/FOLDER" to "/Shares/sharedfile1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/FOLDER/sample-folder" should exist + And as "Alice" folder "/Shares/sharedfile1.txt/sample-folder" should exist + And user "Alice" should not have any received shares + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-1239 + Scenario Outline: copy a folder into another folder at different level which is received as a user share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "BRIAN-FOLDER" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder/third-level-folder" + And user "Brian" has shared folder "BRIAN-FOLDER" with user "Alice" + And user "Alice" has accepted share "/BRIAN-FOLDER" offered by user "Brian" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b/sample-folder-c" + When user "Alice" copies folder "Sample-Folder-A/sample-folder-b" to "Shares/BRIAN-FOLDER/second-level-folder/third-level-folder" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/Sample-Folder-A/sample-folder-b/sample-folder-c" should exist + And as "Alice" folder "/Shares/BRIAN-FOLDER/second-level-folder/third-level-folder/sample-folder-c" should exist + And the response when user "Alice" gets the info of the last share should include + | file_target | /Shares/BRIAN-FOLDER | + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-1239 + Scenario Outline: copy a file into a folder at different level received as a user share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "BRIAN-FOLDER" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder/third-level-folder" + And user "Brian" has shared folder "BRIAN-FOLDER" with user "Alice" + And user "Alice" has accepted share "/BRIAN-FOLDER" offered by user "Brian" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has uploaded file with content "sample file-c" to "Sample-Folder-A/sample-folder-b/textfile-c.txt" + When user "Alice" copies file "Sample-Folder-A/sample-folder-b/textfile-c.txt" to "Shares/BRIAN-FOLDER/second-level-folder" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "Shares/BRIAN-FOLDER/second-level-folder/third-level-folder" should not exist + And as "Alice" file "Sample-Folder-A/sample-folder-b/textfile-c.txt" should exist + And as "Alice" file "Shares/BRIAN-FOLDER/second-level-folder" should exist + And the content of file "Shares/BRIAN-FOLDER/second-level-folder" for user "Alice" should be "sample file-c" + And the response when user "Alice" gets the info of the last share should include + | file_target | /Shares/BRIAN-FOLDER | + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-1239 + Scenario Outline: copy a file into a file at different level received as a user share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "BRIAN-FOLDER" + And user "Brian" has uploaded file with content "file at second level" to "BRIAN-FOLDER/second-level-file.txt" + And user "Brian" has shared folder "BRIAN-FOLDER" with user "Alice" + And user "Alice" has accepted share "/BRIAN-FOLDER" offered by user "Brian" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has uploaded file with content "sample file-c" to "Sample-Folder-A/sample-folder-b/textfile-c.txt" + When user "Alice" copies file "Sample-Folder-A/sample-folder-b/textfile-c.txt" to "Shares/BRIAN-FOLDER/second-level-file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "Sample-Folder-A/sample-folder-b/textfile-c.txt" should exist + And as "Alice" file "Shares/BRIAN-FOLDER/second-level-file.txt" should exist + And as "Alice" file "Shares/BRIAN-FOLDER/textfile-c.txt" should not exist + And the content of file "Shares/BRIAN-FOLDER/second-level-file.txt" for user "Alice" should be "sample file-c" + And the response when user "Alice" gets the info of the last share should include + | file_target | /Shares/BRIAN-FOLDER | + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-1239 + Scenario Outline: copy a folder into a file at different level received as a user share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "BRIAN-FOLDER" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder" + And user "Brian" has uploaded file with content "file at third level" to "BRIAN-FOLDER/second-level-folder/third-level-file.txt" + And user "Brian" has shared folder "BRIAN-FOLDER" with user "Alice" + And user "Alice" has accepted share "/BRIAN-FOLDER" offered by user "Brian" + And user "Alice" has created folder "FOLDER/second-level-folder" + And user "Alice" has created folder "FOLDER/second-level-folder/third-level-folder" + When user "Alice" copies folder "FOLDER/second-level-folder" to "/Shares/BRIAN-FOLDER/second-level-folder/third-level-file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "Shares/BRIAN-FOLDER/second-level-folder/third-level-file.txt" should exist + And as "Alice" folder "FOLDER/second-level-folder/third-level-folder" should exist + And as "Alice" folder "Shares/BRIAN-FOLDER/second-level-folder/third-level-file.txt/third-level-folder" should exist + And as "Alice" folder "Shares/BRIAN-FOLDER/second-level-folder/second-level-folder" should not exist + And the response when user "Alice" gets the info of the last share should include + | file_target | /Shares/BRIAN-FOLDER | + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-1239 + Scenario Outline: copy a file over the top of an existing folder received as a group share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Brian" has created folder "/BRIAN-Folder" + And user "Brian" has created folder "BRIAN-Folder/sample-folder" + And user "Brian" has shared folder "BRIAN-Folder" with group "grp1" with permissions "15" + And user "Alice" has accepted share "/BRIAN-Folder" offered by user "Brian" + When user "Alice" copies file "/textfile1.txt" to "/Shares/BRIAN-Folder" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/Shares/BRIAN-Folder" for user "Alice" should be "ownCloud test text file 1" + And as "Alice" folder "/Shares/BRIAN-Folder/sample-folder" should not exist + And as "Alice" file "/textfile1.txt" should exist + And user "Alice" should not have any received shares + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-1239 + Scenario Outline: copy a folder over the top of an existing file received as a group share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Brian" has uploaded file with content "file to share" to "/sharedfile1.txt" + And user "Brian" has shared file "/sharedfile1.txt" with group "grp1" + And user "Alice" has accepted share "/sharedfile1.txt" offered by user "Brian" + And user "Alice" has created folder "FOLDER/sample-folder" + When user "Alice" copies folder "/FOLDER" to "/Shares/sharedfile1.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/FOLDER/sample-folder" should exist + And as "Alice" folder "/Shares/sharedfile1.txt/sample-folder" should exist + And user "Alice" should not have any received shares + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-1239 + Scenario Outline: copy a folder into another folder at different level which is received as a group share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Brian" has created folder "BRIAN-FOLDER" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder/third-level-folder" + And user "Brian" has shared folder "BRIAN-FOLDER" with group "grp1" + And user "Alice" has accepted share "/BRIAN-FOLDER" offered by user "Brian" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b/sample-folder-c" + When user "Alice" copies folder "Sample-Folder-A/sample-folder-b" to "Shares/BRIAN-FOLDER/second-level-folder/third-level-folder" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "/Sample-Folder-A/sample-folder-b/sample-folder-c" should exist + And as "Alice" folder "/Shares/BRIAN-FOLDER/second-level-folder/third-level-folder/sample-folder-c" should exist + And the response when user "Alice" gets the info of the last share should include + | file_target | /Shares/BRIAN-FOLDER | + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-1239 + Scenario Outline: copy a file into a folder at different level received as a group share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Brian" has created folder "BRIAN-FOLDER" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder/third-level-folder" + And user "Brian" has shared folder "BRIAN-FOLDER" with group "grp1" + And user "Alice" has accepted share "/BRIAN-FOLDER" offered by user "Brian" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has uploaded file with content "sample file-c" to "Sample-Folder-A/sample-folder-b/textfile-c.txt" + When user "Alice" copies file "Sample-Folder-A/sample-folder-b/textfile-c.txt" to "Shares/BRIAN-FOLDER/second-level-folder" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "Shares/BRIAN-FOLDER/second-level-folder/third-level-folder" should not exist + And as "Alice" file "Sample-Folder-A/sample-folder-b/textfile-c.txt" should exist + And as "Alice" file "Shares/BRIAN-FOLDER/second-level-folder" should exist + And the content of file "Shares/BRIAN-FOLDER/second-level-folder" for user "Alice" should be "sample file-c" + And the response when user "Alice" gets the info of the last share should include + | file_target | /Shares/BRIAN-FOLDER | + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-1239 + Scenario Outline: copy a file into a file at different level received as a group share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Brian" has created folder "BRIAN-FOLDER" + And user "Brian" has uploaded file with content "file at second level" to "BRIAN-FOLDER/second-level-file.txt" + And user "Brian" has shared folder "BRIAN-FOLDER" with group "grp1" + And user "Alice" has accepted share "/BRIAN-FOLDER" offered by user "Brian" + And user "Alice" has created folder "Sample-Folder-A" + And user "Alice" has created folder "Sample-Folder-A/sample-folder-b" + And user "Alice" has uploaded file with content "sample file-c" to "Sample-Folder-A/sample-folder-b/textfile-c.txt" + When user "Alice" copies file "Sample-Folder-A/sample-folder-b/textfile-c.txt" to "Shares/BRIAN-FOLDER/second-level-file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "Sample-Folder-A/sample-folder-b/textfile-c.txt" should exist + And as "Alice" file "Shares/BRIAN-FOLDER/second-level-file.txt" should exist + And as "Alice" file "Shares/BRIAN-FOLDER/textfile-c.txt" should not exist + And the content of file "Shares/BRIAN-FOLDER/second-level-file.txt" for user "Alice" should be "sample file-c" + And the response when user "Alice" gets the info of the last share should include + | file_target | /Shares/BRIAN-FOLDER | + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-1239 + Scenario Outline: copy a folder into a file at different level received as a group share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has been added to group "grp1" + And user "Brian" has been added to group "grp1" + And user "Brian" has created folder "BRIAN-FOLDER" + And user "Brian" has created folder "BRIAN-FOLDER/second-level-folder" + And user "Brian" has uploaded file with content "file at third level" to "BRIAN-FOLDER/second-level-folder/third-level-file.txt" + And user "Brian" has shared folder "BRIAN-FOLDER" with group "grp1" + And user "Alice" has accepted share "/BRIAN-FOLDER" offered by user "Brian" + And user "Alice" has created folder "FOLDER/second-level-folder" + And user "Alice" has created folder "FOLDER/second-level-folder/third-level-folder" + When user "Alice" copies folder "FOLDER/second-level-folder" to "Shares/BRIAN-FOLDER/second-level-folder/third-level-file.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" folder "Shares/BRIAN-FOLDER/second-level-folder/third-level-file.txt" should exist + And as "Alice" folder "FOLDER/second-level-folder/third-level-folder" should exist + And as "Alice" folder "Shares/BRIAN-FOLDER/second-level-folder/third-level-file.txt/third-level-folder" should exist + And as "Alice" folder "Shares/BRIAN-FOLDER/second-level-folder/second-level-folder" should not exist + And the response when user "Alice" gets the info of the last share should include + | file_target | /Shares/BRIAN-FOLDER | + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: copy a file of size zero byte + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/zerobyte.txt" to "/zerobyte.txt" + And user "Alice" has created folder "/testZeroByte" + When user "Alice" copies file "/zerobyte.txt" to "/testZeroByte/zerobyte.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/testZeroByte/zerobyte.txt" should exist + And as "Alice" file "/zerobyte.txt" should exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Copy file into a nonexistent folder + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToCopy.txt" + When user "Alice" copies file "/fileToCopy.txt" to "/not-existing-folder/fileToCopy.txt" using the WebDAV API + Then the HTTP status code should be "409" + And as "Alice" file "/fileToCopy.txt" should exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Copy a nonexistent file into a folder + Given using DAV path + When user "Alice" copies file "/doesNotExist.txt" to "/FOLDER/doesNotExist.txt" using the WebDAV API + Then the HTTP status code should be "404" + And as "Alice" file "/FOLDER/doesNotExist.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Copy a folder into a nonexistent one + Given using DAV path + And user "Alice" has created folder "/testshare" + When user "Alice" copies folder "/testshare" to "/not-existing/testshare" using the WebDAV API + Then the HTTP status code should be "409" + And user "Alice" should see the following elements + | /testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required + Scenario Outline: Copying a file into a shared folder as the sharee + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Alice" copies file "/textfile0.txt" to "/Shares/testshare/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/Shares/testshare/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + And the content of file "/testshare/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required + Scenario Outline: Copying a file into a shared folder as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Brian" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Brian" copies file "/textfile0.txt" to "/testshare/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/Shares/testshare/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" + And the content of file "/testshare/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required + Scenario Outline: Copying a file out of a shared folder as the sharee + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + And user "Alice" has uploaded file with content "ownCloud test text file inside share" to "/Shares/testshare/fileInsideShare.txt" + When user "Alice" copies file "/Shares/testshare/fileInsideShare.txt" to "/fileInsideShare.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/fileInsideShare.txt" should exist + And the content of file "/fileInsideShare.txt" for user "Alice" should be "ownCloud test text file inside share" + And the content of file "/testshare/fileInsideShare.txt" for user "Brian" should be "ownCloud test text file inside share" + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required + Scenario Outline: Copying a file out of a shared folder as the sharer + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare" + And user "Brian" has uploaded file with content "ownCloud test text file inside share" to "/testshare/fileInsideShare.txt" + And user "Brian" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare" offered by user "Brian" + When user "Brian" copies file "testshare/fileInsideShare.txt" to "/fileInsideShare.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/fileInsideShare.txt" should exist + And the content of file "/Shares/testshare/fileInsideShare.txt" for user "Alice" should be "ownCloud test text file inside share" + And the content of file "/fileInsideShare.txt" for user "Brian" should be "ownCloud test text file inside share" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Copying a hidden file + Given using DAV path + And user "Alice" has uploaded the following files with content "hidden file" + | path | + | .hidden_file101 | + | /FOLDER/.hidden_file102 | + When user "Alice" copies file ".hidden_file101" to "/FOLDER/.hidden_file101" using the WebDAV API + And user "Alice" copies file "/FOLDER/.hidden_file102" to ".hidden_file102" using the WebDAV API + And as "Alice" the following files should exist + | path | + | .hidden_file102 | + | /FOLDER/.hidden_file101 | + And the content of the following files for user "Alice" should be "hidden file" + | path | + | .hidden_file102 | + | /FOLDER/.hidden_file101 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required + Scenario Outline: Copying a file between shares received from different users + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare0" + And user "Brian" has uploaded file with content "content inside testshare0" to "/testshare0/testshare0.txt" + And user "Carol" has created folder "/testshare1" + And user "Brian" has created a share with settings + | path | testshare0 | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Carol" has created a share with settings + | path | testshare1 | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare0" offered by user "Brian" + And user "Alice" has accepted share "/testshare1" offered by user "Carol" + When user "Alice" copies file "/Shares/testshare0/testshare0.txt" to "/Shares/testshare1/testshare0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Carol" file "testshare1/testshare0.txt" should exist + And as "Alice" file "Shares/testshare1/testshare0.txt" should exist + And the content of file "/testshare1/testshare0.txt" for user "Carol" should be "content inside testshare0" + And the content of file "/Shares/testshare1/testshare0.txt" for user "Alice" should be "content inside testshare0" + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required + Scenario Outline: Copying a folder between shares received from different users + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And user "Brian" has created folder "/testshare0" + And user "Brian" has created folder "/testshare0/folder_to_copy/" + And user "Brian" has uploaded file with content "content inside testshare0" to "/testshare0/folder_to_copy/testshare0.txt" + And user "Carol" has created folder "/testshare1" + And user "Brian" has created a share with settings + | path | testshare0 | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Carol" has created a share with settings + | path | testshare1 | + | shareType | user | + | permissions | change | + | shareWith | Alice | + And user "Alice" has accepted share "/testshare0" offered by user "Brian" + And user "Alice" has accepted share "/testshare1" offered by user "Carol" + When user "Alice" copies file "/Shares/testshare0/folder_to_copy/" to "/Shares/testshare1/folder_to_copy/" using the WebDAV API + Then the HTTP status code should be "201" + And as "Carol" file "testshare1/folder_to_copy/testshare0.txt" should exist + And as "Alice" file "/Shares/testshare1/folder_to_copy/testshare0.txt" should exist + And the content of file "testshare1/folder_to_copy/testshare0.txt" for user "Carol" should be "content inside testshare0" + And the content of file "/Shares/testshare1/folder_to_copy/testshare0.txt" for user "Alice" should be "content inside testshare0" + Examples: + | dav_version | + | old | + | new | + + @files_sharing-app-required + Scenario Outline: Copying a file to a folder that is shared with multiple users + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/testshare" + And user "Alice" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Brian | + And user "Brian" has accepted share "/testshare" offered by user "Alice" + And user "Alice" has created a share with settings + | path | testshare | + | shareType | user | + | permissions | change | + | shareWith | Carol | + And user "Carol" has accepted share "/testshare" offered by user "Alice" + When user "Alice" copies file "/textfile0.txt" to "/testshare/textfile0.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" file "/Shares/testshare/textfile0.txt" should exist + And as "Carol" file "/Shares/testshare/textfile0.txt" should exist + And the content of file "/Shares/testshare/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" + And the content of file "/Shares/testshare/textfile0.txt" for user "Carol" should be "ownCloud test text file 0" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Copy a folder into another one + Given using DAV path + And user "Alice" has created folder "/testshare" + And user "Alice" has created folder "/an-other-folder" + When user "Alice" copies folder "/testshare" to "/an-other-folder/testshare" using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" should see the following elements + | /testshare/ | + And user "Alice" should see the following elements + | /an-other-folder/testshare/ | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-3023 + Scenario Outline: Copying a folder into a sub-folder of itself + Given using DAV path + And user "Alice" has created folder "/PARENT" + And user "Alice" has created folder "/PARENT/CHILD" + And user "Alice" has uploaded file with content "parent text" to "/PARENT/parent.txt" + And user "Alice" has uploaded file with content "child text" to "/PARENT/CHILD/child.txt" + When user "Alice" copies folder "/PARENT" to "/PARENT/CHILD/PARENT" using the WebDAV API + Then the HTTP status code should be "409" + And the content of file "/PARENT/parent.txt" for user "Alice" should be "parent text" + And the content of file "/PARENT/CHILD/child.txt" for user "Alice" should be "child text" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Copying a folder with a file into another folder + Given using DAV path + And user "Alice" has created folder "/FOLDER1" + And user "Alice" has created folder "/FOLDER2" + And user "Alice" has uploaded file with content "Folder 1 text" to "/FOLDER1/textfile.txt" + When user "Alice" copies folder "/FOLDER1" to "/FOLDER2/FOLDER1" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" folder "/FOLDER2/FOLDER1" should exist + And as "Alice" file "/FOLDER2/FOLDER1/textfile.txt" should exist + And as "Alice" folder "/FOLDER1" should exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavProperties1/createFileFolder.feature b/tests/acceptance/features/coreApiWebdavProperties1/createFileFolder.feature new file mode 100644 index 00000000000..16d8504f3cb --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavProperties1/createFileFolder.feature @@ -0,0 +1,180 @@ +@api +Feature: create files and folder + As a user + I want to be able to create files and folders + So that I can organise the files in my file system + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @issue-ocis-reva-269 + Scenario Outline: create a folder + Given using DAV path + When user "Alice" creates folder "" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" folder "" should exist + Examples: + | dav_version | folder_name | + | old | /upload | + | old | /strängé folder | + | old | /C++ folder.cpp | + | old | /नेपाली | + | old | /folder #2 | + | old | /folder ?2 | + | old | /😀 🤖 | + | old | /new&folder | + | new | /upload | + | new | /strängé folder | + | new | /C++ folder.cpp | + | new | /नेपाली | + | new | /folder #2 | + | new | /folder ?2 | + | new | /😀 🤖 | + | new | /new&folder | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | + | spaces | /upload | + | spaces | /strängé folder | + | spaces | /C++ folder.cpp | + | spaces | /नेपाली | + | spaces | /folder #2 | + | spaces | /folder ?2 | + | spaces | /😀 🤖 | + | spaces | /new&folder | + + @smokeTest + Scenario Outline: Creating a folder + Given using DAV path + And user "Alice" has created folder "/test_folder" + When user "Alice" gets the following properties of folder "/test_folder" using the WebDAV API + | propertyName | + | d:resourcetype | + Then the HTTP status code should be "201" + And the single response should contain a property "d:resourcetype" with a child property "d:collection" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Creating a folder with special chars + Given using DAV path + And user "Alice" has created folder "/test_folder:5" + When user "Alice" gets the following properties of folder "/test_folder:5" using the WebDAV API + | propertyName | + | d:resourcetype | + Then the HTTP status code should be "201" + And the single response should contain a property "d:resourcetype" with a child property "d:collection" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-15 + Scenario Outline: Creating a directory which contains .part should not be possible + Given using DAV path + When user "Alice" creates folder "/folder.with.ext.part" using the WebDAV API + Then the HTTP status code should be "400" + And the DAV exception should be "OCA\DAV\Connector\Sabre\Exception\InvalidPath" + And the DAV message should be "Can`t upload files with extension .part because these extensions are reserved for internal use." + And the DAV reason should be "Can`t upload files with extension .part because these extensions are reserved for internal use." + And user "Alice" should not see the following elements + | /folder.with.ext.part | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-168 + Scenario Outline: try to create a folder that already exists + Given using DAV path + And user "Alice" has created folder "my-data" + When user "Alice" creates folder "my-data" using the WebDAV API + Then the HTTP status code should be "405" + And as "Alice" folder "my-data" should exist + And the DAV exception should be "Sabre\DAV\Exception\MethodNotAllowed" + And the DAV message should be "The resource you tried to create already exists" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-168 + Scenario Outline: try to create a folder with a name of an existing file + Given using DAV path + And user "Alice" has uploaded file with content "uploaded data" to "/my-data.txt" + When user "Alice" creates folder "my-data.txt" using the WebDAV API + Then the HTTP status code should be "405" + And the DAV exception should be "Sabre\DAV\Exception\MethodNotAllowed" + And the DAV message should be "The resource you tried to create already exists" + And the content of file "/my-data.txt" for user "Alice" should be "uploaded data" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Create a file + Given using DAV path + When user "Alice" uploads file with content "some text" to "" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "" should exist + And the content of file "" for user "Alice" should be "some text" + Examples: + | dav_version | file_name | + | old | /upload.txt | + | old | /strängéfile.txt | + | old | /C++ file.cpp | + | old | /नेपाली | + | old | /file #2.txt | + | old | /file ?2.pdf | + | old | /😀 🤖.txt | + | old | /new&file.txt | + | new | /upload.txt | + | new | /strängéfile.txt | + | new | /C++ file.cpp | + | new | /नेपाली | + | new | /file #2.txt | + | new | /file ?2.pdf | + | new | /😀 🤖.txt | + | new | /new&file.txt | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | file_name | + | spaces | /upload.txt | + | spaces | /strängéfile.txt | + | spaces | /C++ file.cpp | + | spaces | /नेपाली | + | spaces | /file #2.txt | + | spaces | /file ?2.pdf | + | spaces | /😀 🤖.txt | + | spaces | /new&file.txt | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavProperties1/createFileFolderWhenSharesExist.feature b/tests/acceptance/features/coreApiWebdavProperties1/createFileFolderWhenSharesExist.feature new file mode 100644 index 00000000000..39460125c73 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavProperties1/createFileFolderWhenSharesExist.feature @@ -0,0 +1,72 @@ +@api +Feature: create file or folder named similar to Shares folder + As a user + I want to be able to create files and folders when the Shares folder exists + So that I can organise the files in my file system + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,update" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + + + Scenario Outline: create a folder with a name similar to Shares + Given using DAV path + When user "Brian" creates folder "" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "" should exist + And as "Brian" folder "/Shares" should exist + Examples: + | dav_version | folder_name | + | old | /Share | + | old | /shares | + | old | /Shares1 | + | new | /Share | + | new | /shares | + | new | /Shares1 | + + + Scenario Outline: create a file with a name similar to Shares + Given using DAV path + When user "Brian" uploads file with content "some text" to "" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "" for user "Brian" should be "some text" + And as "Brian" folder "/Shares" should exist + Examples: + | dav_version | file_name | + | old | /Share | + | old | /shares | + | old | /Shares1 | + | new | /Share | + | new | /shares | + | new | /Shares1 | + + + Scenario Outline: try to create a folder named Shares + Given using DAV path + When user "Brian" creates folder "/Shares" using the WebDAV API + Then the HTTP status code should be "405" + And as "Brian" folder "/Shares" should exist + And as "Brian" folder "/Shares/FOLDER" should exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: try to create a file named Shares + Given using DAV path + When user "Brian" uploads file with content "some text" to "/Shares" using the WebDAV API + Then the HTTP status code should be "409" + And as "Brian" folder "/Shares" should exist + And as "Brian" folder "/Shares/FOLDER" should exist + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/coreApiWebdavProperties1/getQuota.feature b/tests/acceptance/features/coreApiWebdavProperties1/getQuota.feature new file mode 100644 index 00000000000..652a4e9748f --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavProperties1/getQuota.feature @@ -0,0 +1,110 @@ +@api @issue-ocis-reva-101 @skipOnGraph +Feature: get quota + As a user + I want to be able to find out my available storage quota + So that I can manage the use of my allocated storage + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and small skeleton files + + + Scenario Outline: Retrieving folder quota when no quota is set + Given using DAV path + When the administrator gives unlimited quota to user "Alice" using the provisioning API + Then the HTTP status code should be "200" + And as user "Alice" folder "/" should contain a property "d:quota-available-bytes" with value "-3" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest + Scenario Outline: Retrieving folder quota when quota is set + Given using DAV path + When the administrator sets the quota of user "Alice" to "10 MB" using the provisioning API + Then the HTTP status code should be "200" + And as user "Alice" folder "/" should contain a property "d:quota-available-bytes" with value "10485406" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required + Scenario Outline: Retrieving folder quota of shared folder with quota when no quota is set for recipient + Given using DAV path + And user "Brian" has been created with default attributes and small skeleton files + And user "Alice" has been given unlimited quota + And the quota of user "Brian" has been set to "10 MB" + And user "Brian" has created folder "/testquota" + And user "Brian" has created a share with settings + | path | testquota | + | shareType | user | + | permissions | all | + | shareWith | Alice | + When user "Alice" gets the following properties of folder "/testquota" using the WebDAV API + | propertyName | + | d:quota-available-bytes | + Then the HTTP status code should be "200" + And the single response should contain a property "d:quota-available-bytes" with value "10485406" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Retrieving folder quota when quota is set and a file was uploaded + Given using DAV path + And the quota of user "Alice" has been set to "1 KB" + And user "Alice" has uploaded file "/prueba.txt" of size 93 bytes + When user "Alice" gets the following properties of folder "/" using the WebDAV API + | propertyName | + | d:quota-available-bytes | + Then the HTTP status code should be "201" + And the single response should contain a property "d:quota-available-bytes" with value "577" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required + Scenario Outline: Retrieving folder quota when quota is set and a file was received + Given using DAV path + And user "Brian" has been created with default attributes and small skeleton files + And the quota of user "Brian" has been set to "1 KB" + And user "Alice" has uploaded file "/Alice.txt" of size 93 bytes + And user "Alice" has shared file "Alice.txt" with user "Brian" + When user "Brian" gets the following properties of folder "/" using the WebDAV API + | propertyName | + | d:quota-available-bytes | + Then the HTTP status code should be "200" + And the single response should contain a property "d:quota-available-bytes" with value "670" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavProperties1/setFileProperties.feature b/tests/acceptance/features/coreApiWebdavProperties1/setFileProperties.feature new file mode 100644 index 00000000000..2f735a6d2a8 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavProperties1/setFileProperties.feature @@ -0,0 +1,105 @@ +@api +Feature: set file properties + As a user + I want to be able to set meta-information about files + So that I can reccord file meta-information (detailed requirement TBD) + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @smokeTest @issue-ocis-reva-276 + Scenario Outline: Setting custom DAV property and reading it + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/testcustomprop.txt" + And user "Alice" has set property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testcustomprop.txt" to "veryCustomPropValue" + When user "Alice" gets a custom property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testcustomprop.txt" + Then the response should contain a custom "very-custom-prop" property with namespace "x1='http://whatever.org/ns'" and value "veryCustomPropValue" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-217 + Scenario Outline: Setting custom complex DAV property and reading it + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/testcustomprop.txt" + And user "Alice" has set property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testcustomprop.txt" to "" + When user "Alice" gets a custom property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testcustomprop.txt" + Then the response should contain a custom "very-custom-prop" property with namespace "x1='http://whatever.org/ns'" and complex value "" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-276 + Scenario Outline: Setting custom DAV property and reading it after the file is renamed + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/testcustompropwithmove.txt" + And user "Alice" has set property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testcustompropwithmove.txt" to "valueForMovetest" + And user "Alice" has moved file "/testcustompropwithmove.txt" to "/catchmeifyoucan.txt" + When user "Alice" gets a custom property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/catchmeifyoucan.txt" + Then the response should contain a custom "very-custom-prop" property with namespace "x1='http://whatever.org/ns'" and value "valueForMovetest" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @issue-ocis-reva-217 + Scenario Outline: Setting custom DAV property on a shared file as an owner and reading as a recipient + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/testcustompropshared.txt" + And user "Alice" has created a share with settings + | path | testcustompropshared.txt | + | shareType | user | + | permissions | all | + | shareWith | Brian | + And user "Alice" has set property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testcustompropshared.txt" to "valueForSharetest" + When user "Brian" gets a custom property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testcustompropshared.txt" + Then the response should contain a custom "very-custom-prop" property with namespace "x1='http://whatever.org/ns'" and value "valueForSharetest" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-276 + Scenario Outline: Setting custom DAV property using one endpoint and reading it with other endpoint + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/testnewold.txt" + And user "Alice" has set property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testnewold.txt" to "lucky" + And using DAV path + When user "Alice" gets a custom property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testnewold.txt" + Then the response should contain a custom "very-custom-prop" property with namespace "x1='http://whatever.org/ns'" and value "lucky" + Examples: + | action_dav_version | other_dav_version | + | old | new | + | new | old | + + @skipOnOcV10 @personalSpace + Examples: + | action_dav_version | other_dav_version | + | spaces | new | + | spaces | old | + | new | spaces | + | old | spaces | diff --git a/tests/acceptance/features/coreApiWebdavProperties2/getFileProperties.feature b/tests/acceptance/features/coreApiWebdavProperties2/getFileProperties.feature new file mode 100644 index 00000000000..c3fddf28117 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavProperties2/getFileProperties.feature @@ -0,0 +1,657 @@ +@api +Feature: get file properties + As a user + I want to be able to get meta-information about files + So that I can know file meta-information (detailed requirement TBD) + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: Do a PROPFIND of various file names + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "" + When user "Alice" gets the properties of file "" using the WebDAV API + Then the HTTP status code should be "201" + And the properties response should contain an etag + Examples: + | dav_version | file_name | + | old | /upload.txt | + | old | /strängé file.txt | + | old | /नेपाली.txt | + | old | s,a,m,p,l,e.txt | + | new | /upload.txt | + | new | /strängé file.txt | + | new | /नेपाली.txt | + | new | s,a,m,p,l,e.txt | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | file_name | + | spaces | /upload.txt | + | spaces | /strängé file.txt | + | spaces | /नेपाली.txt | + | spaces | s,a,m,p,l,e.txt | + + @issue-ocis-reva-214 + Scenario Outline: Do a PROPFIND of various file names + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "" + When user "Alice" gets the properties of file "" using the WebDAV API + Then the HTTP status code should be "201" + And the properties response should contain an etag + And there should be an entry with href containing "" in the response to user "Alice" + Examples: + | dav_version | file_name | expected_href | + | old | /C++ file.cpp | remote.php/webdav/C++ file.cpp | + | old | /file #2.txt | remote.php/webdav/file #2.txt | + | old | /file ?2.txt | remote.php/webdav/file ?2.txt | + | old | /file &2.txt | remote.php/webdav/file &2.txt | + | new | /C++ file.cpp | remote.php/dav/files/%username%/C++ file.cpp | + | new | /file #2.txt | remote.php/dav/files/%username%/file #2.txt | + | new | /file ?2.txt | remote.php/dav/files/%username%/file ?2.txt | + | new | /file &2.txt | remote.php/dav/files/%username%/file &2.txt | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | file_name | expected_href | + | spaces | /C++ file.cpp | dav/spaces/%spaceid%/C++ file.cpp | + | spaces | /file #2.txt | dav/spaces/%spaceid%/file #2.txt | + | spaces | /file ?2.txt | dav/spaces/%spaceid%/file ?2.txt | + | spaces | /file &2.txt | dav/spaces/%spaceid%/file &2.txt | + + @issue-ocis-reva-214 + Scenario Outline: Do a PROPFIND of various folder names + Given using DAV path + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content" to "/file1.txt" + And user "Alice" has uploaded file with content "uploaded content" to "/file2.txt" + When user "Alice" gets the properties of folder "" with depth 1 using the WebDAV API + Then the HTTP status code should be "201" + And there should be an entry with href containing "/" in the response to user "Alice" + And there should be an entry with href containing "/file1.txt" in the response to user "Alice" + And there should be an entry with href containing "/file2.txt" in the response to user "Alice" + Examples: + | dav_version | folder_name | expected_href | + | old | /upload | remote.php/webdav/upload | + | old | /strängé folder | remote.php/webdav/strängé folder | + | old | /C++ folder | remote.php/webdav/C++ folder | + | old | /नेपाली | remote.php/webdav/नेपाली | + | old | /folder #2.txt | remote.php/webdav/folder #2.txt | + | old | /folder ?2.txt | remote.php/webdav/folder ?2.txt | + | old | /folder &2.txt | remote.php/webdav/folder &2.txt | + | new | /upload | remote.php/dav/files/%username%/upload | + | new | /strängé folder | remote.php/dav/files/%username%/strängé folder | + | new | /C++ folder | remote.php/dav/files/%username%/C++ folder | + | new | /नेपाली | remote.php/dav/files/%username%/नेपाली | + | new | /folder #2.txt | remote.php/dav/files/%username%/folder #2.txt | + | new | /folder ?2.txt | remote.php/dav/files/%username%/folder ?2.txt | + | new | /folder &2.txt | remote.php/dav/files/%username%/folder &2.txt | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | expected_href | + | spaces | /upload | dav/spaces/%spaceid%/upload | + | spaces | /strängé folder | dav/spaces/%spaceid%/strängé folder | + | spaces | /C++ folder | dav/spaces/%spaceid%/C++ folder | + | spaces | /नेपाली | dav/spaces/%spaceid%/नेपाली | + | spaces | /folder #2.txt | dav/spaces/%spaceid%/folder #2.txt | + | spaces | /folder ?2.txt | dav/spaces/%spaceid%/folder ?2.txt | + | spaces | /folder &2.txt | dav/spaces/%spaceid%/folder &2.txt | + + + Scenario Outline: Do a PROPFIND of various files inside various folders + Given using DAV path + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content" to "/" + When user "Alice" gets the properties of file "/" using the WebDAV API + Then the HTTP status code should be "201" + And the properties response should contain an etag + Examples: + | dav_version | folder_name | file_name | + | old | /upload | abc.txt | + | old | /strängé folder | strängé file.txt | + | old | /C++ folder | C++ file.cpp | + | old | /नेपाली | नेपाली | + | old | /folder #2.txt | file #2.txt | + | new | /upload | abc.txt | + | new | /strängé folder (duplicate #2 &) | strängé file (duplicate #2 &) | + | new | /C++ folder | C++ file.cpp | + | new | /नेपाली | नेपाली | + | new | /folder #2.txt | file #2.txt | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | file_name | + | spaces | /upload | abc.txt | + | spaces | /strängé folder | strängé file.txt | + | spaces | /C++ folder | C++ file.cpp | + | spaces | /नेपाली | नेपाली | + | spaces | /folder #2.txt | file #2.txt | + + @issue-ocis-reva-265 + #after fixing all issues delete this Scenario and merge with the one above + Scenario Outline: Do a PROPFIND of various files inside various folders + Given using DAV path + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content" to "/" + When user "Alice" gets the properties of file "/" using the WebDAV API + Then the HTTP status code should be "201" + And the properties response should contain an etag + Examples: + | dav_version | folder_name | file_name | + | old | /folder ?2.txt | file ?2.txt | + | new | /folder ?2.txt | file ?2.txt | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | file_name | + | spaces | /folder ?2.txt | file ?2.txt | + + + Scenario Outline: A file that is not shared does not have a share-types property + Given using DAV path + And user "Alice" has created folder "/test" + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | oc:share-types | + Then the HTTP status code should be "201" + And the response should contain an empty property "oc:share-types" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @issue-ocis-reva-11 + Scenario Outline: A file that is shared to a user has a share-types property + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/test" + And user "Alice" has created a share with settings + | path | test | + | shareType | user | + | permissions | all | + | shareWith | Brian | + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | oc:share-types | + Then the HTTP status code should be "200" + And the response should contain a share-types property with + | 0 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @files_sharing-app-required @issue-ocis-reva-11 + Scenario Outline: A file that is shared to a group has a share-types property + Given using DAV path + And group "grp1" has been created + And user "Alice" has created folder "/test" + And user "Alice" has created a share with settings + | path | test | + | shareType | group | + | permissions | all | + | shareWith | grp1 | + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | oc:share-types | + Then the HTTP status code should be "200" + And the response should contain a share-types property with + | 1 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-11 + Scenario Outline: A file that is shared by link has a share-types property + Given using DAV path + And user "Alice" has created folder "/test" + And user "Alice" has created a public link share with settings + | path | test | + | permissions | all | + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | oc:share-types | + Then the HTTP status code should be "200" + And the response should contain a share-types property with + | 3 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @skipOnLDAP @user_ldap-issue-268 @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-11 + Scenario Outline: A file that is shared by user,group and link has a share-types property + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has created folder "/test" + And user "Alice" has created a share with settings + | path | test | + | shareType | user | + | permissions | all | + | shareWith | Brian | + And user "Alice" has created a share with settings + | path | test | + | shareType | group | + | permissions | all | + | shareWith | grp1 | + And user "Alice" has created a public link share with settings + | path | test | + | permissions | all | + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | oc:share-types | + Then the HTTP status code should be "200" + And the response should contain a share-types property with + | 0 | + | 1 | + | 3 | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @notToImplementOnOCIS + Scenario Outline: Doing a PROPFIND with a web login should work with CSRF token on the new backend + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt" + And user "Alice" has logged in to a web-style session + When the client sends a "PROPFIND" to "/remote.php/dav/files/%username%/somefile.txt" of user "Alice" with requesttoken + Then the HTTP status code should be "207" + Examples: + | dav_version | + | old | + | new | + + @smokeTest @issue-ocis-reva-216 + Scenario Outline: Retrieving private link + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt" + When user "Alice" gets the following properties of file "/somefile.txt" using the WebDAV API + | propertyName | + | oc:privatelink | + Then the HTTP status code should be "201" + And the single response should contain a property "oc:privatelink" with value like "%(/(index.php/)?f/[0-9]*)%" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Do a PROPFIND to a nonexistent URL + When user "Alice" requests "" with "PROPFIND" using basic auth + Then the HTTP status code should be "404" + And the value of the item "/d:error/s:message" in the response about user "Alice" should be "" or "" + And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound" + + @skipOnOcV10 + Examples: + | url | message1 | message2 | + | /remote.php/dav/files/does-not-exist | Resource not found | Resource not found | + | /remote.php/dav/does-not-exist | File not found in root | | + + @skipOnOcis + Examples: + | url | message1 | message2 | + | /remote.php/dav/files/does-not-exist | Principal with name does-not-exist not found | | + | /remote.php/dav/does-not-exist | File not found: does-not-exist in 'root' | | + + @skipOnOcV10 @personalSpace + Examples: + | url | message1 | message2 | + | /remote.php/dav/spaces/%spaceid%/does-not-exist | Resource not found | | + | /remote.php/dav/spaces/%spaceid%/file1.txt | Resource not found | | + + @issue-ocis-reva-217 + Scenario Outline: add, receive multiple custom meta properties to a file + Given using DAV path + And user "Alice" has created folder "/TestFolder" + And user "Alice" has uploaded file with content "test data one" to "/TestFolder/test1.txt" + And user "Alice" has set the following properties of file "/TestFolder/test1.txt" using the WebDav API + | propertyName | propertyValue | + | testprop1 | AAAAA | + | testprop2 | BBBBB | + When user "Alice" gets the following properties of file "/TestFolder/test1.txt" using the WebDAV API + | propertyName | + | oc:testprop1 | + | oc:testprop2 | + Then the HTTP status code should be success + And as user "Alice" the last response should have the following properties + | resource | propertyName | propertyValue | + | /TestFolder/test1.txt | testprop1 | AAAAA | + | /TestFolder/test1.txt | testprop2 | BBBBB | + | /TestFolder/test1.txt | status | HTTP/1.1 200 OK | + Examples: + | dav_version | + | new | + + @skipOnOcV10 + Examples: + | dav_version | + | old | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-36920 @issue-ocis-reva-217 + Scenario Outline: add multiple properties to files inside a folder and do a propfind of the parent folder + Given using DAV path + And user "Alice" has created folder "/TestFolder" + And user "Alice" has uploaded file with content "test data one" to "/TestFolder/test1.txt" + And user "Alice" has uploaded file with content "test data two" to "/TestFolder/test2.txt" + And user "Alice" has set the following properties of file "/TestFolder/test1.txt" using the WebDav API + | propertyName | propertyValue | + | testprop1 | AAAAA | + | testprop2 | BBBBB | + And user "Alice" has set the following properties of file "/TestFolder/test2.txt" using the WebDav API + | propertyName | propertyValue | + | testprop1 | CCCCC | + | testprop2 | DDDDD | + When user "Alice" gets the following properties of folder "/TestFolder" using the WebDAV API + | propertyName | + | oc:testprop1 | + | oc:testprop2 | + Then the HTTP status code should be success + And as user "Alice" the last response should have the following properties + | resource | propertyName | propertyValue | + | /TestFolder/test1.txt | testprop1 | AAAAA | + | /TestFolder/test1.txt | testprop2 | BBBBB | + | /TestFolder/test2.txt | testprop1 | CCCCC | + | /TestFolder/test2.txt | testprop2 | DDDDD | + | /TestFolder/ | status | HTTP/1.1 404 Not Found | + Examples: + | dav_version | + | new | + + @skipOnOcV10 + Examples: + | dav_version | + | old | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the last modified date of a folder using webdav api + Given using DAV path + And user "Alice" has created folder "/test" + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | d:getlastmodified | + Then the HTTP status code should be "201" + And the single response should contain a property "d:getlastmodified" with value like "/^[MTWFS][uedhfriatno]{2},\s(\d){2}\s[JFMAJSOND][anebrpyulgctov]{2}\s\d{4}\s\d{2}:\d{2}:\d{2} GMT$/" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the content type of a folder using webdav api + Given using DAV path + And user "Alice" has created folder "/test" + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | d:getcontenttype | + Then the HTTP status code should be "201" + And the single response should contain a property "d:getcontenttype" with value "" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the content type of a file using webdav api + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "file.txt" + When user "Alice" gets the following properties of folder "file.txt" using the WebDAV API + | propertyName | + | d:getcontenttype | + Then the HTTP status code should be "201" + And the single response should contain a property "d:getcontenttype" with value "text/plain.*" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the etag of a file using webdav api + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "file.txt" + When user "Alice" gets the following properties of folder "file.txt" using the WebDAV API + | propertyName | + | d:getetag | + Then the HTTP status code should be "201" + And the single response should contain a property "d:getetag" with value like '%\"[a-z0-9:]{1,32}\"%' + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the resource type of a file using webdav api + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "file.txt" + When user "Alice" gets the following properties of folder "file.txt" using the WebDAV API + | propertyName | + | d:resourcetype | + Then the HTTP status code should be "201" + And the single response should contain a property "d:resourcetype" with value "" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the size of a file using webdav api + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "file.txt" + When user "Alice" gets the following properties of folder "file.txt" using the WebDAV API + | propertyName | + | oc:size | + Then the HTTP status code should be "201" + And the single response should contain a property "oc:size" with value "16" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the size of a folder using webdav api + Given using DAV path + And user "Alice" has created folder "/test" + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | oc:size | + Then the HTTP status code should be "201" + And the single response should contain a property "oc:size" with value "0" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the file id of a file using webdav api + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "file.txt" + When user "Alice" gets the following properties of folder "file.txt" using the WebDAV API + | propertyName | + | oc:fileid | + Then the HTTP status code should be "201" + And the single response should contain a property "oc:fileid" with value like '/[a-zA-Z0-9]+/' + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the file id of a folder using webdav api + Given using DAV path + And user "Alice" has created folder "/test" + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | oc:fileid | + Then the HTTP status code should be "201" + And the single response should contain a property "oc:fileid" with value like '/[a-zA-Z0-9]+/' + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the owner display name of a file using webdav api + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "file.txt" + When user "Alice" gets the following properties of file "file.txt" using the WebDAV API + | propertyName | + | oc:owner-display-name | + Then the HTTP status code should be "201" + And the single response about the file owned by "Alice" should contain a property "oc:owner-display-name" with value "%displayname%" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the owner display name of a folder using webdav api + Given using DAV path + And user "Alice" has created folder "/test" + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | oc:owner-display-name | + Then the HTTP status code should be "201" + And the single response about the file owned by "Alice" should contain a property "oc:owner-display-name" with value "%displayname%" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the permissions on a file using webdav api + Given using DAV path + And user "Alice" has uploaded file with content "uploaded content" to "file.txt" + When user "Alice" gets the following properties of folder "file.txt" using the WebDAV API + | propertyName | + | oc:permissions | + Then the HTTP status code should be "201" + And the single response should contain a property "oc:permissions" with value like '/RM{0,1}DNVW/' + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Propfind the permissions on a folder using webdav api + Given using DAV path + And user "Alice" has created folder "/test" + When user "Alice" gets the following properties of folder "/test" using the WebDAV API + | propertyName | + | oc:permissions | + Then the HTTP status code should be "201" + And the single response should contain a property "oc:permissions" with value like '/RM{0,1}DNVCK/' + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFile.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFile.feature new file mode 100644 index 00000000000..29184fbf485 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload1/uploadFile.feature @@ -0,0 +1,334 @@ +@api +Feature: upload file + As a user + I want to be able to upload files + So that I can store and share files between multiple client systems + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @smokeTest + Scenario Outline: upload a file and check download content + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to "" using the WebDAV API + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And the content of file "" for user "Alice" should be "uploaded content" + Examples: + | dav_version | file_name | + | old | /upload.txt | + | old | /नेपाली.txt | + | old | /strängé file.txt | + | old | /s,a,m,p,l,e.txt | + | new | /upload.txt | + | new | /नेपाली.txt | + | new | /strängé file.txt | + | new | /s,a,m,p,l,e.txt | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | file_name | + | spaces | /upload.txt | + | spaces | /नेपाली.txt | + | spaces | /strängé file.txt | + | spaces | /s,a,m,p,l,e.txt | + + + Scenario Outline: upload a file and check download content + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to using the WebDAV API + Then the HTTP status code should be "201" + And the content of file for user "Alice" should be "uploaded content" + Examples: + | dav_version | file_name | + | old | "C++ file.cpp" | + | old | "file #2.txt" | + | new | "C++ file.cpp" | + | new | "file #2.txt" | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | file_name | + | spaces | "C++ file.cpp" | + | spaces | "file #2.txt" | + + @issue-ocis-reva-265 + #after fixing all issues delete this Scenario and merge with the one above + Scenario Outline: upload a file and check download content + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to using the WebDAV API + Then the HTTP status code should be "201" + And the content of file for user "Alice" should be "uploaded content" + Examples: + | dav_version | file_name | + | old | "file ?2.txt" | + | old | " ?fi=le&%#2 . txt" | + | old | " # %ab ab?=ed " | + | new | "file ?2.txt" | + | new | " ?fi=le&%#2 . txt" | + | new | " # %ab ab?=ed " | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | file_name | + | spaces | "file ?2.txt" | + | spaces | " ?fi=le&%#2 . txt" | + | spaces | " # %ab ab?=ed " | + + + Scenario Outline: upload a file with comma in the filename and check download content + Given using DAV path + When user "Alice" uploads file with content "file with comma" to using the WebDAV API + Then the HTTP status code should be "201" + And the content of file for user "Alice" should be "file with comma" + Examples: + | dav_version | file_name | + | old | "sample,1.txt" | + | old | ",,,.txt" | + | old | ",,,.," | + | new | "sample,1.txt" | + | new | ",,,.txt" | + | new | ",,,.," | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | file_name | + | spaces | "sample,1.txt" | + | spaces | ",,,.txt" | + | spaces | ",,,.," | + + + Scenario Outline: upload a file into a folder and check download content + Given using DAV path + And user "Alice" has created folder "" + When user "Alice" uploads file with content "uploaded content" to "/" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/" for user "Alice" should be "uploaded content" + Examples: + | dav_version | folder_name | file_name | + | old | /upload | abc.txt | + | old | /strängé folder | strängé file.txt | + | old | /C++ folder | C++ file.cpp | + | old | /नेपाली | नेपाली | + | old | /folder #2.txt | file #2.txt | + | new | /upload | abc.txt | + | new | /strängé folder (duplicate #2 &) | strängé file (duplicate #2 &) | + | new | /C++ folder | C++ file.cpp | + | new | /नेपाली | नेपाली | + | new | /folder #2.txt | file #2.txt | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | file_name | + | spaces | /strängé folder | strängé file.txt | + | spaces | /upload | abc.txt | + | spaces | /C++ folder | C++ file.cpp | + | spaces | /नेपाली | नेपाली | + | spaces | /folder #2.txt | file #2.txt | + + @issue-ocis-reva-265 + #after fixing all issues delete this Scenario and merge with the one above + Scenario Outline: upload a file into a folder and check download content + Given using DAV path + And user "Alice" has created folder "" + When user "Alice" uploads file with content "uploaded content" to "/" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/" for user "Alice" should be "uploaded content" + Examples: + | dav_version | folder_name | file_name | + | old | /folder ?2.txt | file ?2.txt | + | old | /?fi=le&%#2 . txt | # %ab ab?=ed | + | new | /folder ?2.txt | file ?2.txt | + | new | /?fi=le&%#2 . txt | # %ab ab?=ed | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | file_name | + | spaces | /folder ?2.txt | file ?2.txt | + | spaces | /?fi=le&%#2 . txt | # %ab ab?=ed | + + + Scenario Outline: attempt to upload a file into a nonexistent folder + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to "nonexistent-folder/new-file.txt" using the WebDAV API + Then the HTTP status code should be "409" + And as "Alice" folder "nonexistent-folder" should not exist + And as "Alice" file "nonexistent-folder/new-file.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-15 + Scenario Outline: Uploading file to path with extension .part should not be possible + Given using DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile.part" using the WebDAV API + Then the HTTP status code should be "400" + And the DAV exception should be "OCA\DAV\Connector\Sabre\Exception\InvalidPath" + And the DAV message should be "Can`t upload files with extension .part because these extensions are reserved for internal use." + And the DAV reason should be "Can`t upload files with extension .part because these extensions are reserved for internal use." + And user "Alice" should not see the following elements + | /textfile.part | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: upload a file into a folder with dots in the path and check download content + Given using DAV path + And user "Alice" has created folder "" + When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "/" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "//" should exist + And the content of file "/" for user "Alice" should be "uploaded content for file name ending with a dot" + Examples: + | dav_version | folder_name | file_name | + | old | /upload. | abc. | + | old | /upload. | abc . | + | old | /upload.1 | abc.txt | + | old | /upload...1.. | abc...txt.. | + | old | /... | ... | + | new | /..upload | ..abc | + | new | /upload. | abc. | + | new | /upload. | abc . | + | new | /upload.1 | abc.txt | + | new | /upload...1.. | abc...txt.. | + | new | /... | ... | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | folder_name | file_name | + | spaces | /upload. | abc. | + | spaces | /upload. | abc . | + | spaces | /upload.1 | abc.txt | + | spaces | /upload...1.. | abc...txt.. | + | spaces | /... | ... | + + @issue-ocis-reva-174 + Scenario Outline: upload file with mtime + Given using DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "file.txt" should exist + And as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-174 + Scenario Outline: upload a file with mtime in a folder + Given using DAV path + And user "Alice" has created folder "testFolder" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testFolder/file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/testFolder/file.txt" should exist + And as "Alice" the mtime of the file "/testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-174 + Scenario Outline: moving a file does not change its mtime + Given using DAV path + And user "Alice" has created folder "testFolder" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API + And user "Alice" moves file "file.txt" to "/testFolder/file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/testFolder/file.txt" should exist + And as "Alice" the mtime of the file "/testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-174 + Scenario Outline: overwriting a file changes its mtime + Given using DAV path + And user "Alice" has uploaded file with content "first time upload content" to "file.txt" + When user "Alice" uploads a file with content "Overwrite file" and mtime "Thu, 08 Aug 2019 04:18:13 GMT" to "file.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "file.txt" should exist + And as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + And the content of file "file.txt" for user "Alice" should be "Overwrite file" + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: upload a hidden file and check download content + Given using DAV path + And user "Alice" has created folder "/FOLDER" + When user "Alice" uploads the following files with content "hidden file" + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + Then the HTTP status code of responses on all endpoints should be "201" + And as "Alice" the following files should exist + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + And the content of the following files for user "Alice" should be "hidden file" + | path | + | .hidden_file | + | /FOLDER/.hidden_file | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: upload a file of size zero byte + Given using DAV path + When user "Alice" uploads file "filesForUpload/zerobyte.txt" to "/zerobyte.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "zerobyte.txt" should exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileAsyncUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileAsyncUsingNewChunking.feature new file mode 100644 index 00000000000..ac8b0f3175c --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileAsyncUsingNewChunking.feature @@ -0,0 +1,184 @@ +@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 +Feature: upload file using new chunking + As a user + I want to be able to upload "large" files in chunks asynchronously + So that I do not have to wait for the long MOVE operation on assembly to finish + + Background: + Given using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + And the owncloud log level has been set to debug + And the owncloud log has been cleared + And the administrator has enabled async operations + + + Scenario: Upload chunked file ordered asc using async MOVE + When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + + Scenario: Upload chunked file ordered desc using async MOVE + When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API + | number | content | + | 3 | CCCCC | + | 2 | BBBBB | + | 1 | AAAAA | + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + + Scenario: Upload chunked file in random order using async MOVE + When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API + | number | content | + | 2 | BBBBB | + | 3 | CCCCC | + | 1 | AAAAA | + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + + Scenario: Upload chunked file overwriting existing file using async MOVE + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And user "Alice" has copied file "/textfile0.txt" to "/existingFile.txt" + When user "Alice" uploads the following chunks asynchronously to "/existingFile.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + And the content of file "/existingFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + + Scenario: New chunked upload MOVE using old DAV path should fail + Given user "Alice" has created a new chunking upload with id "chunking-42" + And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" + And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" + And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" + When using old DAV path + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" using the WebDAV API + Then the HTTP status code should be "404" + + + Scenario: Upload file via new chunking endpoint with wrong size header using async MOVE + Given user "Alice" has created a new chunking upload with id "chunking-42" + And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" + And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" + And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" + When user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with size 5 using the WebDAV API + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^error$/ | + | errorCode | /^400$/ | + | errorMessage | /^Chunks on server do not sum up to 5 but to 15$/ | + + + Scenario: Upload file via new chunking endpoint with correct size header using async MOVE + Given user "Alice" has created a new chunking upload with id "chunking-42" + And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" + And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" + And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" + When user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with size 15 using the WebDAV API + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + + Scenario Outline: Upload files with difficult names using new chunking and async MOVE + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/" using the WebDAV API + Then the HTTP status code should be "202" + And the following headers should match these regular expressions for user "Alice" + | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | + And the oc job status values of last request for user "Alice" should match these regular expressions + | status | /^finished$/ | + | fileId | /^[0-9a-z]{20,}$/ | + And as "Alice" file "/" should exist + And the content of file "/" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + Examples: + | file-name | + | &#? | + | TIÄFÜ | + + + Scenario: disabled async operations leads to original behavior + Given the administrator has disabled async operations + When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And the following headers should not be set + | header | + | OC-JobStatus-Location | + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + + + Scenario: enabling async operations does no difference to normal MOVE - Upload chunked file + When user "Alice" uploads the following chunks to "/myChunkedFile.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And the following headers should not be set + | header | + | OC-JobStatus-Location | + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature new file mode 100644 index 00000000000..3b67e27d8e3 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature @@ -0,0 +1,76 @@ +@api +Feature: users cannot upload a file to a blacklisted name + As an administrator + I want to be able to prevent users from uploading files to specified file names + So that I can prevent unwanted file names existing in the cloud storage + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @issue-ocis-reva-15 @notToImplementOnOCIS + Scenario Outline: upload a file to a filename that is banned by default + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to ".htaccess" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file ".htaccess" should not exist + Examples: + | dav_version | + | old | + | new | + + @issue-ocis-reva-54 + Scenario Outline: upload a file to a banned filename + Given using DAV path + And the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" + When user "Alice" uploads file with content "uploaded content" to "blacklisted-file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "blacklisted-file.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-54 + Scenario Outline: upload a file to a filename that matches (or not) blacklisted_files_regex + Given using DAV path + And user "Alice" has created folder "FOLDER" + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + And the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" uploads to these filenames with content "uploaded content" using the webDAV API then the results should be as listed + | filename | http-code | exists | + | .ext | 403 | no | + | filename.ext | 403 | no | + | bannedfilename.txt | 403 | no | + | containsbannedstring | 403 | no | + | this-ContainsBannedString.txt | 403 | no | + | /FOLDER/.ext | 403 | no | + | /FOLDER/filename.ext | 403 | no | + | /FOLDER/bannedfilename.txt | 403 | no | + | /FOLDER/containsbannedstring | 403 | no | + | /FOLDER/this-ContainsBannedString.txt | 403 | no | + | .extension | 201 | yes | + | filename.txt | 201 | yes | + | bannedfilename | 201 | yes | + | bannedfilenamewithoutdot | 201 | yes | + | not-contains-banned-string.txt | 201 | yes | + | /FOLDER/.extension | 201 | yes | + | /FOLDER/filename.txt | 201 | yes | + | /FOLDER/bannedfilename | 201 | yes | + | /FOLDER/bannedfilenamewithoutdot | 201 | yes | + | /FOLDER/not-contains-banned-string.txt | 201 | yes | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedNameAsyncUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedNameAsyncUsingNewChunking.feature new file mode 100644 index 00000000000..8705504a848 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedNameAsyncUsingNewChunking.feature @@ -0,0 +1,64 @@ +@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 +Feature: users cannot upload a file to a blacklisted name using new chunking + As an administrator + I want to be able to prevent users from uploading files to specified file names + So that I can prevent unwanted file names existing in the cloud storage + + Background: + Given using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + And the owncloud log level has been set to debug + And the owncloud log has been cleared + And the administrator has enabled async operations + + + Scenario: Upload to a filename that is banned by default using new chunking and async MOVE + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/.htaccess" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/.htaccess" should not exist + + + Scenario: Upload to a banned filename using new chunking and async MOVE + Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/blacklisted-file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/blacklisted-file.txt" should not exist + + + Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using new chunking and async MOVE + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "" should not exist + Examples: + | filename | + | filename.ext | + | bannedfilename.txt | + | this-ContainsBannedString.txt | + + + Scenario: upload a file to a filename that does not match blacklisted_files_regex using new chunking and async MOVE + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "not-contains-banned-string.txt" using the WebDAV API + Then the HTTP status code should be "202" + And as "Alice" file "not-contains-banned-string.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectory.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectory.feature new file mode 100644 index 00000000000..08ff53f1239 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectory.feature @@ -0,0 +1,86 @@ +@api +Feature: users cannot upload a file to or into an excluded directory + As an administrator + I want to be able to exclude directories (folders) from being processed. Any attempt to upload a file to one of those names should be refused. + So that I can have directories on my cloud server storage that are not available for syncing. + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @issue-ocis-reva-54 + Scenario Outline: upload a file to an excluded directory name + Given using DAV path + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" uploads file with content "uploaded content" to ".github" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file ".github" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-54 + Scenario Outline: upload a file to an excluded directory name inside a parent directory + Given using DAV path + And user "Alice" has created folder "FOLDER" + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" uploads file with content "uploaded content" to "/FOLDER/.github" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" folder "/FOLDER" should exist + But as "Alice" file "/FOLDER/.github" should not exist + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @issue-ocis-reva-54 + Scenario Outline: upload a file to a filename that matches (or not) excluded_directories_regex + Given using DAV path + And user "Alice" has created folder "FOLDER" + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + And the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" uploads to these filenames with content "uploaded content" using the webDAV API then the results should be as listed + | filename | http-code | exists | + | endswith.bad | 403 | no | + | thisendswith.bad | 403 | no | + | .git | 403 | no | + | .github | 403 | no | + | containsvirusinthename | 403 | no | + | this-containsvirusinthename.txt | 403 | no | + | /FOLDER/endswith.bad | 403 | no | + | /FOLDER/thisendswith.bad | 403 | no | + | /FOLDER/.git | 403 | no | + | /FOLDER/.github | 403 | no | + | /FOLDER/containsvirusinthename | 403 | no | + | /FOLDER/this-containsvirusinthename.txt | 403 | no | + | endswith.badandotherstuff | 201 | yes | + | thisendswith.badandotherstuff | 201 | yes | + | name.git | 201 | yes | + | name.github | 201 | yes | + | not-contains-virus-in-the-name.txt | 201 | yes | + | /FOLDER/endswith.badandotherstuff | 201 | yes | + | /FOLDER/thisendswith.badandotherstuff | 201 | yes | + | /FOLDER/name.git | 201 | yes | + | /FOLDER/name.github | 201 | yes | + | /FOLDER/not-contains-virus-in-the-name.txt | 201 | yes | + Examples: + | dav_version | + | old | + | new | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectoryAsyncUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectoryAsyncUsingNewChunking.feature new file mode 100644 index 00000000000..7dbc847654f --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectoryAsyncUsingNewChunking.feature @@ -0,0 +1,67 @@ +@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 +Feature: users cannot upload a file to or into an excluded directory using new chunking + As an administrator + I want to be able to exclude directories (folders) from being processed. Any attempt to upload a file to one of those names should be refused. + So that I can have directories on my cloud server storage that are not available for syncing. + + Background: + Given using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + And the owncloud log level has been set to debug + And the owncloud log has been cleared + And the administrator has enabled async operations + + + Scenario: Upload to an excluded directory name using new chunking and async MOVE + Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/.github" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "/.github" should not exist + + + Scenario: Upload to an excluded directory name inside a parent directory using new chunking and async MOVE + Given user "Alice" has created folder "FOLDER" + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/FOLDER/.github" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" folder "/FOLDER" should exist + But as "Alice" file "/FOLDER/.github" should not exist + + + Scenario Outline: upload a file to a filename that matches excluded_directories_regex using new chunking and async MOVE + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "" should not exist + Examples: + | filename | + | thisendswith.bad | + | .github | + | this-containsvirusinthename.txt | + + + Scenario: upload a file to a filename that does not match excluded_directories_regex using new chunking and async MOVE + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "not-contains-virus-in-the-name.txt" using the WebDAV API + Then the HTTP status code should be "202" + And as "Alice" file "not-contains-virus-in-the-name.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingNewChunking.feature new file mode 100644 index 00000000000..7e02f174cd2 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingNewChunking.feature @@ -0,0 +1,62 @@ +@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 +Feature: users cannot upload a file to a blacklisted name using new chunking + As an administrator + I want to be able to prevent users from uploading files to specified file names + So that I can prevent unwanted file names existing in the cloud storage + + Background: + Given using OCS API version "1" + And using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario: Upload a file to a filename that is banned by default using new chunking + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to ".htaccess" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file ".htaccess" should not exist + + + Scenario: Upload a file to a banned filename using new chunking + Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "blacklisted-file.txt" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "blacklisted-file.txt" should not exist + + + Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using new chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "" should not exist + Examples: + | filename | + | filename.ext | + | bannedfilename.txt | + | this-ContainsBannedString.txt | + + + Scenario: upload a file to a filename that does not match blacklisted_files_regex using new chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "not-contains-banned-string.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "not-contains-banned-string.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature new file mode 100644 index 00000000000..57181e3b5f3 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature @@ -0,0 +1,46 @@ +@api @issue-ocis-reva-15 +Feature: users cannot upload a file to a blacklisted name using old chunking + As an administrator + I want to be able to prevent users from uploading files to specified file names + So that I can prevent unwanted file names existing in the cloud storage + + Background: + Given using OCS API version "1" + And using old DAV path + And user "Alice" has been created with default attributes and without skeleton files + + @skipOnOcV10 @issue-36645 @notToImplementOnOCIS + Scenario: Upload a file to a filename that is banned by default using old chunking + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.htaccess" in 3 chunks using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file ".htaccess" should not exist + + @skipOnOcV10 @issue-36645 + Scenario: Upload a file to a banned filename using old chunking + Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "blacklisted-file.txt" in 3 chunks using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "blacklisted-file.txt" should not exist + + @skipOnOcV10 @issue-36645 + Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using old chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "" in 3 chunks using the WebDAV API + Then the HTTP status code should be "" + And as "Alice" file "" should not exist + Examples: + | filename | http-status | + | filename.ext | 403 | + | bannedfilename.txt | 403 | + | this-ContainsBannedString.txt | 403 | + + + Scenario: upload a file to a filename that does not match blacklisted_files_regex using old chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "not-contains-banned-string.txt" in 3 chunks using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "not-contains-banned-string.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunkingOc10Issue36645.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunkingOc10Issue36645.feature new file mode 100644 index 00000000000..9f0135c5ed7 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunkingOc10Issue36645.feature @@ -0,0 +1,39 @@ +@notToImplementOnOCIS @api @issue-ocis-reva-15 +Feature: users cannot upload a file to a blacklisted name using old chunking + As an administrator + I want to be able to prevent users from uploading files to specified file names + So that I can prevent unwanted file names existing in the cloud storage + + Background: + Given using OCS API version "1" + And using old DAV path + And user "Alice" has been created with default attributes and without skeleton files + + @issue-36645 + Scenario: Upload a file to a filename that is banned by default using old chunking + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.htaccess" in 3 chunks using the WebDAV API + Then the HTTP status code should be "507" +# Then the HTTP status code should be "403" + And as "Alice" file ".htaccess" should not exist + + @issue-36645 + Scenario: Upload a file to a banned filename using old chunking + Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "blacklisted-file.txt" in 3 chunks using the WebDAV API + Then the HTTP status code should be "507" +# Then the HTTP status code should be "403" + And as "Alice" file "blacklisted-file.txt" should not exist + + @issue-36645 + Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using old chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ + Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "" in 3 chunks using the WebDAV API + Then the HTTP status code should be "" + And as "Alice" file "" should not exist + Examples: + | filename | http-status | comment | + | filename.ext | 507 | issue-36645 | + | bannedfilename.txt | 403 | ok | + | this-ContainsBannedString.txt | 403 | ok | diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingNewChunking.feature new file mode 100644 index 00000000000..accfd7aa1f3 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingNewChunking.feature @@ -0,0 +1,65 @@ +@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 +Feature: users cannot upload a file to or into an excluded directory using new chunking + As an administrator + I want to be able to exclude directories (folders) from being processed. Any attempt to upload a file to one of those names should be refused. + So that I can have directories on my cloud server storage that are not available for syncing. + + Background: + Given using OCS API version "1" + And using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario: Upload a file to an excluded directory name using new chunking + Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to ".github" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file ".github" should not exist + + + Scenario: Upload a file to an excluded directory name inside a parent directory using new chunking + Given user "Alice" has created folder "FOLDER" + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "/FOLDER/.github" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" folder "/FOLDER" should exist + But as "Alice" file "/FOLDER/.github" should not exist + + + Scenario Outline: upload a file to a filename that matches excluded_directories_regex using new chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file "" should not exist + Examples: + | filename | + | thisendswith.bad | + | .github | + | this-containsvirusinthename.txt | + + + Scenario: upload a file to a filename that does not match excluded_directories_regex using new chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "not-contains-virus-in-the-name.txt" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "not-contains-virus-in-the-name.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature new file mode 100644 index 00000000000..b86c037efe8 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature @@ -0,0 +1,49 @@ +@api @issue-ocis-reva-15 +Feature: users cannot upload a file to or into an excluded directory using old chunking + As an administrator + I want to be able to exclude directories (folders) from being processed. Any attempt to upload a file to one of those names should be refused. + So that I can have directories on my cloud server storage that are not available for syncing. + + Background: + Given using OCS API version "1" + And using old DAV path + And user "Alice" has been created with default attributes and without skeleton files + + @skipOnOcV10 @issue-36645 + Scenario: Upload a file to an excluded directory name using old chunking + Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.github" in 3 chunks using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" file ".github" should not exist + + @skipOnOcV10 @issue-36645 + Scenario: Upload a file to an excluded directory name inside a parent directory using old chunking + Given user "Alice" has created folder "FOLDER" + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/FOLDER/.github" in 3 chunks using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" folder "/FOLDER" should exist + But as "Alice" file "/FOLDER/.github" should not exist + + @skipOnOcV10 @issue-36645 + Scenario Outline: upload a file to a filename that matches excluded_directories_regex using old chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "" in 3 chunks using the WebDAV API + Then the HTTP status code should be "" + And as "Alice" file "" should not exist + Examples: + | filename | http-status | + | thisendswith.bad | 503 | + | .github | 403 | + | this-containsvirusinthename.txt | 403 | + + + Scenario: upload a file to a filename that does not match excluded_directories_regex using old chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "not-contains-virus-in-the-name.txt" in 3 chunks using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "not-contains-virus-in-the-name.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunkingOc10Issue36645.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunkingOc10Issue36645.feature new file mode 100644 index 00000000000..34a74b048d6 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunkingOc10Issue36645.feature @@ -0,0 +1,42 @@ +@notToImplementOnOCIS @api @issue-ocis-reva-15 +Feature: users cannot upload a file to or into an excluded directory using old chunking + As an administrator + I want to be able to exclude directories (folders) from being processed. Any attempt to upload a file to one of those names should be refused. + So that I can have directories on my cloud server storage that are not available for syncing. + + Background: + Given using OCS API version "1" + And using old DAV path + And user "Alice" has been created with default attributes and without skeleton files + + @issue-36645 + Scenario: Upload a file to an excluded directory name using old chunking + Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.github" in 3 chunks using the WebDAV API + Then the HTTP status code should be "507" +# Then the HTTP status code should be "403" + And as "Alice" file ".github" should not exist + + @issue-36645 + Scenario: Upload a file to an excluded directory name inside a parent directory using old chunking + Given user "Alice" has created folder "FOLDER" + And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/FOLDER/.github" in 3 chunks using the WebDAV API + Then the HTTP status code should be "507" +# Then the HTTP status code should be "403" + And as "Alice" folder "/FOLDER" should exist + But as "Alice" file "/FOLDER/.github" should not exist + + @issue-36645 + Scenario Outline: upload a file to a filename that matches excluded_directories_regex using old chunking + # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it + # The actual regular expressions end up being endswith\.bad$ and ^\.git + Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "" in 3 chunks using the WebDAV API + Then the HTTP status code should be "" + And as "Alice" file "" should not exist + Examples: + | filename | http-status | comment | + | thisendswith.bad | 507 | issue-36645 | + | .github | 403 | ok | + | this-containsvirusinthename.txt | 403 | ok | diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingNewChunking.feature new file mode 100644 index 00000000000..69419021364 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingNewChunking.feature @@ -0,0 +1,193 @@ +@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 +Feature: upload file using new chunking + As a user + I want to be able to upload "large" files in chunks + So that the upload can be completed in less elapsed time + + Background: + Given using OCS API version "1" + And using new DAV path + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario: Upload chunked file asc with new chunking + Given the owncloud log level has been set to debug + And the owncloud log has been cleared + When user "Alice" uploads the following chunks to "/myChunkedFile.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + + Scenario: Upload chunked file desc with new chunking + Given the owncloud log level has been set to debug + And the owncloud log has been cleared + When user "Alice" uploads the following chunks to "/myChunkedFile.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + + Scenario: Upload chunked file random with new chunking + Given the owncloud log level has been set to debug + And the owncloud log has been cleared + When user "Alice" uploads the following chunks to "/myChunkedFile.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + + Scenario: Checking file id after a move overwrite using new chunking endpoint + Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And the owncloud log level has been set to debug + And the owncloud log has been cleared + And user "Alice" has copied file "/textfile0.txt" to "/existingFile.txt" + And user "Alice" has stored id of file "/existingFile.txt" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/existingFile.txt" in 3 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "204" + And user "Alice" file "/existingFile.txt" should have the previously stored id + And the content of file "/existingFile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + + Scenario: New chunked upload MKDIR using old DAV path should fail + Given using old DAV path + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + Then the HTTP status code should be "409" + + + Scenario: New chunked upload PUT using old DAV path should fail + Given user "Alice" has created a new chunking upload with id "chunking-42" + When using old DAV path + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + Then the HTTP status code should be "409" + + + Scenario: New chunked upload MOVE using old DAV path should fail + Given user "Alice" has created a new chunking upload with id "chunking-42" + And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" + And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" + And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" + When using old DAV path + And user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" using the WebDAV API + Then the HTTP status code should be "404" + + + Scenario: Upload to new DAV path using old way should fail + When user "Alice" uploads chunk file "1" of "3" with "AAAAA" to "/myChunkedFile.txt" using the WebDAV API + Then the HTTP status code should be "503" + + + Scenario: Upload file via new chunking endpoint with wrong size header + Given user "Alice" has created a new chunking upload with id "chunking-42" + And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" + And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" + And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" + When user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with size 5 using the WebDAV API + Then the HTTP status code should be "400" + + + Scenario: Upload file via new chunking endpoint with correct size header + Given the owncloud log level has been set to debug + And the owncloud log has been cleared + And user "Alice" has created a new chunking upload with id "chunking-42" + And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" + And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" + And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" + When user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with size 15 using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + + @smokeTest + # This smokeTest scenario does ordinary checks for chunked upload, + # without adjusting the log level. This allows it to run in test environments + # where the log level has been fixed and cannot be changed. + Scenario Outline: Upload files with difficult names using new chunking + When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API + And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API + And user "Alice" moves new chunk file with id "chunking-42" to "/" using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/" should exist + And the content of file "/" for user "Alice" should be "AAAAABBBBBCCCCC" + Examples: + | file-name | + | 0 | + | &#? | + | TIÄFÜ | + + + # This scenario does extra checks with the log level set to debug. + # It does not run in smoke test runs. (see comments in scenario above) + Scenario Outline: Upload files with difficult names using new chunking and check the log + Given the owncloud log level has been set to debug + And the owncloud log has been cleared + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/" in 3 chunks with new chunking and using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/" should exist + And the content of file "/" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + Examples: + | file-name | + | &#? | + | TIÄFÜ | + + + Scenario: Upload chunked file with new chunking with lengthy filenames + Given the owncloud log level has been set to debug + And the owncloud log has been cleared + When user "Alice" uploads the following chunks to "हजार नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-012345.txt" with new chunking and using the WebDAV API + | number | content | + | 1 | AAAAAAAAAAAAAAAAAAAAAAAAA | + | 2 | BBBBBBBBBBBBBBBBBBBBBBBBB | + | 3 | CCCCCCCCCCCCCCCCCCCCCCCCC | + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" file "हजार नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-012345.txt" should exist + And the content of file "हजार नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-012345.txt" for user "Alice" should be "AAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunking.feature new file mode 100644 index 00000000000..938351d63b0 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunking.feature @@ -0,0 +1,190 @@ +@api @issue-ocis-reva-17 +Feature: upload file using old chunking + As a user + I want to be able to upload "large" files in chunks + So that the upload can be completed in less elapsed time + + Background: + Given using OCS API version "1" + And user "Alice" has been created with default attributes and without skeleton files + + @skipOnOcV10 @issue-36115 + Scenario Outline: Upload chunked file asc + Given using DAV path + When user "Alice" uploads the following "3" chunks to "/myChunkedFile.txt" with old chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + Examples: + | dav_version | + | old | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Upload chunked file desc + Given using DAV path + When user "Alice" uploads the following "3" chunks to "/myChunkedFile.txt" with old chunking and using the WebDAV API + | number | content | + | 3 | CCCCC | + | 2 | BBBBB | + | 1 | AAAAA | + Then the HTTP status code should be "201" + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + Examples: + | dav_version | + | old | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Upload chunked file random + Given using DAV path + When user "Alice" uploads the following "3" chunks to "/myChunkedFile.txt" with old chunking and using the WebDAV API + | number | content | + | 2 | BBBBB | + | 3 | CCCCC | + | 1 | AAAAA | + Then the HTTP status code should be "201" + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + Examples: + | dav_version | + | old | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Checking file id after a move overwrite using old chunking endpoint + Given using DAV path + And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" + And the owncloud log level has been set to debug + And the owncloud log has been cleared + And user "Alice" has copied file "/textfile0.txt" to "/existingFile.txt" + And user "Alice" has stored id of file "/existingFile.txt" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/existingFile.txt" in 3 chunks with old chunking and using the WebDAV API + Then the HTTP status code should be "201" + And user "Alice" file "/existingFile.txt" should have the previously stored id + And the content of file "/existingFile.txt" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + Examples: + | dav_version | + | old | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | + | spaces | + + @smokeTest + # This smokeTest scenario does ordinary checks for chunked upload, + # without adjusting the log level. This allows it to run in test environments + # where the log level has been fixed and cannot be changed. + Scenario Outline: Chunked upload files with difficult name + Given using DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/" in 3 chunks using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/" should exist + And the content of file "/" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + Examples: + | dav_version | file-name | + | old | &#? TIÄFÜ @a#8a=b?c=d ?abc=oc # | + | old | 0 | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | file-name | + | spaces | &#? TIÄFÜ @a#8a=b?c=d ?abc=oc # | + | spaces | 0 | + + # This scenario does extra checks with the log level set to debug. + # It does not run in smoke test runs. (see comments in scenario above) + Scenario Outline: Chunked upload files with difficult name and check the log + Given using DAV path + And the owncloud log level has been set to debug + And the owncloud log has been cleared + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/" in 3 chunks using the WebDAV API + Then the HTTP status code should be "201" + And as "Alice" file "/" should exist + And the content of file "/" for user "Alice" should be: + """ + This is a testfile. + + Cheers. + """ + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + Examples: + | dav_version | file-name | + | old | file-name | + | old | &#? | + | old | TIÄFÜ | + | old | 0 | + | old | @a#8a=b?c=d | + | old | ?abc=oc # | + + @skipOnOcV10 @personalSpace + Examples: + | dav_version | file-name | + | spaces | file-name | + | spaces | &#? | + | spaces | TIÄFÜ | + | spaces | 0 | + | spaces | @a#8a=b?c=d | + | spaces | ?abc=oc # | + + @skipOnOcV10 @issue-36115 + Scenario Outline: Upload chunked file with old chunking with lengthy filenames + Given using DAV path + Given the owncloud log level has been set to debug + And the owncloud log has been cleared + When user "Alice" uploads the following chunks to "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" with old chunking and using the WebDAV API + | number | content | + | 1 | AAAAAAAAAAAAAAAAAAAAAAAAA | + | 2 | BBBBBBBBBBBBBBBBBBBBBBBBB | + | 3 | CCCCCCCCCCCCCCCCCCCCCCCCC | + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" file "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" should exist + And the content of file "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" for user "Alice" should be "AAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | + Examples: + | dav_version | + | old | + + @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunkingOc10Issue36115.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunkingOc10Issue36115.feature new file mode 100644 index 00000000000..a52fc8c0bba --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunkingOc10Issue36115.feature @@ -0,0 +1,43 @@ +@notToImplementOnOCIS @api @issue-ocis-reva-17 +Feature: upload file using old chunking + As a user + I want to be able to upload "large" files in chunks + So that the upload can be completed in less elapsed time + + @issue-36115 + Scenario: Upload chunked file asc + Given using OCS API version "1" + And using old DAV path + And user "Alice" has been created with default attributes and without skeleton files + When user "Alice" uploads the following "3" chunks to "/myChunkedFile.txt" with old chunking and using the WebDAV API + | number | content | + | 1 | AAAAA | + | 2 | BBBBB | + | 3 | CCCCC | + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^[a-f0-9:\.]{1,32}$/ | +# | ETag | /^"[a-f0-9:\.]{1,32}"$/ | + And as "Alice" file "/myChunkedFile.txt" should exist + And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" + + + Scenario: Upload chunked file with old chunking with lengthy filenames + Given using OCS API version "1" + And using old DAV path + And user "Alice" has been created with default attributes and without skeleton files + And the owncloud log level has been set to debug + And the owncloud log has been cleared + When user "Alice" uploads the following chunks to "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" with old chunking and using the WebDAV API + | number | content | + | 1 | AAAAAAAAAAAAAAAAAAAAAAAAA | + | 2 | BBBBBBBBBBBBBBBBBBBBBBBBB | + | 3 | CCCCCCCCCCCCCCCCCCCCCCCCC | + Then the HTTP status code should be "201" + And the following headers should match these regular expressions for user "Alice" + | ETag | /^[a-f0-9:\.]{1,32}$/ | + And as "Alice" file "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" should exist + And the content of file "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" for user "Alice" should be "AAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCC" + And the log file should not contain any log-entries containing these attributes: + | app | + | dav | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature new file mode 100644 index 00000000000..3eeb77f31dd --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature @@ -0,0 +1,291 @@ +@api @skipOnOcV10 +Feature: checksums + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Uploading a file with checksum should work + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + When user "Alice" uploads file with checksum "" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textFile.txt" for user "Alice" should be "12345" + Examples: + | dav_version | checksum | + | old | MD5 827ccb0eea8a706c4c34a16891f84e7b | + | new | MD5 827ccb0eea8a706c4c34a16891f84e7b | + | old | SHA1 8cb2237d0679ca88db6464eac60da96345513964 | + | new | SHA1 8cb2237d0679ca88db6464eac60da96345513964 | + + @personalSpace + Examples: + | dav_version | checksum | + | spaces | MD5 827ccb0eea8a706c4c34a16891f84e7b | + | spaces | SHA1 8cb2237d0679ca88db6464eac60da96345513964 | + + + Scenario Outline: Uploading a file with checksum should return the checksum in the propfind + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + When user "Alice" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + And user "Alice" requests the checksum of "/textFile.txt" via propfind + Then the HTTP status code should be "207" + And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Uploading a file with checksum should return the checksum in the download header + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + When user "Alice" downloads file "/textFile.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Uploading a file with incorrect checksum should not work + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + When user "Alice" uploads file with checksum "" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + Then the HTTP status code should be "406" + And as "Alice" file "textFile.txt" should not exist + Examples: + | dav_version | incorrect_checksum | + | old | MD5 827ccb0eea8a706c4c34a16891f84e7a | + | new | MD5 827ccb0eea8a706c4c34a16891f84e7a | + | old | SHA1 8cb2237d0679ca88db6464eac60da96345513963 | + | new | SHA1 8cb2237d0679ca88db6464eac60da96345513963 | + + @personalSpace + Examples: + | dav_version | incorrect_checksum | + | spaces | MD5 827ccb0eea8a706c4c34a16891f84e7a | + | spaces | SHA1 8cb2237d0679ca88db6464eac60da96345513963 | + + + Scenario Outline: Uploading a chunked file with correct checksum should work + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API + And user "Alice" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/textFile.txt" for user "Alice" should be "0123456789" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Uploading a chunked file with correct checksum should return the checksum in the propfind + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API + And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API + When user "Alice" requests the checksum of "/textFile.txt" via propfind + Then the HTTP status code should be "207" + And the webdav checksum should match "SHA1:87acec17cd9dcd20a716cc2cf67417b71c8a7016 MD5:781e5e245d69b566979b86e28d23f2c7 ADLER32:0aff020e" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Uploading a chunked file with checksum should return the checksum in the download header + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API + And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API + When user "Alice" downloads file "/textFile.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the header checksum should match "SHA1:87acec17cd9dcd20a716cc2cf67417b71c8a7016" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Uploading second chunk of file with incorrect checksum should not work + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546799" using the TUS protocol on the WebDAV API + And user "Alice" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 781e5e245d69b566979b86e28d23f2c7" using the TUS protocol on the WebDAV API + Then the HTTP status code should be "409" + And as "Alice" file "textFile.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Uploading a file with correct checksum and overwriting an existing file should return the checksum for new data in the propfind + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API + And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API + When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "" using the TUS protocol on the WebDAV API with these headers: + | Upload-Length | 5 | + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" requests the checksum of "/textFile.txt" via propfind + Then the HTTP status code should be "207" + And the webdav checksum should match "SHA1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d MD5:5d41402abc4b2a76b9719d911017c592 ADLER32:062c0215" + And the content of file "/textFile.txt" for user "Alice" should be "hello" + Examples: + | dav_version | overwriteChecksum | + | old | MD5 5d41402abc4b2a76b9719d911017c592 | + | new | MD5 5d41402abc4b2a76b9719d911017c592 | + | old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d | + | new | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d | + + @personalSpace + Examples: + | dav_version | overwriteChecksum | + | spaces | MD5 5d41402abc4b2a76b9719d911017c592 | + | spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d | + + + Scenario Outline: Uploading a file with correct checksum and overwriting an existing file with invalid checksum should not work + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API + And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API + When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "" using the TUS protocol on the WebDAV API with these headers: + | Upload-Length | 5 | + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + Then the HTTP status code should be "406" + And the content of file "/textFile.txt" for user "Alice" should be "0123456789" + Examples: + | dav_version | overwriteInvalidChecksum | + | old | MD5 5d41402abc4b2a76b9719d911017c593 | + | new | MD5 5d41402abc4b2a76b9719d911017c593 | + | old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a | + | new | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a | + + @personalSpace + Examples: + | dav_version | overwriteInvalidChecksum | + | spaces | MD5 5d41402abc4b2a76b9719d911017c593 | + | spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a | + + + Scenario Outline: Overwriting an existing file with new data and checksum should return the checksum of new data in the propfind + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "" using the TUS protocol on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" requests the checksum of "/textFile.txt" via propfind + Then the HTTP status code should be "207" + And the webdav checksum should match "SHA1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d MD5:5d41402abc4b2a76b9719d911017c592 ADLER32:062c0215" + And the content of file "/textFile.txt" for user "Alice" should be "hello" + Examples: + | dav_version | overwriteChecksum | + | old | MD5 5d41402abc4b2a76b9719d911017c592 | + | new | MD5 5d41402abc4b2a76b9719d911017c592 | + | old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d | + | new | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d | + + @personalSpace + Examples: + | dav_version | overwriteChecksum | + | spaces | MD5 5d41402abc4b2a76b9719d911017c592 | + | spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d | + + + Scenario Outline: Overwriting an existing file with new data and invalid checksum should not work + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "" using the TUS protocol on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + Then the HTTP status code should be "406" + And the content of file "/textFile.txt" for user "Alice" should be "12345" + Examples: + | dav_version | overwriteChecksum | + | old | MD5 5d41402abc4b2a76b9719d911017c593 | + | new | MD5 5d41402abc4b2a76b9719d911017c593 | + | old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a | + | new | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a | + + @personalSpace + Examples: + | dav_version | overwriteChecksum | + | spaces | MD5 5d41402abc4b2a76b9719d911017c593 | + | spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/creationWithUploadExtension.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/creationWithUploadExtension.feature new file mode 100644 index 00000000000..8a8c57e6091 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/creationWithUploadExtension.feature @@ -0,0 +1,46 @@ +@api @skipOnOcV10 +Feature: tests of the creation extension see https://tus.io/protocols/resumable-upload.html#creation-with-upload + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: creating a new upload resource using creation with upload extension + Given using DAV path + When user "Alice" creates a new TUS resource with content "uploaded content" on the WebDAV API with these headers: + | Upload-Length | 16 | + | Tus-Resumable | 1.0.0 | + | Content-Type | application/offset+octet-stream | + # dGVzdC50eHQ= is the base64 encode of test.txt + | Upload-Metadata | filename dGVzdC50eHQ= | + | Tus-Extension | creation-with-upload | + Then the HTTP status code should be "201" + And the following headers should match these regular expressions + | Tus-Resumable | /1\.0\.0/ | + | Location | /http[s]?:\/\/.*:\d+\/data\/.*/ | + | Upload-Offset | /\d+/ | + And the content of file "/test.txt" for user "Alice" should be "uploaded content" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: creating a new resource and upload data in multiple bytes using creation with upload extension + Given using DAV path + When user "Alice" creates file "textFile.txt" and uploads content "12345" in the same request using the TUS protocol on the WebDAV API + Then the content of file "/textFile.txt" for user "Alice" should be "12345" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/lowLevelCreationExtension.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/lowLevelCreationExtension.feature new file mode 100644 index 00000000000..3340ed9eead --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/lowLevelCreationExtension.feature @@ -0,0 +1,48 @@ +@api @skipOnOcV10 +Feature: low level tests of the creation extension see https://tus.io/protocols/resumable-upload.html#creation + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: creating a new upload resource + Given using DAV path + When user "Alice" creates a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 100 | + # d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg== is the base64 encode of world_domination_plan.pdf + | Upload-Metadata | filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg== | + | Tus-Resumable | 1.0.0 | + Then the HTTP status code should be "201" + And the following headers should match these regular expressions + | Tus-Resumable | /1\.0\.0/ | + | Location | /http[s]?:\/\/.*:\d+\/data\/.*/ | + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: creating a new upload resource without upload length + Given using DAV path + When user "Alice" creates a new TUS resource on the WebDAV API with these headers: + | Tus-Resumable | 1.0.0 | + # d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg== is the base64 encode of world_domination_plan.pdf + | Upload-Metadata | filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg== | + Then the HTTP status code should be "412" + And the following headers should not be set + | header | + | Location | + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/lowLevelUpload.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/lowLevelUpload.feature new file mode 100644 index 00000000000..02fba4390d6 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/lowLevelUpload.feature @@ -0,0 +1,90 @@ +@api @skipOnOcV10 +Feature: low level tests for upload of chunks + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: upload a chunk twice + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # ZmlsZS50eHQ= is the base64 encode of file.txt + | Upload-Metadata | filename ZmlsZS50eHQ= | + When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API + And user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "000" using the WebDAV API + Then the HTTP status code should be "409" + And as "Alice" file "file.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: finalize file upload after uploading a chunk twice + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # ZmlsZS50eHQ= is the base64 encode of file.txt + | Upload-Metadata | filename ZmlsZS50eHQ= | + When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API + And user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "000" using the WebDAV API + And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "4567890" using the WebDAV API + Then the HTTP status code should be "204" + And the content of file "/file.txt" for user "Alice" should be "1234567890" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: send last chunk twice + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # ZmlsZS50eHQ= is the base64 encode of file.txt + | Upload-Metadata | filename ZmlsZS50eHQ= | + When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API + And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "4567890" using the WebDAV API + And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "0000000" using the WebDAV API + Then the HTTP status code should be "404" + And the content of file "/file.txt" for user "Alice" should be "1234567890" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: start with uploading not at the beginning of the file + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # ZmlsZS50eHQ= is the base64 encode of file.txt + | Upload-Metadata | filename ZmlsZS50eHQ= | + When user "Alice" sends a chunk to the last created TUS Location with offset "1" and data "123" using the WebDAV API + Then the HTTP status code should be "409" + And as "Alice" file "file.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature new file mode 100644 index 00000000000..c41fddbd83b --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature @@ -0,0 +1,115 @@ +@api @skipOnOcV10 +Feature: OPTIONS request + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario: send OPTIONS request to webDav endpoints using the TUS protocol with valid password and username + When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/ | + | /remote.php/dav/files/%username%/ | + Then the HTTP status code should be "204" + And the following headers should be set + | header | value | + | Tus-Resumable | 1.0.0 | + | Tus-Version | 1.0.0 | + | Tus-Extension | creation,creation-with-upload,checksum,expiration | + | Tus-Checksum-Algorithm | md5,sha1,adler32 | + + @personalSpace + Scenario: send OPTIONS request to spaces webDav endpoint using the TUS protocol with valid password and username + When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/ | + Then the HTTP status code should be "204" + And the following headers should be set + | header | value | + | Tus-Resumable | 1.0.0 | + | Tus-Version | 1.0.0 | + | Tus-Extension | creation,creation-with-upload,checksum,expiration | + | Tus-Checksum-Algorithm | md5,sha1,adler32 | + + + Scenario: send OPTIONS request to webDav endpoints using the TUS protocol without any authentication + When a user requests these endpoints with "OPTIONS" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/webdav/ | + | /remote.php/dav/files/%username%/ | + Then the HTTP status code should be "204" + And the following headers should be set + | header | value | + | Tus-Resumable | 1.0.0 | + | Tus-Version | 1.0.0 | + | Tus-Extension | creation,creation-with-upload,checksum,expiration | + | Tus-Checksum-Algorithm | md5,sha1,adler32 | + + @personalSpace + Scenario: send OPTIONS request to spaces webDav endpoint using the TUS protocol without any authentication + When a user requests these endpoints with "OPTIONS" with body "doesnotmatter" and no authentication about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/ | + Then the HTTP status code should be "204" + And the following headers should be set + | header | value | + | Tus-Resumable | 1.0.0 | + | Tus-Version | 1.0.0 | + | Tus-Extension | creation,creation-with-upload,checksum,expiration | + | Tus-Checksum-Algorithm | md5,sha1,adler32 | + + + Scenario: send OPTIONS request to webDav endpoints using the TUS protocol with valid username and wrong password + When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/webdav/ | + | /remote.php/dav/files/%username%/ | + Then the HTTP status code should be "401" + And the following headers should be set + | header | value | + | Tus-Resumable | 1.0.0 | + | Tus-Version | 1.0.0 | + | Tus-Extension | creation,creation-with-upload,checksum,expiration | + | Tus-Checksum-Algorithm | md5,sha1,adler32 | + + @personalSpace + Scenario: send OPTIONS request to spaces webDav endpoint using the TUS protocol with valid username and wrong password + When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using password "invalid" about user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/ | + Then the HTTP status code should be "401" + And the following headers should be set + | header | value | + | Tus-Resumable | 1.0.0 | + | Tus-Version | 1.0.0 | + | Tus-Extension | creation,creation-with-upload,checksum,expiration | + | Tus-Checksum-Algorithm | md5,sha1,adler32 | + + + Scenario: send OPTIONS requests to webDav endpoints using valid password and username of different user + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/webdav/ | + | /remote.php/dav/files/%username%/ | + Then the HTTP status code should be "401" + And the following headers should be set + | header | value | + | Tus-Resumable | 1.0.0 | + | Tus-Version | 1.0.0 | + | Tus-Extension | creation,creation-with-upload,checksum,expiration | + | Tus-Checksum-Algorithm | md5,sha1,adler32 | + + @personalSpace + Scenario: send OPTIONS requests to spaces webDav endpoints using valid password and username of different user + Given user "Brian" has been created with default attributes and without skeleton files + When user "Brian" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice" + | endpoint | + | /remote.php/dav/spaces/%spaceid%/ | + Then the HTTP status code should be "401" + And the following headers should be set + | header | value | + | Tus-Resumable | 1.0.0 | + | Tus-Version | 1.0.0 | + | Tus-Extension | creation,creation-with-upload,checksum,expiration | + | Tus-Checksum-Algorithm | md5,sha1,adler32 | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFile.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFile.feature new file mode 100644 index 00000000000..bea7de061fc --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFile.feature @@ -0,0 +1,211 @@ +@api @skipOnOcV10 +Feature: upload file + As a user + I want to be able to upload files + So that I can store and share files between multiple client systems + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: upload a file and check download content + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to "" using the TUS protocol on the WebDAV API + Then the content of file "" for user "Alice" should be "uploaded content" + Examples: + | dav_version | file_name | + | old | /upload.txt | + | old | /नेपाली.txt | + | old | /strängé file.txt | + | old | /s,a,m,p,l,e.txt | + | old | /C++ file.cpp | + | old | /?fi=le&%#2 . txt | + | old | /# %ab ab?=ed | + | new | /upload.txt | + | new | /strängé file.txt | + | new | /नेपाली.txt | + | new | /s,a,m,p,l,e.txt | + | new | /C++ file.cpp | + | new | /?fi=le&%#2 . txt | + | new | /# %ab ab?=ed | + + @personalSpace + Examples: + | dav_version | file_name | + | spaces | /upload.txt | + | spaces | /strängé file.txt | + | spaces | /नेपाली.txt | + | spaces | /s,a,m,p,l,e.txt | + | spaces | /C++ file.cpp | + | spaces | /?fi=le&%#2 . txt | + | spaces | /# %ab ab?=ed | + + + Scenario Outline: upload a file into a folder and check download content + Given using DAV path + And user "Alice" has created folder "" + When user "Alice" uploads file with content "uploaded content" to "/" using the TUS protocol on the WebDAV API + Then the content of file "/" for user "Alice" should be "uploaded content" + Examples: + | dav_version | folder_name | file_name | + | old | /upload | abc.txt | + | old | /strängé folder | strängé file.txt | + | old | /C++ folder | C++ file.cpp | + | old | /नेपाली | नेपाली | + | old | /folder #2.txt | file #2.txt | + | old | /folder ?2.txt | file ?2.txt | + | old | /?fi=le&%#2 . txt | # %ab ab?=ed | + | new | /upload | abc.txt | + | new | /strängé folder (duplicate #2 &) | strängé file (duplicate #2 &) | + | new | /C++ folder | C++ file.cpp | + | new | /नेपाली | नेपाली | + | new | /folder #2.txt | file #2.txt | + | new | /folder ?2.txt | file ?2.txt | + | new | /?fi=le&%#2 . txt | # %ab ab?=ed | + + @personalSpace + Examples: + | dav_version | folder_name | file_name | + | spaces | /upload | abc.txt | + | spaces | /strängé folder (duplicate #2 &) | strängé file (duplicate #2 &) | + | spaces | /C++ folder | C++ file.cpp | + | spaces | /नेपाली | नेपाली | + | spaces | /folder #2.txt | file #2.txt | + | spaces | /folder ?2.txt | file ?2.txt | + | spaces | /?fi=le&%#2 . txt | # %ab ab?=ed | + + + Scenario Outline: Upload chunked file with TUS + Given using DAV path + When user "Alice" uploads file with content "uploaded content" in 3 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API + Then the content of file "/myChunkedFile.txt" for user "Alice" should be "uploaded content" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Upload 1 byte chunks with TUS + Given using DAV path + When user "Alice" uploads file with content "0123456789" in 10 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API + Then the content of file "/myChunkedFile.txt" for user "Alice" should be "0123456789" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: Upload to overwriting a file + Given using DAV path + And user "Alice" has uploaded file with content "original content" to "textfile.txt" + When user "Alice" uploads file with content "overwritten content" to "textfile.txt" using the TUS protocol on the WebDAV API + Then the content of file "textfile.txt" for user "Alice" should be "overwritten content" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: upload a file and no version is available + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to "/upload.txt" using the TUS protocol on the WebDAV API + Then the version folder of file "/upload.txt" for user "Alice" should contain "0" elements + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: upload a file twice and versions are available + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to "/upload.txt" using the TUS protocol on the WebDAV API + And user "Alice" uploads file with content "re-uploaded content" to "/upload.txt" using the TUS protocol on the WebDAV API + Then the version folder of file "/upload.txt" for user "Alice" should contain "1" element + And the content of file "/upload.txt" for user "Alice" should be "re-uploaded content" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: upload a file in chunks with TUS and no version is available + Given using DAV path + When user "Alice" uploads file with content "0123456789" in 10 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API + Then the version folder of file "/myChunkedFile.txt" for user "Alice" should contain "0" elements + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: upload a twice file in chunks with TUS and versions are available + Given using DAV path + When user "Alice" uploads file with content "0123456789" in 10 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API + And user "Alice" uploads file with content "01234" in 5 chunks to "/myChunkedFile.txt" using the TUS protocol on the WebDAV API + Then the version folder of file "/myChunkedFile.txt" for user "Alice" should contain "1" elements + And the content of file "/myChunkedFile.txt" for user "Alice" should be "01234" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: upload a file with invalid-name + Given using DAV path + When user "Alice" creates a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 100 | + | Upload-Metadata | filename | + | Tus-Resumable | 1.0.0 | + Then the HTTP status code should be "412" + And the following headers should not be set + | header | + | Location | + And as "Alice" file should not exist + Examples: + | dav_version | file_name | metadata | + | old | " " | IA== | + | old | "filewithLF-and-CR\r\n" | ZmlsZXdpdGhMRi1hbmQtQ1INCgo= | + | old | "folder/file" | Zm9sZGVyL2ZpbGU= | + | old | "my\\file" | bXkMaWxl | + | new | " " | IA== | + | new | "filewithLF-and-CR\r\n" | ZmlsZXdpdGhMRi1hbmQtQ1INCgo= | + | new | "folder/file" | Zm9sZGVyL2ZpbGU= | + | new | "my\\file" | bXkMaWxl | + + @personalSpace + Examples: + | dav_version | file_name | metadata | + | spaces | " " | IA== | + | spaces | "filewithLF-and-CR\r\n" | ZmlsZXdpdGhMRi1hbmQtQ1INCgo= | + | spaces | "folder/file" | Zm9sZGVyL2ZpbGU= | + | spaces | "my\\file" | bXkMaWxl | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFileMtime.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFileMtime.feature new file mode 100644 index 00000000000..c54b451f691 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFileMtime.feature @@ -0,0 +1,70 @@ +@api @skipOnOcV10 +Feature: upload file + As a user + I want the mtime of an uploaded file to be the creation date on upload source not the upload date + So that I can find files by their real creation date + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: upload file with mtime + Given using DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the TUS protocol on the WebDAV API + Then as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: upload file with future mtime + Given using DAV path + When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2129 04:18:13 GMT" using the TUS protocol on the WebDAV API + Then as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2129 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: upload a file with mtime in a folder + Given using DAV path + And user "Alice" has created folder "testFolder" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testFolder/file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the TUS protocol on the WebDAV API + Then as "Alice" the mtime of the file "/testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: overwriting a file changes its mtime + Given using DAV path + And user "Alice" has uploaded file with content "first time upload content" to "file.txt" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the TUS protocol on the WebDAV API + Then as "Alice" the mtime of the file "file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFileMtimeShares.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFileMtimeShares.feature new file mode 100644 index 00000000000..24772cfa410 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFileMtimeShares.feature @@ -0,0 +1,71 @@ +@api @files_sharing-app-required @skipOnOcV10 +Feature: upload file + As a user + I want the mtime of an uploaded file to be the creation date on upload source not the upload date + So that I can find files by their real creation date + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: upload file with mtime to a received share + Given using DAV path + And user "Alice" has created folder "/toShare" + And user "Alice" has shared folder "/toShare" with user "Brian" + And user "Brian" has accepted share "/toShare" offered by user "Alice" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API + Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT" + And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: upload file with mtime to a send share + Given using DAV path + And user "Alice" has created folder "/toShare" + And user "Alice" has shared folder "/toShare" with user "Brian" + And user "Brian" has accepted share "/toShare" offered by user "Alice" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API + Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT" + And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: overwriting a file with mtime in a received share + Given using DAV path + And user "Alice" has created folder "/toShare" + And user "Alice" has shared folder "/toShare" with user "Brian" + And user "Brian" has accepted share "/toShare" offered by user "Alice" + And user "Alice" has uploaded file with content "uploaded content" to "/toShare/file.txt" + When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API + Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT" + And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: overwriting a file with mtime in a send share + Given using DAV path + And user "Alice" has created folder "/toShare" + And user "Alice" has shared folder "/toShare" with user "Brian" + And user "Brian" has accepted share "/toShare" offered by user "Alice" + And user "Brian" has uploaded file with content "uploaded content" to "/Shares/toShare/file.txt" + When user "Alice" uploads file "filesForUpload/textfile.txt" to "/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API + Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT" + And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT" + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToMoveFolder.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToMoveFolder.feature new file mode 100644 index 00000000000..99bbf7caba9 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToMoveFolder.feature @@ -0,0 +1,28 @@ +@api @skipOnOcV10 +Feature: move folders + As a user + I want to be able to move and upload files/folders + So that I can organise my data structure + + Background: + Given user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: Uploading file into a moved folder + Given using DAV path + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test-moved" + And user "Alice" has moved folder "/test-moved" to "/test/test-moved" + When user "Alice" uploads file with content "uploaded content" to "/test/test-moved/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Alice" file "/test/test-moved/textfile.txt" should exist + And the content of file "/test/test-moved/textfile.txt" for user "Alice" should be "uploaded content" + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToNonExistingFolder.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToNonExistingFolder.feature new file mode 100644 index 00000000000..22fcf5d3862 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToNonExistingFolder.feature @@ -0,0 +1,67 @@ +@api @skipOnOcV10 +Feature: upload file + As a user + I want to try uploading files to a nonexistent folder + So that I can check if the uploading works in such case + + Background: + Given using OCS API version "1" + And the administrator has set the default folder for received shares to "Shares" + And user "Alice" has been created with default attributes and without skeleton files + + + Scenario Outline: attempt to upload a file into a nonexistent folder inside shares + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Alice" folder "/Shares/FOLDER/" should not exist + And as "Alice" file "/Shares/FOLDER/textfile.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: attempt to upload a file into a nonexistent folder + Given using DAV path + When user "Alice" uploads file with content "uploaded content" to "/nonExistentFolder/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Alice" folder "/nonExistentFolder" should not exist + And as "Alice" file "/nonExistentFolder/textfile.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + @personalSpace + Examples: + | dav_version | + | spaces | + + + Scenario Outline: attempt to upload a file into a nonexistent folder within correctly received share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/nonExistentFolder/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Brian" folder "/Shares/FOLDER/nonExistentFolder" should not exist + And as "Brian" file "/Shares/FOLDER/nonExistentFolder/textfile.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: attempt to upload a file into a nonexistent folder within correctly received read only share + Given using DAV path + And user "Brian" has been created with default attributes and without skeleton files + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/nonExistentFolder/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Brian" folder "/Shares/FOLDER/nonExistentFolder" should not exist + And as "Brian" file "/Shares/FOLDER/nonExistentFolder/textfile.txt" should not exist + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature new file mode 100644 index 00000000000..6e60e4a5b89 --- /dev/null +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature @@ -0,0 +1,296 @@ +@api @files_sharing-app-required @skipOnOcV10 + +Feature: upload file to shared folder + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + + + Scenario Outline: Uploading file to a received share folder + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Alice" file "/FOLDER/textfile.txt" should exist + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "uploaded content" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Uploading file to a user read/write share folder works + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "change" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Alice" file "/FOLDER/textfile.txt" should exist + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "uploaded content" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Uploading a file into a group share as share receiver + Given using DAV path + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "FOLDER" with group "grp1" with permissions "change" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Alice" file "/FOLDER/textfile.txt" should exist + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "uploaded content" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Overwrite file to a received share folder + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has uploaded file with content "original content" to "/FOLDER/textfile.txt" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file with content "overwritten content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Alice" file "/FOLDER/textfile.txt" should exist + And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "overwritten content" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: attempt to upload a file into a folder within correctly received read only share + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API + Then as "Brian" file "/Shares/FOLDER/textfile.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Upload a file to shared folder with checksum should return the checksum in the propfind for sharee + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt + | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= | + And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + When user "Brian" requests the checksum of "/Shares/FOLDER/textFile.txt" via propfind + Then the HTTP status code should be "207" + And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Upload a file to shared folder with checksum should return the checksum in the download header for sharee + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt + | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= | + And user "Alice" has uploaded file with checksum "SHA1 8cb2237d069ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + When user "Brian" downloads file "/Shares/FOLDER/textFile.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Sharer shares a file with correct checksum should return the checksum in the propfind for sharee + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + And user "Alice" has shared file "/textFile.txt" with user "Brian" + And user "Brian" has accepted share "/textFile.txt" offered by user "Alice" + When user "Brian" requests the checksum of "/Shares/textFile.txt" via propfind + Then the HTTP status code should be "207" + And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Sharer shares a file with correct checksum should return the checksum in the download header for sharee + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API + And user "Alice" has shared file "/textFile.txt" with user "Brian" + And user "Brian" has accepted share "/textFile.txt" offered by user "Alice" + When user "Brian" downloads file "/Shares/textFile.txt" using the WebDAV API + Then the HTTP status code should be "200" + And the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Sharee uploads a file to a received share folder with correct checksum + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" creates a new TUS resource on the WebDAV API with these headers: + | Tus-Resumable | 1.0.0 | + | Upload-Length | 16 | + # L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 is the base64 encode of /Shares/FOLDER/textFile.txt + | Upload-Metadata | filename L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 | + And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "uploaded content" using the TUS protocol on the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/FOLDER/textFile.txt" should exist + And the content of file "/FOLDER/textFile.txt" for user "Alice" should be "uploaded content" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Sharee uploads a file to a received share folder with wrong checksum should not work + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + When user "Brian" creates a new TUS resource on the WebDAV API with these headers: + | Tus-Resumable | 1.0.0 | + | Upload-Length | 16 | + # L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 is the base64 encode of /Shares/FOLDER/textFile.txt + | Upload-Metadata | filename L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 | + And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e8c" to the last created TUS Location with offset "0" and content "uploaded content" using the TUS protocol on the WebDAV API + Then the HTTP status code should be "406" + And as "Alice" file "/FOLDER/textFile.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Sharer uploads a file to shared folder with wrong correct checksum should not work + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 5 | + # L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt + | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= | + When user "Alice" uploads file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513954" to the last created TUS Location with offset "0" and content "uploaded content" using the TUS protocol on the WebDAV API + Then the HTTP status code should be "406" + And as "Alice" file "/FOLDER/textFile.txt" should not exist + And as "Brian" file "/Shares/FOLDER/textFile.txt" should not exist + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Sharer uploads a chunked file with correct checksum and share it with sharee should work + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 10 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API + And user "Alice" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API + And user "Alice" shares file "textFile.txt" with user "Brian" using the sharing API + And user "Brian" accepts share "/textFile.txt" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the content of file "/Shares/textFile.txt" for user "Brian" should be "0123456789" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Sharee uploads a chunked file with correct checksum to a received share folder should work + Given using DAV path + And user "Alice" has created folder "/FOLDER" + And user "Alice" has shared folder "/FOLDER" with user "Brian" + And user "Brian" has accepted share "/FOLDER" offered by user "Alice" + And user "Brian" creates a new TUS resource on the WebDAV API with these headers: + | Tus-Resumable | 1.0.0 | + | Upload-Length | 10 | + # L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 is the base64 encode of /Shares/FOLDER/textFile.txt + | Upload-Metadata | filename L1NoYXJlcy9GT0xERVIvdGV4dGZpbGUudHh0 | + When user "Brian" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API + And user "Brian" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/FOLDER/textFile.txt" should exist + And the content of file "/FOLDER/textFile.txt" for user "Alice" should be "0123456789" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and correct checksum + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 16 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded file with checksum "SHA1 c1dab0c0864b6ac9bdd3743a1408d679f1acd823" to the last created TUS Location with offset "0" and content "original content" using the TUS protocol on the WebDAV API + And user "Alice" has shared file "/textFile.txt" with user "Brian" + And user "Brian" has accepted share "/textFile.txt" offered by user "Alice" + When user "Brian" overwrites recently shared file with offset "0" and data "overwritten content" with checksum "SHA1 fe990d2686a0fc86004efc31f5bf2475a45d4905" using the TUS protocol on the WebDAV API with these headers: + | Upload-Length | 19 | + # dGV4dEZpbGUudHh0 is the base64 encode of /Shares/textFile.txt + | Upload-Metadata | filename L1NoYXJlcy90ZXh0RmlsZS50eHQ= | + Then the HTTP status code should be "204" + And the content of file "/textFile.txt" for user "Alice" should be "overwritten content" + Examples: + | dav_version | + | old | + | new | + + + Scenario Outline: Sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and invalid checksum + Given using DAV path + And user "Alice" has created a new TUS resource on the WebDAV API with these headers: + | Upload-Length | 16 | + # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt + | Upload-Metadata | filename dGV4dEZpbGUudHh0 | + And user "Alice" has uploaded file with checksum "SHA1 c1dab0c0864b6ac9bdd3743a1408d679f1acd823" to the last created TUS Location with offset "0" and content "original content" using the TUS protocol on the WebDAV API + And user "Alice" has shared file "/textFile.txt" with user "Brian" + And user "Brian" has accepted share "/textFile.txt" offered by user "Alice" + When user "Brian" overwrites recently shared file with offset "0" and data "overwritten content" with checksum "SHA1 fe990d2686a0fc86004efc31f5bf2475a45d4906" using the TUS protocol on the WebDAV API with these headers: + | Upload-Length | 19 | + # dGV4dEZpbGUudHh0 is the base64 encode of /Shares/textFile.txt + | Upload-Metadata | filename L1NoYXJlcy90ZXh0RmlsZS50eHQ= | + Then the HTTP status code should be "406" + And the content of file "/textFile.txt" for user "Alice" should be "original content" + Examples: + | dav_version | + | old | + | new |