retag reva issue 249 with the correct issue tags

owncloud · Jul 9, 2020 · 619e93c · 619e93c
1 parent 3861d0a
commit 619e93c
Show file tree

Hide file tree

Showing 2 changed files with 119 additions and 7 deletions.
diff --git a/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature b/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
@@ -1,7 +1,7 @@
-@api @files_sharing-app-required @skipOnOcis @issue-ocis-reva-21 @issue-ocis-reva-243
+@api @files_sharing-app-required @issue-ocis-reva-243
 Feature: sharing
 
-  @issue-ocis-reva-249
+  @skipOnOcis @issue-ocis-reva-194
   Scenario Outline: Delete all group shares
     Given these users have been created with default attributes and skeleton files:
       | username |
@@ -21,7 +21,7 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-  @smokeTest @issue-ocis-reva-249
+  @smokeTest @skipOnOcis @issue-ocis-reva-356
   Scenario Outline: delete a share
     Given user "Alice" has been created with default attributes and skeleton files
     And user "Brian" has been created with default attributes and without skeleton files
@@ -36,21 +36,35 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
+  @skipOnOcV10 @smokeTest @issue-ocis-reva-356
+  #after fixing all issues delete this Scenario and use the one above
+  Scenario Outline: delete a share
+    Given user "Alice" has been created with default attributes and skeleton files
+    And user "Brian" has been created with default attributes and without skeleton files
+    And using OCS API version "<ocs_api_version>"
+    And user "Alice" has shared file "textfile0.txt" with user "Brian"
+    When user "Alice" deletes the last share using the sharing API
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
   Scenario: orphaned shares
     Given using OCS API version "1"
     And these users have been created with default attributes and without skeleton files:
       | username |
       | Alice    |
       | Brian    |
-    And a new browser session for "Alice" has been started
     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
+  @smokeTest @files_trashbin-app-required @skipOnOcis @issue-ocis-reva-243
   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 been created with default attributes and skeleton files
@@ -65,7 +79,7 @@ Feature: sharing
     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
+  @files_trashbin-app-required @skipOnOcis @issue-ocis-reva-243
   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 been created with default attributes and skeleton files
@@ -83,7 +97,7 @@ Feature: sharing
     And as "Brian" folder "/sub" should exist in the trashbin
     And as "Brian" file "/sub/shared_file.txt" should exist in the trashbin
 
-  @smokeTest
+  @smokeTest @skipOnOcis @issue-ocis-reva-194
   Scenario: unshare from self
     And group "grp1" has been created
     And these users have been created with default attributes and without skeleton files:
@@ -101,6 +115,7 @@ Feature: sharing
     And the etag of element "/" of user "Brian" should have changed
     And the etag of element "/PARENT" of user "Carol" should not have changed
 
+  @skipOnOcis @issue-ocis-reva-243
   Scenario: sharee of a read-only share folder tries to delete the shared folder
     Given using OCS API version "1"
     And user "Alice" has been created with default attributes and skeleton files
@@ -112,6 +127,7 @@ Feature: sharing
     Then the HTTP status code should be "403"
     And as "Brian" file "/shared/shared_file.txt" should exist
 
+  @skipOnOcis @issue-ocis-reva-243
   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 been created with default attributes and skeleton files
@@ -123,6 +139,7 @@ Feature: sharing
     Then the HTTP status code should be "403"
     And as "Alice" file "/shared/shared_file.txt" should exist
 
+  @skipOnOcis @issue-ocis-reva-243
   Scenario: sharee of an upload-only shared folder tries to delete their file in the folder
     Given using OCS API version "1"
     And these users have been created with default attributes and without skeleton files:
@@ -136,6 +153,7 @@ Feature: sharing
     Then the HTTP status code should be "403"
     And as "Alice" file "/shared/textfile.txt" should exist
 
+  @skipOnOcis @issue-ocis-reva-194
   Scenario Outline: A Group share recipient tries to delete the share
     Given using OCS API version "<ocs_api_version>"
     And group "grp1" has been created

diff --git a/tests/acceptance/features/apiShareUpdate/updateShare.feature b/tests/acceptance/features/apiShareUpdate/updateShare.feature
@@ -239,6 +239,100 @@ Feature: sharing
     And as "Alice" folder "/Alice-folder/folder2" should exist
     And as "Carol" folder "/Carol-folder/folder2" should not exist
 
+  @skipOnOcis @issue-ocis-reva-243 @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 "<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 "<ocs_status_code>"
+    And the OCS status message should be ""
+    And the HTTP status code should be "200"
+    Then 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                 | home::Alice          |
+      | storage                    | A_STRING             |
+      | file_source                | A_STRING             |
+      | file_target                | /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 |  |
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
+  @skipOnOcV10 @issue-ocis-reva-243 @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 above
+  Scenario Outline: API responds with a full set of parameters when owner changes the permission of a share
+    Given using OCS API version "<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 "<ocs_status_code>"
+    And the last share_id should not be included in the response
+    And the OCS status message should be "OK"
+    And the HTTP status code should be "200"
+    Then 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 |               |
+      | state                      | 0             |
+      | item_source                |               |
+      | path                       |               |
+      | item_type                  |               |
+      | mimetype                   |               |
+      | storage_id                 |               |
+      | storage                    | 0             |
+      | file_source                |               |
+      | file_target                |               |
+      | share_with                 | %username%    |
+      | share_with_displayname     | %displayname% |
+      | share_with_additional_info |               |
+      | mail_send                  | 0             |
+      | name                       |               |
+    And the fields of the last response should not include
+      | attributes |  |
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
   @skipOnOcis @issue-ocis-reva-194 @issue-ocis-reva-243
   Scenario Outline: Increasing permissions is allowed for owner
     Given using OCS API version "<ocs_api_version>"