do not delete user home "under the hood"

[phil-davis]

On top of #755

Do not delete user data "under the hood" in the acceptance tests. The Provisioning API "delete user" endpoint should be doing that.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
No Duplication information

[phil-davis]

Tests that fail include:
https://drone.owncloud.com/owncloud/ocis/1076/14/7

  Scenario: delete a single file from the trashbin                                                                 # /drone/src/ocis/tests/acceptance/features/apiOcisSpecific/apiTrashbin-trashbinDelete.feature:44
    Given user "Alice" has deleted file "/textfile0.txt"                                                           # FeatureContext::userHasDeletedFile()
    And user "Alice" has deleted file "/textfile1.txt"                                                             # FeatureContext::userHasDeletedFile()
    And user "Alice" has deleted file "/PARENT/parent.txt"                                                         # FeatureContext::userHasDeletedFile()
    And user "Alice" has deleted file "/PARENT/CHILD/child.txt"                                                    # FeatureContext::userHasDeletedFile()
    When user "Alice" deletes the file with original path "textfile1.txt" from the trashbin using the trashbin API # TrashbinContext::deleteFileFromTrashbin()
      Expected to delete exactly one item from the trashbin but 3 were deleted
      Failed asserting that 3 matches expected 1.
    Then the HTTP status code should be "405"                                                                      # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And as "Alice" the file with original path "/textfile1.txt" should exist in the trashbin                       # TrashbinContext::elementIsInTrashCheckingOriginalPath()
    But as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin                       # TrashbinContext::elementIsInTrashCheckingOriginalPath()
    And as "Alice" the file with original path "/PARENT/parent.txt" should exist in the trashbin                   # TrashbinContext::elementIsInTrashCheckingOriginalPath()
    And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should exist in the trashbin              # TrashbinContext::elementIsInTrashCheckingOriginalPath()

It looks like there are 2 files "leftover" still in the trashbin from the previous scenario(s).

https://drone.owncloud.com/owncloud/ocis/1076/17/7

  Scenario Outline: sharee file favorite state should not change the favorite state of sharer # /srv/app/testrunner/tests/acceptance/features/apiFavorites/favoritesSharingToShares.feature:67
    Given using <dav_version> DAV path                                                        # FeatureContext::usingOldOrNewDavPath()
    And user "Brian" has been created with default attributes and without skeleton files      # FeatureContext::userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
    And user "Alice" has shared file "/PARENT/parent.txt" with user "Brian"                   # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Brian" has accepted share "/parent.txt" offered by user "Alice"                 # FeatureContext::userHasReactedToShareOfferedBy()
    When user "Brian" favorites element "/Shares/parent.txt" using the WebDAV API             # FavoritesContext::userFavoritesElementUsingWebDavApi()
    Then the HTTP status code should be "207"                                                 # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And as user "Alice" file "/PARENT/parent.txt" should not be favorited                     # FavoritesContext::asUserFileShouldNotBeFavorited()

    Examples:
      | dav_version |
      | old         |
      | new         |
        HTTP status code 500 is not the expected value 207
        Failed asserting that 500 matches expected '207'.

Not sure why just the "new dav_version" scenario is failing. Maybe some "favorite" or "sharing" state of the share received by Brian is still remembered from the "old dav_version" scenario?

[phil-davis]

https://drone.owncloud.com/owncloud/ocis/1076/21/7

  Background:                                                                          # /srv/app/testrunner/tests/acceptance/features/apiShareManagementToShares/acceptSharesToSharesFolder.feature:7
    Given the administrator has set the default folder for received shares to "Shares" # OccContext::theAdministratorHasSetTheDefaultFolderForReceivedSharesTo()
    And parameter "shareapi_auto_accept_share" of app "core" has been set to "no"      # AppConfigurationContext::serverParameterHasBeenSetTo()
    And using OCS API version "1"                                                      # FeatureContext::usingOcsApiVersion()
    And using new DAV path                                                             # FeatureContext::usingOldOrNewDavPath()
    And these users have been created with default attributes and skeleton files:      # FeatureContext::theseUsersHaveBeenCreated()
      | username |
      | Alice    |
      | Brian    |
      Could not upload skeleton file (Exception)

Something goes wrong uploading a skeleton file. I raised core PR owncloud/core#38051 so we can see the exception better.

[phil-davis]

https://drone.owncloud.com/owncloud/ocis/1076/23/7

  Scenario Outline: Update of reshare can increase permissions to the maximum allowed                         # /srv/app/testrunner/tests/acceptance/features/apiShareReshareToShares3/reShareUpdate.feature:28
    Given using OCS API version "<ocs_api_version>"                                                           # FeatureContext::usingOcsApiVersion()
    And user "Alice" has created folder "/TMP"                                                                # FeatureContext::userHasCreatedFolder()
    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"   # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Brian" has accepted share "/TMP" offered by user "Alice"                                        # FeatureContext::userHasReactedToShareOfferedBy()
    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"           # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Carol" has accepted share "/TMP" offered by user "Brian"                                        # FeatureContext::userHasReactedToShareOfferedBy()
    When user "Brian" updates the last share using the sharing API with                                       # FeatureContext::userUpdatesTheLastShareWith()
      | permissions | share,create,update,read |
    Then the OCS status code should be "<ocs_status_code>"                                                    # OCSContext::theOCSStatusCodeShouldBe()
    And the HTTP status code should be "200"                                                                  # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt" # FeatureContext::userShouldBeAbleToUploadFileTo()

    Examples:
      | ocs_api_version | ocs_status_code |
      | 1               | 100             |
        Sharing::isUserOrGroupInSharedData Exception parsing response body: "<?xml version="1.0" encoding="UTF-8"?>
        <ocs><meta><status>error</status><statuscode>996</statuscode><message>grpc stat request failed</message></meta></ocs><?xml version="1.0" encoding="UTF-8"?>
        <ocs><meta><status>error</status><statuscode>996</statuscode><message>fixme</message></meta></ocs>" (Exception)
      | 2               | 200             |
        Sharing::userHasReactedToShareOfferedBy could not accepted share to Brian by Alice
        Failed asserting that 500 matches expected 200.

More scenarios fail with 500 status when trying to accept a share.

[phil-davis]

https://drone.owncloud.com/owncloud/ocis/1076/24/7

  Scenario: Remove a file                                                                              # /srv/app/testrunner/tests/acceptance/features/apiVersions/fileVersions.feature:52
    Given user "Alice" has uploaded file "filesForUpload/davtest.txt" to "/davtest.txt"                # FeatureContext::userHasUploadedAFileTo()
    And user "Alice" has uploaded file "filesForUpload/davtest.txt" to "/davtest.txt"                  # FeatureContext::userHasUploadedAFileTo()
    And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element          # FilesVersionsContext::theVersionFolderOfFileShouldContainElements()
      could not find 1 version element(s) in 
      <?xml version="1.0" encoding="utf-8"?>
      <d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns"><d:response><d:href>/remote.php/dav/meta/MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3Ojc0ZTkzNjI1LTVhNmQtNGRjMi1hNTM4LTFkNGViZGJmNTljNw==/v/</d:href><d:propstat><d:prop><d:getetag>"ce0eca8bdd0b1172cfcf547e130211dd"</d:getetag></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response><d:response><d:href>/remote.php/dav/meta/MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3Ojc0ZTkzNjI1LTVhNmQtNGRjMi1hNTM4LTFkNGViZGJmNTljNw==/v/1603951478</d:href><d:propstat><d:prop><d:getetag/></d:prop><d:status>HTTP/1.1 404 Not Found</d:status></d:propstat></d:response><d:response><d:href>/remote.php/dav/meta/MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3Ojc0ZTkzNjI1LTVhNmQtNGRjMi1hNTM4LTFkNGViZGJmNTljNw==/v/1603951489</d:href><d:propstat><d:prop><d:getetag/></d:prop><d:status>HTTP/1.1 404 Not Found</d:status></d:propstat></d:response></d:multistatus>
      
      Failed asserting that 2 matches expected '1'.

There might be versions "left behind" from a previous scenario.

[phil-davis]

Some more etag tests fail.

https://drone.owncloud.com/owncloud/ocis/1076/25/7

  Scenario Outline: as share receiver renaming a file inside a folder changes its etag for all collaborators    # /srv/app/testrunner/tests/acceptance/features/apiWebdavEtagPropagation1/moveFileFolder.feature:115
    Given user "Brian" has been created with default attributes and without skeleton files                      # FeatureContext::userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
    And the administrator has set the default folder for received shares to "Shares"                            # OccContext::theAdministratorHasSetTheDefaultFolderForReceivedSharesTo()
    And parameter "shareapi_auto_accept_share" of app "core" has been set to "no"                               # AppConfigurationContext::serverParameterHasBeenSetTo()
    And using <dav_version> DAV path                                                                            # FeatureContext::usingOldOrNewDavPath()
    And user "Alice" has created folder "/upload"                                                               # FeatureContext::userHasCreatedFolder()
    And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"                    # FeatureContext::userHasUploadedAFileWithContentTo()
    And user "Alice" has shared folder "/upload" with user "Brian"                                              # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Brian" has accepted share "/upload" offered by user "Alice"                                       # FeatureContext::userHasReactedToShareOfferedBy()
    And user "Alice" has stored etag of element "/"                                                             # WebDavPropertiesContext::userHasStoredEtagOfElement()
    And user "Alice" has stored etag of element "/upload"                                                       # WebDavPropertiesContext::userHasStoredEtagOfElement()
    And user "Brian" has stored etag of element "/"                                                             # WebDavPropertiesContext::userHasStoredEtagOfElement()
    And user "Brian" has stored etag of element "/Shares"                                                       # WebDavPropertiesContext::userHasStoredEtagOfElement()
    And user "Brian" has stored etag of element "/Shares/upload"                                                # WebDavPropertiesContext::userHasStoredEtagOfElement()
    When user "Brian" moves file "/Shares/upload/file.txt" to "/Shares/upload/renamed.txt" using the WebDAV API # FeatureContext::userMovesFileUsingTheAPI()
    Then these etags should have changed:                                                                       # WebDavPropertiesContext::theseEtagsShouldHaveChanged()
      | user  | path           |
      | Alice | /              |
      | Alice | /upload        |
      | Brian | /              |
      | Brian | /Shares        |
      | Brian | /Shares/upload |

    Examples:
      | dav_version |
      | old         |
        WebDav::listFolderAndReturnResponseXml Received empty response where XML was expected (Exception)
      | new         |
        WebDav::listFolderAndReturnResponseXml Received empty response where XML was expected (Exception)

Somehow related to left-over shares from previous scenarios, or?

[phil-davis]

Note: 2021-02-22 - this is blocked until #755 makes some progress.
core PR owncloud/core#38078 is also related.

[phil-davis]

This is being done in issue #1985
PR #1962 improve the cleanup of user files in OCIS storage.