From f29f2bbcd3c263694f1fff14ed725566c67e85eb Mon Sep 17 00:00:00 2001 From: Hari Bhandari Date: Fri, 14 Jun 2019 10:25:51 +0545 Subject: [PATCH 1/7] webui sharing public without skeleton --- .drone.yml | 2 + .../features/bootstrap/Provisioning.php | 2 +- .../shareByPublicLink.feature | 203 +++++++++++++----- 3 files changed, 157 insertions(+), 50 deletions(-) diff --git a/.drone.yml b/.drone.yml index 7db638bb3712..cf220b2b8b82 100644 --- a/.drone.yml +++ b/.drone.yml @@ -1370,6 +1370,8 @@ matrix: OWNCLOUD_LOG: true INSTALL_TESTING_APP: true USE_EMAIL: true + USE_FEDERATED_SERVER: true + FEDERATION_OC_VERSION: daily-stable10-qa - PHP_VERSION: 7.1 TEST_SUITE: selenium diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php index 605e9579fcbe..f6d54b67570f 100644 --- a/tests/acceptance/features/bootstrap/Provisioning.php +++ b/tests/acceptance/features/bootstrap/Provisioning.php @@ -3085,7 +3085,7 @@ public function getDisabledApps() { * * @return string */ - public function popSkeletonDirectoryConfig($baseUrl) { + public function popSkeletonDirectoryConfig($baseUrl = null) { $this->runOcc( ["config:system:get skeletondirectory"], null, null, $baseUrl diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature index 4f882d7b7dc7..4ab228510dbd 100644 --- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature +++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature @@ -9,17 +9,21 @@ Feature: Share by public link So that public sharing is limited according to organization policy Background: - Given user "user1" has been created with default attributes and skeleton files - And user "user1" has logged in using the webUI + Given user "user1" has been created with default attributes and without skeleton files @smokeTest Scenario: simple sharing by public link + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI And the public accesses the last created public link using the webUI Then file "lorem.txt" should be listed on the webUI @skipOnOcV10.0.3 @feature_was_changed_in_10.0.4 Scenario: creating a public link with read & write permissions makes it possible to delete files via the link + Given user "user2" has been created with default attributes and skeleton files + And user "user2" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | permission | read-write | And the public accesses the last created public link using the webUI @@ -34,6 +38,9 @@ Feature: Share by public link @skipOnOcV10.0.3 @feature_was_changed_in_10.0.4 Scenario: creating a public link with read permissions only makes it impossible to delete files via the link + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | permission | read | And the public accesses the last created public link using the webUI @@ -42,92 +49,119 @@ Feature: Share by public link @skipOnINTERNETEXPLORER @skipOnMICROSOFTEDGE @issue-30392 Scenario: mount public link Given using server "REMOTE" - And user "user2" has been created with default attributes and skeleton files + And user "user2" has been created with default attributes and without skeleton files + And using server "LOCAL" + And user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI And the user logs out of the webUI And the public accesses the last created public link using the webUI And the public adds the public link to "%remote_server%" as user "user2" with password "%alt2%" using the webUI And the user accepts the offered remote shares using the webUI - Then folder "simple-folder (2)" should be listed on the webUI - When the user opens folder "simple-folder (2)" using the webUI + Then folder "simple-folder" should be listed on the webUI + When the user opens folder "simple-folder" using the webUI Then file "lorem.txt" should be listed on the webUI - And the content of "lorem.txt" on the remote server should be the same as the original "simple-folder/lorem.txt" + And the content of file "simple-folder/lorem.txt" for user "user2" on server "REMOTE" should be "original content" And it should not be possible to delete file "lorem.txt" using the webUI @skipOnINTERNETEXPLORER @skipOnMICROSOFTEDGE @issue-30392 Scenario: mount public link and overwrite file Given using server "REMOTE" - And user "user2" has been created with default attributes and skeleton files + And user "user2" has been created with default attributes and without skeleton files + And using server "LOCAL" + And user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | permission | read-write | And the user logs out of the webUI And the public accesses the last created public link using the webUI And the public adds the public link to "%remote_server%" as user "user2" with password "%alt2%" using the webUI And the user accepts the offered remote shares using the webUI - Then folder "simple-folder (2)" should be listed on the webUI - When the user opens folder "simple-folder (2)" using the webUI + Then folder "simple-folder" should be listed on the webUI + When the user opens folder "simple-folder" using the webUI Then file "lorem.txt" should be listed on the webUI - And the content of "lorem.txt" on the remote server should be the same as the original "simple-folder/lorem.txt" + And the content of file "simple-folder/lorem.txt" for user "user2" on server "REMOTE" should be "original content" When the user uploads overwriting file "lorem.txt" using the webUI and retries if the file is locked Then file "lorem.txt" should be listed on the webUI And the content of "lorem.txt" on the remote server should be the same as the local "lorem.txt" Scenario: public should be able to access a public link with correct password + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | password | pass123 | And the public accesses the last created public link with password "pass123" using the webUI Then file "lorem.txt" should be listed on the webUI Scenario: public should not be able to access a public link with wrong password + Given user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | password | pass123 | And the public tries to access the last created public link with wrong password "pass12" using the webUI Then the public should not get access to the publicly shared file Scenario: user shares a public link with folder longer than 64 chars and shorter link name - Given user "user1" has moved folder "simple-folder" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" - And the user has reloaded the current page of the webUI + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt" + And user "user1" has moved folder "simple-folder" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" using the webUI with | name | short_linkname | And the public accesses the last created public link using the webUI Then file "lorem.txt" should be listed on the webUI Scenario: user tries to create a public link with read only permission without entering share password while enforce password on read only public share is enforced - Given parameter "shareapi_enforce_links_password_read_only" of app "core" has been set to "yes" + Given user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI + And parameter "shareapi_enforce_links_password_read_only" of app "core" has been set to "yes" When the user tries to create a new public link for folder "simple-folder" using the webUI Then the user should see an error message on the public link share dialog saying "Passwords are enforced for link shares" And the public link should not have been generated Scenario: user tries to create a public link with read-write permission without entering share password while enforce password on read-write public share is enforced - Given parameter "shareapi_enforce_links_password_read_write" of app "core" has been set to "yes" + Given user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI + And parameter "shareapi_enforce_links_password_read_write" of app "core" has been set to "yes" When the user tries to create a new public link for folder "simple-folder" using the webUI with | permission | read-write | Then the user should see an error message on the public link share dialog saying "Passwords are enforced for link shares" And the public link should not have been generated Scenario: user tries to create a public link with write only permission without entering share password while enforce password on write only public share is enforced - Given parameter "shareapi_enforce_links_password_write_only" of app "core" has been set to "yes" + Given user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI + And parameter "shareapi_enforce_links_password_write_only" of app "core" has been set to "yes" When the user tries to create a new public link for folder "simple-folder" using the webUI with | permission | upload | Then the user should see an error message on the public link share dialog saying "Passwords are enforced for link shares" And the public link should not have been generated Scenario: user creates a public link with read-write permission without entering share password while enforce password on read only public share is enforced - Given parameter "shareapi_enforce_links_password_read_only" of app "core" has been set to "yes" + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file with content "test" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And parameter "shareapi_enforce_links_password_read_only" of app "core" has been set to "yes" When the user creates a new public link for folder "simple-folder" using the webUI with | permission | read-write | And the public accesses the last created public link using the webUI Then file "lorem.txt" should be listed on the webUI Scenario: public should be able to access the shared file through public link + Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "user1" has logged in using the webUI When the user creates a new public link for file 'lorem.txt' using the webUI And the public accesses the last created public link using the webUI - Then the text preview of the public link should contain "Lorem ipsum dolor sit amet, consectetur" + Then the text preview of the public link should contain "Sed ut perspiciatis" And the content of the file shared by the last public link should be the same as "lorem.txt" Scenario: user shares a public link via email - Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" - And the user has reloaded the current page of the webUI + Given user "user1" has created folder "/simple-folder" + And parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | email | foo@bar.co | Then the email address "foo@bar.co" should have received an email with the body containing @@ -137,8 +171,9 @@ Feature: Share by public link And the email address "foo@bar.co" should have received an email containing the last shared public link Scenario: user shares a public link via email and sends a copy to self - Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" - And the user has reloaded the current page of the webUI + Given user "user1" has created folder "/simple-folder" + And parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | email | foo@bar.co | | emailToSelf | true | @@ -154,8 +189,9 @@ Feature: Share by public link And the email address "user1@example.org" should have received an email containing the last shared public link Scenario: user shares a public link via email with multiple addresses - Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" - And the user has reloaded the current page of the webUI + Given user "user1" has created folder "/simple-folder" + And parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | email | foo@bar.co, foo@barr.co | Then the email address "foo@bar.co" should have received an email with the body containing @@ -171,7 +207,8 @@ Feature: Share by public link Scenario: user shares a public link via email with a personal message Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" - And the user has reloaded the current page of the webUI + And user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | email | foo@bar.co | | personalMessage | lorem ipsum | @@ -187,7 +224,8 @@ Feature: Share by public link Scenario: user shares a public link via email adding few addresses before and then removing some addresses afterwards Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" - And the user has reloaded the current page of the webUI + And user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI When the user opens the share dialog for folder "simple-folder" And the user opens the public link share tab And the user opens the create public link share popup @@ -217,7 +255,8 @@ Feature: Share by public link Scenario: user edits a public link and does not save the changes Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" - And the user has reloaded the current page of the webUI + And user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI And the user has created a new public link for folder "simple-folder" using the webUI with | email | foo1234@bar.co | | password | pass123 | @@ -229,7 +268,8 @@ Feature: Share by public link Scenario: user shares a public link via email with a personal message Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" - And the user has reloaded the current page of the webUI + And user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | email | foo@bar.co | | personalMessage | lorem ipsum | @@ -244,7 +284,10 @@ Feature: Share by public link And the email address "foo@bar.co" should have received an email containing the last shared public link Scenario: user edits a name of an already existing public link - Given the user has created a new public link for folder "simple-folder" using the webUI + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI And the user has opened the public link share tab When the user renames the public link name from "Public link" to "simple-folder Share" And the public accesses the last created public link using the webUI @@ -252,27 +295,37 @@ Feature: Share by public link Scenario: user shares a file through public link and then it appears in a Shared by link page Given parameter "shareapi_allow_public_notification" of app "core" has been set to "yes" + And user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI And the user has reloaded the current page of the webUI And the user has created a new public link for folder "simple-folder" using the webUI When the user browses to the shared-by-link page Then folder "simple-folder" should be listed on the webUI Scenario: user edits the password of an already existing public link - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | password | pass123 | When the user changes the password of the public link named "Public link" to "pass1234" And the public accesses the last created public link with password "pass1234" using the webUI Then file "lorem.txt" should be listed on the webUI Scenario: user edits the password of an already existing public link and tries to access with old password - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "/simple-folder" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | password | pass123 | When the user changes the password of the public link named "Public link" to "pass1234" And the public tries to access the last created public link with wrong password "pass123" using the webUI Then the public should not get access to the publicly shared file Scenario: user edits the permission of an already existing public link from read-write to read - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | permission | read-write | When the user changes the permission of the public link named "Public link" to "read" And the public accesses the last created public link using the webUI @@ -280,7 +333,11 @@ Feature: Share by public link And it should not be possible to delete file "lorem.txt" using the webUI Scenario: user edits the permission of an already existing public link from read to read-write - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "/simple-folder" + And user "user1" has created folder "/simple-folder/simple-empty-folder" + And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | permission | read | When the user changes the permission of the public link named "Public link" to "read-write" And the public accesses the last created public link using the webUI @@ -292,22 +349,26 @@ Feature: Share by public link And the deleted elements should not be listed on the webUI after a page reload Scenario: user changes the expiration date of an already existing public link using webUI - Given user "user1" has created a share with settings + Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "user1" has created a share with settings | path | lorem.txt | | name | Public link | | expireDate | 14-10-2038 | | shareType | 3 | + And user "user1" has logged in using the webUI When the user changes the expiration of the public link named "Public link" of file "lorem.txt" to "21-07-2038" And the user gets the info of the last share using the sharing API Then the fields of the last response should include | expiration | 21-07-2038 | Scenario: user tries to change the expiration date of the public link to past date using webUI - Given user "user1" has created a share with settings + Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "user1" has created a share with settings | path | lorem.txt | | name | Public link | | expireDate | 14-10-2038 | | shareType | 3 | + And user "user1" has logged in using the webUI When the user changes the expiration of the public link named "Public link" of file "lorem.txt" to "14-09-2017" And the user gets the info of the last share using the sharing API Then the user should see an error message on the public link share dialog saying "Expiration date is in the past" @@ -315,6 +376,10 @@ Feature: Share by public link | expiration | 14-10-2038 | Scenario: share two file with same name but different paths by public link + Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI When the user creates a new public link for file "lorem.txt" using the webUI And the user closes the details dialog And the user opens folder "simple-folder" using the webUI @@ -324,18 +389,24 @@ Feature: Share by public link And file "lorem.txt" with path "/simple-folder" should be listed in the shared with others page on the webUI Scenario: user removes the public link of a file - Given the user has created a new public link for file "lorem.txt" using the webUI + Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for file "lorem.txt" using the webUI When the user removes the public link of file "lorem.txt" using the webUI Then the public should see an error message "File not found" while accessing last created public link using the webUI Scenario: user cancel removes operation for the public link of a file - Given the user has created a new public link for file "lorem.txt" using the webUI + Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for file "lorem.txt" using the webUI When the user tries to remove the public link of file "lorem.txt" but later cancels the remove dialog using webUI And the public accesses the last created public link using the webUI Then the content of the file shared by the last public link should be the same as "lorem.txt" Scenario: user creates a multiple public link of a file and delete the first link - Given the user has created a new public link for file "lorem.txt" using the webUI with + Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for file "lorem.txt" using the webUI with | name | first-link | And the user has created a new public link for file "lorem.txt" using the webUI with | name | second-link | @@ -346,7 +417,9 @@ Feature: Share by public link And the number of public links should be 2 Scenario: user creates a multiple public link of a file and delete the second link - Given the user has created a new public link for file "lorem.txt" using the webUI with + Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for file "lorem.txt" using the webUI with | name | first-link | And the user has created a new public link for file "lorem.txt" using the webUI with | name | second-link | @@ -357,7 +430,9 @@ Feature: Share by public link And the number of public links should be 2 Scenario: user creates a multiple public link of a file and delete the third link - Given the user has created a new public link for file "lorem.txt" using the webUI with + Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for file "lorem.txt" using the webUI with | name | first-link | And the user has created a new public link for file "lorem.txt" using the webUI with | name | second-link | @@ -368,13 +443,19 @@ Feature: Share by public link And the number of public links should be 2 Scenario: user creates public link with view and upload feature + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI When the user creates a new public link for folder "simple-folder" using the webUI with | permission | upload-write-without-modify | And the public accesses the last created public link using the webUI Then it should not be possible to delete file "lorem.txt" using the webUI Scenario: user creates public link with view download and upload feature and uploads same file name and verifies no auto-renamed file seen in UI - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | permission | upload-write-without-modify | And the public accesses the last created public link using the webUI When the user uploads file "lorem.txt" 5 times using webUI @@ -385,7 +466,7 @@ Feature: Share by public link | The file lorem.txt already exists | | The file lorem.txt already exists | And file "lorem.txt" should be listed on the webUI - And the content of "lorem.txt" should not have changed + And the content of file "simple-folder/lorem.txt" should be "original content" And file "lorem (2).txt" should not be listed on the webUI @issue-35177 @@ -402,6 +483,7 @@ Feature: Share by public link | path | nf2/newfolder | And user "user1" has created a public link share with settings | path | test/test | + And user "user1" has logged in using the webUI And the user has browsed to the shared-by-link page When the user renames folder "newfolder" to "newfolder1" using the webUI Then folder "newfolder1" should be listed on the webUI @@ -418,6 +500,7 @@ Feature: Share by public link | path | nf1/newfolder | And user "user1" has created a public link share with settings | path | test | + And user "user1" has logged in using the webUI And the user has browsed to the shared-by-link page When the user renames folder "test" to "newfolder" using the webUI Then near folder "test" a tooltip with the text 'newfolder already exists' should be displayed on the webUI @@ -426,7 +509,10 @@ Feature: Share by public link #| newfolder | Scenario: Permissions work correctly on public link share with upload-write-without-modify - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | permission | upload-write-without-modify | When the public accesses the last created public link using the webUI Then the option to rename file "lorem.txt" should not be available on the webUI @@ -434,7 +520,10 @@ Feature: Share by public link And the option to upload file should be available on the webUI Scenario: Permissions work correctly on public link share with read-write - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | permission | read-write | When the public accesses the last created public link using the webUI Then the option to rename file "lorem.txt" should be available on the webUI @@ -442,7 +531,10 @@ Feature: Share by public link And the option to upload file should be available on the webUI Scenario: User tries to upload existing file in public link share with permissions upload-write-without-modify - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | permission | upload-write-without-modify | And the public accesses the last created public link using the webUI When the user uploads file "lorem.txt" using the webUI @@ -451,7 +543,10 @@ Feature: Share by public link And file "lorem (2).txt" should not be listed on the webUI Scenario: User tries to upload existing file in public link share with permissions read-write - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | permission | read-write | And the public accesses the last created public link using the webUI When the user uploads file "lorem.txt" keeping both new and existing files using the webUI @@ -459,7 +554,11 @@ Feature: Share by public link And file "lorem (2).txt" should be listed on the webUI Scenario: Editing the permission on a existing share from read-write to upload-write-without-modify works correctly - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has uploaded file "filesForUpload/lorem-big.txt" to "/simple-folder/lorem-big.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | permission | read-write | And the public accesses the last created public link using the webUI Then it should be possible to delete file "lorem.txt" using the webUI @@ -471,7 +570,11 @@ Feature: Share by public link Then the option to delete file "lorem-big.txt" should not be available on the webUI Scenario: Editing the permission on a existing share from upload-write-without-modify to read-write works correctly - Given the user has created a new public link for folder "simple-folder" using the webUI with + Given user "user1" has created folder "/simple-folder" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "user1" has uploaded file "filesForUpload/lorem-big.txt" to "/simple-folder/lorem-big.txt" + And user "user1" has logged in using the webUI + And the user has created a new public link for folder "simple-folder" using the webUI with | permission | upload-write-without-modify | And the public accesses the last created public link using the webUI Then the option to delete file "lorem.txt" should not be available on the webUI @@ -485,12 +588,13 @@ Feature: Share by public link Scenario: user tries to deletes the expiration date of already existing public link using webUI when expiration date is enforced 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" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" And user "user1" has created a share with settings | path | lorem.txt | | name | Public link | | expireDate | + 5 days | | shareType | 3 | - When the user reloads the current page of the webUI + And user "user1" has logged in using the webUI And the user changes the expiration of the public link named "Public link" of file "lorem.txt" to " " Then the user should see an error message on the public link popup saying "Expiration date is required" And the user gets the info of the last share using the sharing API @@ -499,12 +603,13 @@ Feature: Share by public link Scenario: user deletes the expiration date of already existing public link using webUI when expiration date is set but not enforced Given parameter "shareapi_default_expire_date" of app "core" has been set to "yes" + And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" And user "user1" has created a share with settings | path | lorem.txt | | name | Public link | | expireDate | + 5 days | | shareType | 3 | - When the user reloads the current page of the webUI + And user "user1" has logged in using the webUI And the user changes the expiration of the public link named "Public link" of file "lorem.txt" to " " And the user gets the info of the last share using the sharing API And the fields of the last response should include From ef7552593e569712607e528d4ab8b8f273d1f9bd Mon Sep 17 00:00:00 2001 From: Hari Bhandari Date: Wed, 12 Jun 2019 15:10:06 +0545 Subject: [PATCH 2/7] fix deleteTags for webui --- tests/acceptance/features/webUITags/deleteTags.feature | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/acceptance/features/webUITags/deleteTags.feature b/tests/acceptance/features/webUITags/deleteTags.feature index 1b28d230f010..c6fa573ccc30 100644 --- a/tests/acceptance/features/webUITags/deleteTags.feature +++ b/tests/acceptance/features/webUITags/deleteTags.feature @@ -49,11 +49,13 @@ Feature: Deletion of existing tags from files and folders Scenario: Delete a tag that exists for multiple file Given user "user1" has uploaded file with content "some content" to "/randomfile.txt" + And user "user1" has created folder "a-folder" + And user "user1" has uploaded file with content "another content" to "/a-folder/randomfile.txt" And user "user1" has uploaded file with content "more content" to "/randomfile-big.txt" And the user has created a "normal" tag with name "random" And the user has added tag "random" to file "randomfile.txt" And the user has added tag "random" to file "randomfile-big.txt" - And the user has browsed directly to display the details of file "randomfile.txt" in folder "" + And the user has browsed directly to display the details of file "randomfile.txt" in folder "a-folder" When the user deletes tag with name "random" using the webUI Then tag "random" should not exist for user "user1" From c95420299aa9139ccf2d8fc80206cbd159dd4bfd Mon Sep 17 00:00:00 2001 From: Hari Bhandari Date: Mon, 17 Jun 2019 15:36:53 +0545 Subject: [PATCH 3/7] fix for users creation in ldap test --- .../features/bootstrap/Provisioning.php | 32 +++++++++++-------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php index f6d54b67570f..4c2bb4fae625 100644 --- a/tests/acceptance/features/bootstrap/Provisioning.php +++ b/tests/acceptance/features/bootstrap/Provisioning.php @@ -383,6 +383,8 @@ public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitializ // We add all the request objects in an array so that we can send all the requests in parallel. $requests = []; $client = new Client(); + $methodLdap = \getenv("TEST_EXTERNAL_USER_BACKENDS"); + foreach ($table as $row) { $body['userid'] = $this->getActualUsername($row['username']); @@ -418,17 +420,21 @@ public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitializ \array_push($bodies, $body); // Create a OCS request for creating the user. The request is not sent to the server yet. - $request = OcsApiHelper::createOcsRequest( - $this->getBaseUrl(), - $this->getAdminUsername(), - $this->getAdminPassword(), - 'POST', - "/cloud/users", - $body, - $client - ); - // Add the request to the $requests array so that they can be sent in parallel. - \array_push($requests, $request); + if ($methodLdap === "true") { + echo "creating LDAP users is not implemented, so assume they exist\n"; + } else { + $request = OcsApiHelper::createOcsRequest( + $this->getBaseUrl(), + $this->getAdminUsername(), + $this->getAdminPassword(), + 'POST', + "/cloud/users", + $body, + $client + ); + // Add the request to the $requests array so that they can be sent in parallel. + \array_push($requests, $request); + } } $results = HttpRequestHelper::sendBatchRequest($requests, $client); @@ -452,7 +458,7 @@ public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitializ } } // Edit the users in parallel to make the process faster. - if (\count($editData) > 0) { + if (\count($editData) > 0 and !$methodLdap === "true") { $results = UserHelper::editUserBatch( $this->getBaseUrl(), $editData, @@ -465,7 +471,7 @@ public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitializ } // If the users need to be initialized then initialize them in parallel. - if ($initialize) { + if ($initialize and !$methodLdap === "true") { $this->initializeUserBatch($users); } } From fbfc619fc707ddb715c373f49ec0fe47e45eaa8f Mon Sep 17 00:00:00 2001 From: Hari Bhandari Date: Tue, 18 Jun 2019 10:50:28 +0545 Subject: [PATCH 4/7] fix --- .../features/bootstrap/Provisioning.php | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php index 4c2bb4fae625..365e269e43c6 100644 --- a/tests/acceptance/features/bootstrap/Provisioning.php +++ b/tests/acceptance/features/bootstrap/Provisioning.php @@ -383,7 +383,11 @@ public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitializ // We add all the request objects in an array so that we can send all the requests in parallel. $requests = []; $client = new Client(); - $methodLdap = \getenv("TEST_EXTERNAL_USER_BACKENDS"); + + if (\getenv("TEST_EXTERNAL_USER_BACKENDS") === "true") { + echo "creating LDAP users is not implemented, so assume they exist\n"; + return; + } foreach ($table as $row) { $body['userid'] = $this->getActualUsername($row['username']); @@ -420,21 +424,17 @@ public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitializ \array_push($bodies, $body); // Create a OCS request for creating the user. The request is not sent to the server yet. - if ($methodLdap === "true") { - echo "creating LDAP users is not implemented, so assume they exist\n"; - } else { - $request = OcsApiHelper::createOcsRequest( - $this->getBaseUrl(), - $this->getAdminUsername(), - $this->getAdminPassword(), - 'POST', - "/cloud/users", - $body, - $client - ); - // Add the request to the $requests array so that they can be sent in parallel. - \array_push($requests, $request); - } + $request = OcsApiHelper::createOcsRequest( + $this->getBaseUrl(), + $this->getAdminUsername(), + $this->getAdminPassword(), + 'POST', + "/cloud/users", + $body, + $client + ); + // Add the request to the $requests array so that they can be sent in parallel. + \array_push($requests, $request); } $results = HttpRequestHelper::sendBatchRequest($requests, $client); @@ -458,7 +458,7 @@ public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitializ } } // Edit the users in parallel to make the process faster. - if (\count($editData) > 0 and !$methodLdap === "true") { + if (\count($editData) > 0) { $results = UserHelper::editUserBatch( $this->getBaseUrl(), $editData, @@ -471,7 +471,7 @@ public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitializ } // If the users need to be initialized then initialize them in parallel. - if ($initialize and !$methodLdap === "true") { + if ($initialize) { $this->initializeUserBatch($users); } } From 6842f5917f6062e8a8dd5034cf076e950e31da06 Mon Sep 17 00:00:00 2001 From: Hari Bhandari Date: Mon, 17 Jun 2019 17:06:24 +0545 Subject: [PATCH 5/7] webdav lock protection without skeleton --- .../webUIWebdavLockProtection/delete.feature | 10 ++--- .../webUIWebdavLockProtection/move.feature | 41 ++++++++++++------- .../webUIWebdavLockProtection/upload.feature | 30 ++++++++------ 3 files changed, 49 insertions(+), 32 deletions(-) diff --git a/tests/acceptance/features/webUIWebdavLockProtection/delete.feature b/tests/acceptance/features/webUIWebdavLockProtection/delete.feature index 75ec8be67468..efb3567bc40a 100644 --- a/tests/acceptance/features/webUIWebdavLockProtection/delete.feature +++ b/tests/acceptance/features/webUIWebdavLockProtection/delete.feature @@ -6,15 +6,16 @@ Feature: Locks Background: #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887 - Given these users have been created with skeleton files: + Given these users have been created without skeleton files: |username | |brand-new-user| - And user "brand-new-user" has logged in using the webUI Scenario Outline: deleting a file in a public share of a locked folder - Given user "brand-new-user" has locked folder "simple-folder" setting following properties + Given user "brand-new-user" has created folder "/simple-folder" + And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "brand-new-user" has locked folder "simple-folder" setting following properties | lockscope | | - And the user has browsed to the files page + And user "brand-new-user" has logged in using the webUI And the user has created a new public link for folder "simple-folder" using the webUI with | permission | read-write | When the public accesses the last created public link using the webUI @@ -27,4 +28,3 @@ Feature: Locks | lockscope | | exclusive | | shared | - diff --git a/tests/acceptance/features/webUIWebdavLockProtection/move.feature b/tests/acceptance/features/webUIWebdavLockProtection/move.feature index f150e74cbaf3..a1ff5d76504d 100644 --- a/tests/acceptance/features/webUIWebdavLockProtection/move.feature +++ b/tests/acceptance/features/webUIWebdavLockProtection/move.feature @@ -6,15 +6,16 @@ Feature: Locks Background: #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887 - Given these users have been created with skeleton files: + Given these users have been created without skeleton files: | username | | brand-new-user | - And user "brand-new-user" has logged in using the webUI Scenario Outline: moving a locked file - Given user "brand-new-user" has locked file "lorem.txt" setting following properties + Given user "brand-new-user" has created folder "/simple-empty-folder" + And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "brand-new-user" has locked file "lorem.txt" setting following properties | lockscope | | - And the user has browsed to the files page + And user "brand-new-user" has logged in using the webUI When the user moves file "lorem.txt" into folder "simple-empty-folder" using the webUI Then notifications should be displayed on the webUI with the text | Could not move "lorem.txt" because either the file or the target are locked. | @@ -29,9 +30,12 @@ Feature: Locks | shared | Scenario Outline: moving a file trying to overwrite a locked file - Given user "brand-new-user" has locked file "/simple-folder/lorem.txt" setting following properties + Given user "brand-new-user" has created folder "/simple-folder" + And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "brand-new-user" has locked file "/simple-folder/lorem.txt" setting following properties | lockscope | | - And the user has browsed to the files page + And user "brand-new-user" has logged in using the webUI When the user moves file "lorem.txt" into folder "simple-folder" using the webUI Then notifications should be displayed on the webUI with the text | Could not move "lorem.txt" because either the file or the target are locked. | @@ -44,9 +48,11 @@ Feature: Locks | shared | Scenario Outline: moving a file into a locked folder - Given user "brand-new-user" has locked file "/simple-empty-folder" setting following properties + Given user "brand-new-user" has created folder "/simple-empty-folder" + And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "brand-new-user" has locked file "/simple-empty-folder" setting following properties | lockscope | | - And the user has browsed to the files page + And user "brand-new-user" has logged in using the webUI When the user moves file "lorem.txt" into folder "simple-empty-folder" using the webUI Then notifications should be displayed on the webUI with the text | Could not move "lorem.txt" because either the file or the target are locked. | @@ -61,9 +67,10 @@ Feature: Locks | shared | Scenario Outline: renaming of a locked file - Given user "brand-new-user" has locked file "lorem.txt" setting following properties + Given user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt" + And user "brand-new-user" has locked file "lorem.txt" setting following properties | lockscope | | - And the user has browsed to the files page + And user "brand-new-user" has logged in using the webUI When the user renames file "lorem.txt" to "a-renamed-file.txt" using the webUI Then notifications should be displayed on the webUI with the text | The file "lorem.txt" is locked and can not be renamed. | @@ -78,9 +85,11 @@ Feature: Locks | shared | Scenario Outline: renaming a file in a public share of a locked folder - Given user "brand-new-user" has locked folder "simple-folder" setting following properties + Given user "brand-new-user" has created folder "/simple-folder" + And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "brand-new-user" has locked folder "simple-folder" setting following properties | lockscope | | - And the user has browsed to the files page + And user "brand-new-user" has logged in using the webUI And the user has created a new public link for folder "simple-folder" using the webUI with | permission | read-write | When the public accesses the last created public link using the webUI @@ -96,9 +105,12 @@ Feature: Locks | shared | Scenario Outline: moving a locked file into an other folder in a public share - Given user "brand-new-user" has locked file "simple-folder/lorem.txt" setting following properties + Given user "brand-new-user" has created folder "/simple-folder" + And user "brand-new-user" has created folder "/simple-folder/simple-empty-folder" + And user "brand-new-user" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt" + And user "brand-new-user" has locked file "simple-folder/lorem.txt" setting following properties | lockscope | | - And the user has browsed to the files page + And user "brand-new-user" has logged in using the webUI And the user has created a new public link for folder "simple-folder" using the webUI with | permission | read-write | When the public accesses the last created public link using the webUI @@ -113,4 +125,3 @@ Feature: Locks | lockscope | | exclusive | | shared | - diff --git a/tests/acceptance/features/webUIWebdavLockProtection/upload.feature b/tests/acceptance/features/webUIWebdavLockProtection/upload.feature index 542fc533b60d..fecaa0c78cc1 100644 --- a/tests/acceptance/features/webUIWebdavLockProtection/upload.feature +++ b/tests/acceptance/features/webUIWebdavLockProtection/upload.feature @@ -6,19 +6,19 @@ Feature: Locks Background: #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887 - Given these users have been created with skeleton files: + Given these users have been created without skeleton files: | username | | brand-new-user | - And user "brand-new-user" has logged in using the webUI Scenario Outline: uploading a file, trying to overwrite a locked file - Given user "brand-new-user" has locked file "lorem.txt" setting following properties + Given user "brand-new-user" has uploaded file with content "original content" to "/lorem.txt" + And user "brand-new-user" has locked file "lorem.txt" setting following properties | lockscope | | - And the user has browsed to the files page + And user "brand-new-user" has logged in using the webUI When the user uploads overwriting file "lorem.txt" using the webUI Then notifications should be displayed on the webUI with the text | The file lorem.txt is currently locked, please try again later | - And the content of "lorem.txt" should not have changed + And the content of file "/lorem.txt" for user "brand-new-user" should be "original content" And file "lorem.txt" should be marked as locked on the webUI And file "lorem.txt" should be marked as locked by user "brand-new-user" in the locks tab of the details panel on the webUI And 1 locks should be reported for file "lorem.txt" of user "brand-new-user" by the WebDAV API @@ -28,13 +28,16 @@ Feature: Locks | shared | Scenario Outline: uploading a file, trying to overwrite a file in a locked folder - Given user "brand-new-user" has locked folder "simple-folder" setting following properties + Given user "brand-new-user" has created folder "/simple-folder" + And user "brand-new-user" has uploaded file with content "original content" to "/simple-folder/lorem.txt" + And user "brand-new-user" has locked folder "simple-folder" setting following properties | lockscope | | + And user "brand-new-user" has logged in using the webUI And the user has opened folder "simple-folder" using the webUI When the user uploads overwriting file "lorem.txt" using the webUI Then notifications should be displayed on the webUI with the text | The file lorem.txt is currently locked, please try again later | - And the content of "lorem.txt" should not have changed + And the content of file "/simple-folder/lorem.txt" for user "brand-new-user" should be "original content" And file "lorem.txt" should be marked as locked on the webUI And file "lorem.txt" should be marked as locked by user "brand-new-user" in the locks tab of the details panel on the webUI And 1 locks should be reported for file "simple-folder/lorem.txt" of user "brand-new-user" by the WebDAV API @@ -44,8 +47,10 @@ Feature: Locks | shared | Scenario Outline: uploading a new file into a locked folder - Given user "brand-new-user" has locked folder "simple-folder" setting following properties + Given user "brand-new-user" has created folder "/simple-folder" + And user "brand-new-user" has locked folder "simple-folder" setting following properties | lockscope | | + And user "brand-new-user" has logged in using the webUI And the user has opened folder "simple-folder" using the webUI When the user uploads file "new-lorem.txt" using the webUI Then notifications should be displayed on the webUI with the text @@ -58,19 +63,20 @@ Feature: Locks | shared | Scenario Outline: uploading a file, trying to overwrite a file in a locked folder in a public share - Given user "brand-new-user" has locked folder "simple-folder" setting following properties + Given user "brand-new-user" has created folder "/simple-folder" + And user "brand-new-user" has uploaded file with content "original content" to "/simple-folder/lorem.txt" + And user "brand-new-user" has locked folder "simple-folder" setting following properties | lockscope | | - And the user has browsed to the files page + And user "brand-new-user" has logged in using the webUI And the user has created a new public link for folder "simple-folder" using the webUI with | permission | read-write | When the public accesses the last created public link using the webUI And the user uploads overwriting file "lorem.txt" using the webUI Then notifications should be displayed on the webUI with the text | The file lorem.txt is currently locked, please try again later | - And the content of "simple-folder/lorem.txt" should not have changed + And the content of file "/simple-folder/lorem.txt" should be "original content" And 1 locks should be reported for file "simple-folder/lorem.txt" of user "brand-new-user" by the WebDAV API Examples: | lockscope | | exclusive | | shared | - From 9a5bbdb54e8d62850c8add279cc7405f19ee6deb Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Tue, 18 Jun 2019 18:34:49 +0545 Subject: [PATCH 6/7] Acceptance test for permissions update of link share of sub-folder --- .../apiShareManagement/reShare.feature | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/tests/acceptance/features/apiShareManagement/reShare.feature b/tests/acceptance/features/apiShareManagement/reShare.feature index f3eb08606f0e..a428ecefb7d7 100644 --- a/tests/acceptance/features/apiShareManagement/reShare.feature +++ b/tests/acceptance/features/apiShareManagement/reShare.feature @@ -359,6 +359,38 @@ Feature: sharing | 1 | 200 | | 2 | 404 | + @issue-enterprise-3364 + 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 "user0" has created folder "/test" + And user "user0" has created folder "/test/sub" + And user "user0" has shared folder "/test" with user "user1" with permissions 17 + And user "user1" has created a public link share with settings + | path | /test/sub | + | permissions | 1 | + | publicUpload | false | + And publicly uploading a file should not work + When user "user1" updates the last share using the sharing API with + | permissions | 15 | + Then the OCS status code should be "" + And the HTTP status code should be "200" + #Then the OCS status code should be "404" + #And the HTTP status code should be "" + And publicly uploading a file should work + #And publicly uploading a file should not work + # Delete the following 4 steps when fixing the issue: + And the public should be able to upload file "file.txt" with content "some text" to the last public shared folder + And as "user0" file "/test/sub/file.txt" should exist + And as "user1" file "/test/sub/file.txt" should exist + And the content of file "/test/sub/file.txt" for user "user0" should be "some text" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + #| ocs_api_version | http_status_code | + #| 1 | 200 | + #| 2 | 404 | + Scenario Outline: resharing a file is not allowed when allow resharing has been disabled Given using OCS API version "" And user "user2" has been created with default attributes and without skeleton files From 4756723e53dd08fd6cab44eabd9c00e11a6b4176 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Tue, 18 Jun 2019 15:27:45 +0545 Subject: [PATCH 7/7] Test that an emoji works in the user full name via API --- .../features/apiProvisioning-v1/editUser.feature | 12 ++++++++---- .../features/apiProvisioning-v2/editUser.feature | 12 ++++++++---- 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/tests/acceptance/features/apiProvisioning-v1/editUser.feature b/tests/acceptance/features/apiProvisioning-v1/editUser.feature index 0485672bb8f3..bbff9b0a6ec2 100644 --- a/tests/acceptance/features/apiProvisioning-v1/editUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/editUser.feature @@ -73,14 +73,18 @@ Feature: edit users | email | brand-new-user@example.com | And the email address of user "brand-new-user" should be "brand-new-user@example.com" - Scenario: a normal user should be able to change their display name + 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 skeleton files - When user "brand-new-user" changes the display name of user "brand-new-user" to "Alan Border" using the provisioning API + 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 | Alan Border | - And the display name of user "brand-new-user" should be "Alan Border" + | 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 skeleton files diff --git a/tests/acceptance/features/apiProvisioning-v2/editUser.feature b/tests/acceptance/features/apiProvisioning-v2/editUser.feature index a7cca92cfeaf..6b1a61835618 100644 --- a/tests/acceptance/features/apiProvisioning-v2/editUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/editUser.feature @@ -73,14 +73,18 @@ Feature: edit users | email | brand-new-user@example.com | And the email address of user "brand-new-user" should be "brand-new-user@example.com" - Scenario: a normal user should be able to change their display name + 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 skeleton files - When user "brand-new-user" changes the display name of user "brand-new-user" to "Alan Border" using the provisioning API + 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 | Alan Border | - And the display name of user "brand-new-user" should be "Alan Border" + | 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 skeleton files