Merge pull request #37672 from owncloud/retag-reva-issue-249

[tests-only] retag reva issue 249 with the correct issue tags

tests/acceptance/features/apiShareCreateSpecial1/createShareExpirationDate.feature

@@ -1,4 +1,4 @@
-@api @files_sharing-app-required @skipOnOcis @issue-ocis-reva-41 @issue-ocis-reva-243 @issue-ocis-reva-249 @issue-ocis-reva-333
+@api @files_sharing-app-required @skipOnOcis @toImplementOnOCIS @issue-ocis-reva-41 @issue-ocis-reva-243 @issue-ocis-reva-333
 Feature: a default expiration date can be specified for shares with users or groups
 
   Background:

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 @toFixOnOCIS @issue-ocis-reva-243
 Feature: sharing
 
-  @issue-ocis-reva-249
+  @skipOnOcis @toImplementOnOCIS @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 @toFixOnOCIS @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 @toFixOnOCIS @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 @toFixOnOCIS @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 @toFixOnOCIS @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 @toImplementOnOCIS @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 @toFixOnOCIS @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 @toFixOnOCIS @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 @toFixOnOCIS @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 @toImplementOnOCIS @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
@@ -160,6 +178,7 @@ Feature: sharing
       | /PARENT            | 1               | 200              | PARENT         |
       | /PARENT            | 2               | 404              | PARENT         |
 
+  @skipOnOcis @toFixOnOCIS @issue-ocis-reva-243 @issue-ocis-reva-364
   Scenario Outline: An individual share recipient tries to delete the share
     Given using OCS API version "<ocs_api_version>"
     And user "Alice" has been created with default attributes and skeleton files

tests/acceptance/features/apiShareOperations/gettingShares.feature

@@ -93,7 +93,8 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-  @skipOnOcis @smokeTest @issue-ocis-reva-249
+  @skipOnOcis @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 "<ocs_api_version>"
     And user "Alice" has moved file "/textfile0.txt" to "/file_to_share.txt"
@@ -123,6 +124,37 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
+  @skipOnOcis-OC-Storage @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
+    Given using OCS API version "<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 the info of 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"
+    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            | /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             |
+
   @skipOnOcis @issue-ocis-reva-21
   Scenario Outline: Get a share with a user that didn't receive the share
     Given using OCS API version "<ocs_api_version>"

tests/acceptance/features/apiShareReshare3/reShareWithExpiryDate.feature

@@ -1,4 +1,4 @@
-@api @files_sharing-app-required @skipOnOcis @issue-ocis-reva-243 @issue-ocis-reva-249
+@api @files_sharing-app-required @skipOnOcis @toImplementOnOCIS @issue-ocis-reva-243
 Feature: resharing a resource with an expiration date
 
   Background:

tests/acceptance/features/apiShareUpdate/updateShare.feature

@@ -112,7 +112,7 @@ Feature: sharing
       | 1               | 200              | create,delete |
       | 2               | 400              | create,delete |
 
-  @skipOnFilesClassifier @issue-files-classifier-291 @skipOnOcis @issue-ocis-reva-249 @issue-ocis-reva-243
+  @skipOnFilesClassifier @issue-files-classifier-291 @skipOnOcis @toFixOnOCIS @issue-ocis-reva-243
   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 |
@@ -142,7 +142,7 @@ Feature: sharing
     And as "Alice" folder "/folder1/folder2" should not exist
     And as "Carol" folder "/folder2" should exist
 
-  @skipOnOcis @issue-ocis-reva-243 @issue-ocis-reva-249
+  @skipOnOcis @toFixOnOCIS @issue-ocis-reva-243
   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 |
@@ -172,8 +172,8 @@ Feature: sharing
     And as "Alice" folder "/Alice-folder/folder2" should not exist
     And as "Carol" folder "/Carol-folder/folder2" should exist
 
-  @skipOnOcV10 @skipOnOcis-EOS-Storage @issue-ocis-reva-249
-  Scenario: cannot get information of a specific share
+  @skipOnOcV10 @skipOnOcis-EOS-Storage @toFixOnOCIS @issue-ocis-reva-243
+  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    |
@@ -209,9 +209,9 @@ Feature: sharing
     And as "Alice" folder "/Alice-folder/folder2" should exist
     And as "Carol" folder "/Carol-folder/folder2" should not exist
 
-  @skipOnOcV10 @skipOnOcis-OC-Storage @issue-ocis-reva-249
+  @skipOnOcV10 @skipOnOcis-OC-Storage @toFixOnOCIS @issue-ocis-reva-243
   #same as previous Scenario but without displayname_owner because EOS does not report it
-  Scenario: cannot get information of a specific share
+  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    |
@@ -369,7 +369,7 @@ Feature: sharing
       | 1               | 200              |
       | 2               | 404              |
 
-  @skipOnOcis @issue-ocis-reva-194 @issue-ocis-reva-243 @issue-ocis-reva-249
+  @skipOnOcis @toImplementOnOCIS @issue-ocis-reva-194 @issue-ocis-reva-41
   Scenario Outline: Editing share permission of existing share is forbidden when sharing with groups is forbidden
     Given using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
@@ -394,7 +394,7 @@ Feature: sharing
       | 1               | 200              |
       | 2               | 400              |
 
-  @skipOnOcis @issue-ocis-reva-194 @issue-ocis-reva-243 @issue-ocis-reva-249
+  @skipOnOcis @toImplementOnOCIS @issue-ocis-reva-194 @issue-ocis-reva-41
   Scenario Outline: Deleting group share is allowed when sharing with groups is forbidden
     Given using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
@@ -410,7 +410,7 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-  @skipOnOcis @issue-ocis-reva-243 @issue-ocis-reva-249
+  @skipOnOcis @toImplementOnOCIS @issue-ocis-reva-194 @issue-ocis-reva-41
   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 "<ocs_api_version>"
     And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
@@ -438,7 +438,7 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-  @issue-37217 @skipOnOcis @issue-ocis-reva-243 @issue-ocis-reva-249
+  @issue-37217 @skipOnOcis @toImplementOnOCIS @issue-ocis-reva-194 @issue-ocis-reva-41
   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 "<ocs_api_version>"
     And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"