From 00b3997bbeb4a7ab695b0971ebdf949f67130d23 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Mon, 27 May 2019 14:24:03 +0545 Subject: [PATCH 1/9] API acceptance tests for case sensitive group names --- .../apiProvisioningGroups-v1/addGroup.feature | 14 +++++++++++++ .../deleteGroup.feature | 16 +++++++++++++++ .../apiProvisioningGroups-v1/getGroup.feature | 20 +++++++++++++++++++ .../apiProvisioningGroups-v2/addGroup.feature | 14 +++++++++++++ .../deleteGroup.feature | 16 +++++++++++++++ .../apiProvisioningGroups-v2/getGroup.feature | 20 +++++++++++++++++++ 6 files changed, 100 insertions(+) diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature index 2216c783103f..30872315b94f 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature @@ -44,6 +44,20 @@ Feature: add groups | staff?group | Question mark | | 😅 😆 | emoji | + Scenario Outline: group names are case-sensitive, multiple groups can exist with different upper and lower case names + When the administrator sends a group creation request for group "" using the provisioning API + And the administrator sends a group creation request for group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And group "" should exist + And group "" should exist + But group "" should not exist + Examples: + | group_id1 | group_id2 | group_id3 | + | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | + # Note: these groups do get created OK, but: # 1) the "should exist" step fails because the API to check their existence does not work. # 2) the ordinary group deletion in AfterScenario does not work, because the diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature index c14ce5a84e1a..762c88abb8fd 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature @@ -46,6 +46,22 @@ Feature: delete groups | staff?group | Question mark | | 😁 😂 | emoji | + Scenario Outline: group names are case-sensitive, the correct group is deleted + Given group "" has been created + And group "" has been created + And group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And group "" should not exist + But group "" should exist + And group "" should exist + Examples: + | group_id1 | group_id2 | group_id3 | + | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | + @issue-31015 Scenario Outline: admin deletes a group that has a forward-slash in the group name # After fixing issue-31015, change the following step to "has been created" diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature index 9287067a38ff..838f61b891a7 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature @@ -28,6 +28,26 @@ Feature: get group And the HTTP status code should be "200" And the list of users returned by the API should be empty + Scenario: admin tries to get users in a non-existent group + Given group "new-group" has been created + When the administrator gets all the members of group "not-a-group" using the provisioning API + Then the OCS status code should be "998" + And the HTTP status code should be "200" + + Scenario Outline: admin tries to get users in a group but using wrong case of the group name + Given group "" has been created + When the administrator gets all the members of group "" using the provisioning API + Then the OCS status code should be "998" + And the HTTP status code should be "200" + Examples: + | group_id1 | group_id2 | + | case-sensitive-group | Case-Sensitive-Group | + | case-sensitive-group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | case-sensitive-group | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | CASE-SENSITIVE-GROUP | Case-Sensitive-Group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | + @smokeTest Scenario: subadmin gets users in a group they are responsible for Given user "user1" has been created with default attributes diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature index 1e761afb9e60..f5b69933cf70 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature @@ -44,6 +44,20 @@ Feature: add groups | staff?group | Question mark | | 😅 😆 | emoji | + Scenario Outline: group names are case-sensitive, multiple groups can exist with different upper and lower case names + When the administrator sends a group creation request for group "" using the provisioning API + And the administrator sends a group creation request for group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And group "" should exist + And group "" should exist + But group "" should not exist + Examples: + | group_id1 | group_id2 | group_id3 | + | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | + # Note: these groups do get created OK, but: # 1) the "should exist" step fails because the API to check their existence does not work. # 2) the ordinary group deletion in AfterScenario does not work, because the diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature index 9e78caf81312..b3cf27c0aa6c 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature @@ -46,6 +46,22 @@ Feature: delete groups | staff?group | Question mark | | 😅 😆 | emoji | + Scenario Outline: group names are case-sensitive, the correct group is deleted + Given group "" has been created + And group "" has been created + And group "" has been created + When the administrator deletes group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And group "" should not exist + But group "" should exist + And group "" should exist + Examples: + | group_id1 | group_id2 | group_id3 | + | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | + @issue-31015 Scenario Outline: admin deletes a group that has a forward-slash in the group name # After fixing issue-31015, change the following step to "has been created" diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature index 69a3515e689f..9b2a13fa0300 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature @@ -28,6 +28,26 @@ Feature: get group And the HTTP status code should be "200" And the list of users returned by the API should be empty + Scenario: admin tries to get users in a non-existent group + Given group "new-group" has been created + When the administrator gets all the members of group "not-a-group" using the provisioning API + Then the OCS status code should be "404" + And the HTTP status code should be "404" + + Scenario Outline: admin tries to get users in a group but using wrong case of the group name + Given group "" has been created + When the administrator gets all the members of group "" using the provisioning API + Then the OCS status code should be "404" + And the HTTP status code should be "404" + Examples: + | group_id1 | group_id2 | + | case-sensitive-group | Case-Sensitive-Group | + | case-sensitive-group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | case-sensitive-group | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | CASE-SENSITIVE-GROUP | Case-Sensitive-Group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | + @smokeTest Scenario: subadmin gets users in a group they are responsible for Given user "user1" has been created with default attributes From 7a5202fecd01239560667275b4506698c157ddf1 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Mon, 27 May 2019 14:41:41 +0545 Subject: [PATCH 2/9] CLI acceptance tests for case sensitive group names --- .../features/cliProvisioning/addGroup.feature | 13 +++++++++++ .../cliProvisioning/deleteGroup.feature | 18 ++++++++++++++- .../features/cliProvisioning/getGroup.feature | 22 ++++++++++++++++++- 3 files changed, 51 insertions(+), 2 deletions(-) diff --git a/tests/acceptance/features/cliProvisioning/addGroup.feature b/tests/acceptance/features/cliProvisioning/addGroup.feature index c8ff7d4c5589..6b96557fe14e 100644 --- a/tests/acceptance/features/cliProvisioning/addGroup.feature +++ b/tests/acceptance/features/cliProvisioning/addGroup.feature @@ -15,6 +15,19 @@ Feature: add group | España | special European characters | | नेपाली | Unicode group name | + Scenario Outline: group names are case-sensitive, multiple groups can exist with different upper and lower case names + When the administrator creates group "" using the occ command + And the administrator creates group "" using the occ command + Then the command should have been successful + And group "" should exist + And group "" should exist + But group "" should not exist + Examples: + | group_id1 | group_id2 | group_id3 | + | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | + Scenario: admin tries to create a group that already exists Given group "new-group" has been created When the administrator creates group "new-group" using the occ command diff --git a/tests/acceptance/features/cliProvisioning/deleteGroup.feature b/tests/acceptance/features/cliProvisioning/deleteGroup.feature index a218579ec1e5..9dd162bb1eeb 100644 --- a/tests/acceptance/features/cliProvisioning/deleteGroup.feature +++ b/tests/acceptance/features/cliProvisioning/deleteGroup.feature @@ -14,4 +14,20 @@ Feature: delete groups | group_id | comment | | simplegroup | nothing special here | | España | special European characters | - | नेपाली | Unicode group name | \ No newline at end of file + | नेपाली | Unicode group name | + + Scenario Outline: group names are case-sensitive, the correct group is deleted + Given group "" has been created + And group "" has been created + And group "" has been created + When the administrator deletes group "" using the occ command + Then the command should have been successful + And the command output should contain the text 'The specified group was deleted' + And group "" should not exist + But group "" should exist + And group "" should exist + Examples: + | group_id1 | group_id2 | group_id3 | + | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | diff --git a/tests/acceptance/features/cliProvisioning/getGroup.feature b/tests/acceptance/features/cliProvisioning/getGroup.feature index 23a25d952a71..f265d54bfdde 100644 --- a/tests/acceptance/features/cliProvisioning/getGroup.feature +++ b/tests/acceptance/features/cliProvisioning/getGroup.feature @@ -30,4 +30,24 @@ Feature: get group Then the command should have been successful And the users returned by the occ command should be | uid | display name | - | brand-new-user | Anne Brown | \ No newline at end of file + | brand-new-user | Anne Brown | + + Scenario: admin tries to get users in a non-existent group + Given group "new-group" has been created + When the administrator gets the users in group "not-a-group" in JSON format using the occ command + Then the command should have failed with exit code 1 + And the command output should contain the text 'Group not-a-group does not exist' + + Scenario Outline: admin tries to get users in a group but using wrong case of the group name + Given group "" has been created + When the administrator gets the users in group "" in JSON format using the occ command + Then the command should have failed with exit code 1 + And the command output should contain the text 'Group does not exist' + Examples: + | group_id1 | group_id2 | + | case-sensitive-group | Case-Sensitive-Group | + | case-sensitive-group | CASE-SENSITIVE-GROUP | + | Case-Sensitive-Group | case-sensitive-group | + | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | + | CASE-SENSITIVE-GROUP | Case-Sensitive-Group | + | CASE-SENSITIVE-GROUP | case-sensitive-group | From b114590bb5a80a18356f8862c7937d4b98ad95c0 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Mon, 27 May 2019 15:07:22 +0545 Subject: [PATCH 3/9] API acceptance tests to add and remove users in groups using mixed case user and group names --- .../addToGroup.feature | 17 ++++++++++++++++ .../removeFromGroup.feature | 20 +++++++++++++++++++ .../addToGroup.feature | 17 ++++++++++++++++ .../removeFromGroup.feature | 20 +++++++++++++++++++ 4 files changed, 74 insertions(+) diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature index b5c77a42e031..b733eb202344 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature @@ -65,6 +65,23 @@ Feature: add users to group | var/../etc | using slash-dot-dot | | priv/subadmins/1 | Subadmins mentioned not at the end | + Scenario Outline: adding a user to a group using mixes of upper and lower case in user and group names + Given user "brand-new-user" has been created with default attributes + And group "" has been created + And group "" has been created + And group "" has been created + When the administrator adds user "" to group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should belong to group "" + But user "brand-new-user" should not belong to group "" + And user "brand-new-user" should not belong to group "" + Examples: + | user_id | group_id1 | group_id2 | group_id3 | + | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP | + | Brand-New-User | new-group | NEW-GROUP | New-Group | + | brand-new-user | NEW-GROUP | New-Group | new-group | + Scenario: normal user tries to add himself to a group Given user "brand-new-user" has been created with default attributes When user "brand-new-user" tries to add himself to group "new-group" using the provisioning API diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature index ab4cf1f7cdd4..63812f0709f6 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature @@ -71,6 +71,26 @@ Feature: remove a user from a group | var/../etc | using slash-dot-dot | | priv/subadmins/1 | Subadmins mentioned not at the end | + Scenario Outline: remove a user from a group using mixes of upper and lower case in user and group names + Given user "brand-new-user" has been created with default attributes + And group "" has been created + And group "" has been created + And group "" has been created + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + When the administrator removes user "" from group "" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "" + But user "brand-new-user" should belong to group "" + And user "brand-new-user" should belong to group "" + Examples: + | user_id | group_id1 | group_id2 | group_id3 | + | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP | + | Brand-New-User | new-group | NEW-GROUP | New-Group | + | brand-new-user | NEW-GROUP | New-Group | new-group | + Scenario: admin tries to remove a user from a group which does not exist Given user "brand-new-user" has been created with default attributes And group "not-group" has been deleted diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature index 286e75682354..d93e9e415b4e 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature @@ -65,6 +65,23 @@ Feature: add users to group | var/../etc | using slash-dot-dot | | priv/subadmins/1 | Subadmins mentioned not at the end | + Scenario Outline: adding a user to a group using mixes of upper and lower case in user and group names + Given user "brand-new-user" has been created with default attributes + And group "" has been created + And group "" has been created + And group "" has been created + When the administrator adds user "" to group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should belong to group "" + But user "brand-new-user" should not belong to group "" + And user "brand-new-user" should not belong to group "" + Examples: + | user_id | group_id1 | group_id2 | group_id3 | + | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP | + | Brand-New-User | new-group | NEW-GROUP | New-Group | + | brand-new-user | NEW-GROUP | New-Group | new-group | + @issue-31276 Scenario: normal user tries to add himself to a group Given user "brand-new-user" has been created with default attributes diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature index e15a8242ef23..972ef0399471 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature @@ -71,6 +71,26 @@ Feature: remove a user from a group | var/../etc | using slash-dot-dot | | priv/subadmins/1 | Subadmins mentioned not at the end | + Scenario Outline: remove a user from a group using mixes of upper and lower case in user and group names + Given user "brand-new-user" has been created with default attributes + And group "" has been created + And group "" has been created + And group "" has been created + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + When the administrator removes user "" from group "" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should not belong to group "" + But user "brand-new-user" should belong to group "" + And user "brand-new-user" should belong to group "" + Examples: + | user_id | group_id1 | group_id2 | group_id3 | + | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP | + | Brand-New-User | new-group | NEW-GROUP | New-Group | + | brand-new-user | NEW-GROUP | New-Group | new-group | + Scenario: admin tries to remove a user from a group which does not exist Given user "brand-new-user" has been created with default attributes And group "not-group" has been deleted From 8a378937c4a621a4d25421fca108ce4364834317 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Mon, 27 May 2019 16:30:04 +0545 Subject: [PATCH 4/9] CLI acceptance tests to add and remove users in groups using mixed case user and group names --- .../cliProvisioning/addToGroup.feature | 17 ++++++++++++++++ .../cliProvisioning/removeFromGroup.feature | 20 +++++++++++++++++++ 2 files changed, 37 insertions(+) diff --git a/tests/acceptance/features/cliProvisioning/addToGroup.feature b/tests/acceptance/features/cliProvisioning/addToGroup.feature index 063f20a384ec..bd3ddf5a8e12 100644 --- a/tests/acceptance/features/cliProvisioning/addToGroup.feature +++ b/tests/acceptance/features/cliProvisioning/addToGroup.feature @@ -18,6 +18,23 @@ Feature: add users to group | España | special European characters | | नेपाली | Unicode group name | + Scenario Outline: adding a user to a group using mixes of upper and lower case in user and group names + Given user "brand-new-user" has been created with default attributes + And group "" has been created + And group "" has been created + And group "" has been created + When the administrator adds user "" to group "" using the occ command + Then the command should have been successful + And the command output should contain the text 'User "brand-new-user" added to group ""' + And user "brand-new-user" should belong to group "" + But user "brand-new-user" should not belong to group "" + And user "brand-new-user" should not belong to group "" + Examples: + | user_id | group_id1 | group_id2 | group_id3 | + | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP | + | Brand-New-User | new-group | NEW-GROUP | New-Group | + | brand-new-user | NEW-GROUP | New-Group | new-group | + Scenario: admin tries to add user to a group which does not exist Given user "brand-new-user" has been created with default attributes And group "not-group" has been deleted diff --git a/tests/acceptance/features/cliProvisioning/removeFromGroup.feature b/tests/acceptance/features/cliProvisioning/removeFromGroup.feature index 058886eb7cb1..47d115273cac 100644 --- a/tests/acceptance/features/cliProvisioning/removeFromGroup.feature +++ b/tests/acceptance/features/cliProvisioning/removeFromGroup.feature @@ -18,6 +18,26 @@ Feature: remove a user from a group | España | special European characters | | नेपाली | Unicode group name | + Scenario Outline: remove a user from a group using mixes of upper and lower case in user and group names + Given user "brand-new-user" has been created with default attributes + And group "" has been created + And group "" has been created + And group "" has been created + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + And user "brand-new-user" has been added to group "" + When the administrator removes user "" from group "" using the occ command + Then the command should have been successful + And the command output should contain the text 'Member "brand-new-user" removed from group ""' + And user "brand-new-user" should not belong to group "" + But user "brand-new-user" should belong to group "" + And user "brand-new-user" should belong to group "" + Examples: + | user_id | group_id1 | group_id2 | group_id3 | + | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP | + | Brand-New-User | new-group | NEW-GROUP | New-Group | + | brand-new-user | NEW-GROUP | New-Group | new-group | + Scenario: admin tries to remove a user from a group which does not exist Given user "brand-new-user" has been created with default attributes And group "not-group" has been deleted From 8ff02f96a48f06b3ae618454a3fe8f019e227662 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Mon, 27 May 2019 16:36:16 +0545 Subject: [PATCH 5/9] API acceptance tests for listing groups with different case in the name --- .../apiProvisioningGroups-v1/getGroups.feature | 11 +++++++++++ .../apiProvisioningGroups-v2/getGroups.feature | 11 +++++++++++ 2 files changed, 22 insertions(+) diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature index f459f7b7f64e..8b6ede4dde0f 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature @@ -18,3 +18,14 @@ Feature: get groups | admin | | new-group | | 0 | + + Scenario: admin gets all the groups, including groups with mixed case + Given group "new-group" has been created + And group "New-Group" has been created + And group "NEW-GROUP" has been created + When the administrator gets all the groups using the provisioning API + Then the groups returned by the API should be + | admin | + | new-group | + | New-Group | + | NEW-GROUP | diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature index 3c3d67f52828..dfc3226a3421 100644 --- a/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature +++ b/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature @@ -18,3 +18,14 @@ Feature: get groups | admin | | new-group | | 0 | + + Scenario: admin gets all the groups, including groups with mixed case + Given group "new-group" has been created + And group "New-Group" has been created + And group "NEW-GROUP" has been created + When the administrator gets all the groups using the provisioning API + Then the groups returned by the API should be + | admin | + | new-group | + | New-Group | + | NEW-GROUP | From d09c2ef66aef47926e81e32c55c5786824a1e335 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Mon, 27 May 2019 16:41:27 +0545 Subject: [PATCH 6/9] CLI acceptance tests for listing groups with different case in the name --- .../features/cliProvisioning/getGroups.feature | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/tests/acceptance/features/cliProvisioning/getGroups.feature b/tests/acceptance/features/cliProvisioning/getGroups.feature index 4b2713930fe8..c1d685186be3 100644 --- a/tests/acceptance/features/cliProvisioning/getGroups.feature +++ b/tests/acceptance/features/cliProvisioning/getGroups.feature @@ -16,3 +16,16 @@ Feature: get groups | admin | | new-group | | 0 | + + Scenario: admin gets all the groups, including groups with mixed case + Given group "new-group" has been created + And group "New-Group" has been created + And group "NEW-GROUP" has been created + When the administrator gets the groups in JSON format using the occ command + Then the command should have been successful + And the groups returned by the occ command should be + | group | + | admin | + | new-group | + | New-Group | + | NEW-GROUP | From 06c379ebf8bf5fa6e4b4e7b61116bf6d6a888dbe Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Tue, 28 May 2019 09:11:23 +0545 Subject: [PATCH 7/9] API tests to delete a user using mixed case for the username --- .../features/apiProvisioning-v1/deleteUser.feature | 7 +++++++ .../features/apiProvisioning-v2/deleteUser.feature | 7 +++++++ 2 files changed, 14 insertions(+) diff --git a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature index 1a4b2d4b15a0..b092939ab953 100644 --- a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature +++ b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature @@ -15,6 +15,13 @@ Feature: delete users And the HTTP status code should be "200" And user "brand-new-user" should not exist + Scenario: Delete a user, and specify the user name in different case + Given user "brand-new-user" has been created with default attributes + When the administrator deletes user "Brand-New-User" using the provisioning API + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + @smokeTest Scenario: subadmin deletes a user in their group Given user "subadmin" has been created with default attributes diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature index 45d80b1eda01..7123410daf8f 100644 --- a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature +++ b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature @@ -15,6 +15,13 @@ Feature: delete users And the HTTP status code should be "200" And user "brand-new-user" should not exist + Scenario: Delete a user, and specify the user name in different case + Given user "brand-new-user" has been created with default attributes + When the administrator deletes user "Brand-New-User" using the provisioning API + Then the OCS status code should be "200" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + @smokeTest Scenario: subadmin deletes a user in their group Given user "subadmin" has been created with default attributes From 4e14c83024a13d7c2aa970ff28e3c952f1f0b4bf Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Tue, 28 May 2019 09:12:11 +0545 Subject: [PATCH 8/9] Remember normalized lowercase username in acceptance tests --- .../features/bootstrap/BasicStructure.php | 3 ++ .../features/bootstrap/Provisioning.php | 30 ++++++++++++++++--- 2 files changed, 29 insertions(+), 4 deletions(-) diff --git a/tests/acceptance/features/bootstrap/BasicStructure.php b/tests/acceptance/features/bootstrap/BasicStructure.php index 2c36274b99b4..ccb92d485e8e 100644 --- a/tests/acceptance/features/bootstrap/BasicStructure.php +++ b/tests/acceptance/features/bootstrap/BasicStructure.php @@ -1331,6 +1331,7 @@ public function rememberNewAdminPassword($password) { */ public function getPasswordForUser($userName) { $userName = $this->getActualUsername($userName); + $userName = $this->normalizeUsername($userName); if ($userName === $this->getAdminUsername()) { return (string) $this->getAdminPassword(); } elseif (\array_key_exists($userName, $this->createdUsers)) { @@ -1377,6 +1378,7 @@ public function getDisplayNameForUser($userName) { // The hard-coded user names and display names are also in ldap-users.ldif // for testing in an LDAP environment. The mapping must be kept the // same in both places. + $userName = $this->normalizeUsername($userName); if (\array_key_exists($userName, $this->createdUsers)) { return (string) $this->createdUsers[$userName]['displayname']; } elseif (\array_key_exists($userName, $this->createdRemoteUsers)) { @@ -1419,6 +1421,7 @@ public function getEmailAddressForUser($userName) { // The hard-coded user names and email addresses are also in ldap-users.ldif // for testing in an LDAP environment. The mapping must be kept the // same in both places. + $userName = $this->normalizeUsername($userName); if (\array_key_exists($userName, $this->createdUsers)) { return (string) $this->createdUsers[$userName]['email']; } elseif (\array_key_exists($userName, $this->createdRemoteUsers)) { diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php index a685f0acb5f0..741952ece072 100644 --- a/tests/acceptance/features/bootstrap/Provisioning.php +++ b/tests/acceptance/features/bootstrap/Provisioning.php @@ -34,14 +34,17 @@ trait Provisioning { /** - * list of users that were created during test runs - * key is the username value is an array of user attributes + * list of users that were created on the local server during test runs + * key is the lowercase username, value is an array of user attributes * * @var array */ private $createdUsers = []; /** + * list of users that were created on the remote server during test runs + * key is the lowercase username, value is an array of user attributes + * * @var array */ private $createdRemoteUsers = []; @@ -66,6 +69,19 @@ trait Provisioning { */ private $createdGroups = []; + /** + * Usernames are not case-sensitive, and can generally be specified with any + * mix of upper and lower case. For remembering usernames use the normalized + * form so that "User0" and "user0" are remembered as the same user. + * + * @param string $username + * + * @return string + */ + public function normalizeUsername($username) { + return \strtolower($username); + } + /** * @return array */ @@ -99,8 +115,9 @@ public function getCurrentUserDisplayName() { * @return string */ public function getUserDisplayName($username) { - if (isset($this->createdUsers[$username]['displayname'])) { - $displayName = (string) $this->createdUsers[$username]['displayname']; + $user = $this->normalizeUsername($username); + if (isset($this->createdUsers[$user]['displayname'])) { + $displayName = (string) $this->createdUsers[$user]['displayname']; if ($displayName !== '') { return $displayName; } @@ -130,6 +147,7 @@ public function getCreatedUserDisplayNames() { * @throws \Exception */ public function getUserPassword($username) { + $username = $this->normalizeUsername($username); if ($username === $this->getAdminUsername()) { $password = $this->getAdminPassword(); } elseif (\array_key_exists($username, $this->createdUsers)) { @@ -154,6 +172,7 @@ public function getUserPassword($username) { * @throws \Exception */ public function theUserShouldExist($username) { + $username = $this->normalizeUsername($username); if (\array_key_exists($username, $this->createdUsers)) { return $this->createdUsers[$username]['shouldExist']; } @@ -1132,6 +1151,7 @@ public function initializeUser($user, $password) { public function addUserToCreatedUsersList( $user, $password, $displayName = null, $email = null, $shouldExist = true ) { + $user = $this->normalizeUsername($user); $userData = [ "password" => $password, "displayname" => $displayName, @@ -1158,6 +1178,7 @@ public function addUserToCreatedUsersList( public function rememberUserPassword( $user, $password ) { + $user = $this->normalizeUsername($user); if ($this->currentServer === 'LOCAL') { if (\array_key_exists($user, $this->createdUsers)) { $this->createdUsers[$user]['password'] = $password; @@ -1180,6 +1201,7 @@ public function rememberUserPassword( * @return void */ public function rememberThatUserIsNotExpectedToExist($user) { + $user = $this->normalizeUsername($user); if (\array_key_exists($user, $this->createdUsers)) { $this->createdUsers[$user]['shouldExist'] = false; } From 95c26ac81a0fe8dfcd3d82f246d1285e58d38f69 Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Tue, 28 May 2019 09:30:32 +0545 Subject: [PATCH 9/9] CLI tests to add and delete a user using mixed case for the username --- .../features/cliProvisioning/addUser.feature | 19 +++++++++++++++++++ .../cliProvisioning/deleteUser.feature | 9 +++++++++ 2 files changed, 28 insertions(+) diff --git a/tests/acceptance/features/cliProvisioning/addUser.feature b/tests/acceptance/features/cliProvisioning/addUser.feature index 261932c97596..f84578a35fc1 100644 --- a/tests/acceptance/features/cliProvisioning/addUser.feature +++ b/tests/acceptance/features/cliProvisioning/addUser.feature @@ -69,3 +69,22 @@ Feature: add a user using the using the occ command When the administrator creates user "brand-new-user" password " " group "brand-new-group" using the occ command Then the command should have failed with exit code 1 And user "brand-new-user" should not exist + + Scenario: admin creates a user with username that contains capital letters + When the administrator creates this user using the occ command: + | username | + | Brand-New-User | + Then the command should have been successful + And the command output should contain the text 'The user "Brand-New-User" was created successfully' + And user "Brand-New-User" should exist + And user "brand-new-user" should exist + And user "Brand-New-User" should be able to access a skeleton file + And the display name of user "brand-new-user" should be "Brand-New-User" + + Scenario: admin tries to create an existing user but with username containing capital letters + Given user "brand-new-user" has been created with default attributes + When the administrator creates this user using the occ command: + | username | + | Brand-New-User | + Then the command should have failed with exit code 1 + And the command output should contain the text 'The user "Brand-New-User" already exists' diff --git a/tests/acceptance/features/cliProvisioning/deleteUser.feature b/tests/acceptance/features/cliProvisioning/deleteUser.feature index b3519702ca90..b9a8ec5bc3de 100644 --- a/tests/acceptance/features/cliProvisioning/deleteUser.feature +++ b/tests/acceptance/features/cliProvisioning/deleteUser.feature @@ -13,6 +13,15 @@ Feature: delete users And the command output should contain the text "User with uid 'brand-new-user', display name 'brand-new-user', email '' was deleted" And user "brand-new-user" should not exist + Scenario: Delete a user, and specify the user name in different case + Given these users have been created: + | username | + | brand-new-user | + When the administrator deletes user "Brand-New-User" using the occ command + Then the OCS status code should be "100" + And the HTTP status code should be "200" + And user "brand-new-user" should not exist + Scenario: admin tries to delete a non-existing user Given user "brand-new-user" has been deleted When the administrator deletes user "brand-new-user" using the occ command