Skip to content

[stable10] add remove user to groups not case sensitive #35343

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
phil-davis merged 9 commits into from
May 29, 2019
Merged

[stable10] add remove user to groups not case sensitive #35343

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
00b3997
API acceptance tests for case sensitive group names
phil-davis May 27, 2019
7a5202f
CLI acceptance tests for case sensitive group names
phil-davis May 27, 2019
b114590
API acceptance tests to add and remove users in groups using mixed ca…
phil-davis May 27, 2019
8a37893
CLI acceptance tests to add and remove users in groups using mixed ca…
phil-davis May 27, 2019
8ff02f9
API acceptance tests for listing groups with different case in the name
phil-davis May 27, 2019
d09c2ef
CLI acceptance tests for listing groups with different case in the name
phil-davis May 27, 2019
06c379e
API tests to delete a user using mixed case for the username
phil-davis May 28, 2019
4e14c83
Remember normalized lowercase username in acceptance tests
phil-davis May 28, 2019
95c26ac
CLI tests to add and delete a user using mixed case for the username
phil-davis May 28, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
7 changes: 7 additions & 0 deletions tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
14 changes: 14 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" using the provisioning API
And the administrator sends a group creation request for group "<group_id2>" using the provisioning API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And group "<group_id1>" should exist
And group "<group_id2>" should exist
But group "<group_id3>" 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
Expand Down
17 changes: 17 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" has been created
And group "<group_id2>" has been created
And group "<group_id3>" has been created
When the administrator adds user "<user_id>" to group "<group_id1>" 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 "<group_id1>"
But user "brand-new-user" should not belong to group "<group_id2>"
And user "brand-new-user" should not belong to group "<group_id3>"
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
Expand Down
16 changes: 16 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" has been created
And group "<group_id2>" has been created
And group "<group_id3>" has been created
When the administrator deletes group "<group_id1>" using the provisioning API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And group "<group_id1>" should not exist
But group "<group_id2>" should exist
And group "<group_id3>" 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"
Expand Down
20 changes: 20 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" has been created
When the administrator gets all the members of group "<group_id2>" 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
Expand Down
11 changes: 11 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
20 changes: 20 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" has been created
And group "<group_id2>" has been created
And group "<group_id3>" has been created
And user "brand-new-user" has been added to group "<group_id1>"
And user "brand-new-user" has been added to group "<group_id2>"
And user "brand-new-user" has been added to group "<group_id3>"
When the administrator removes user "<user_id>" from group "<group_id1>" 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 "<group_id1>"
But user "brand-new-user" should belong to group "<group_id2>"
And user "brand-new-user" should belong to group "<group_id3>"
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
Expand Down
14 changes: 14 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" using the provisioning API
And the administrator sends a group creation request for group "<group_id2>" using the provisioning API
Then the OCS status code should be "200"
And the HTTP status code should be "200"
And group "<group_id1>" should exist
And group "<group_id2>" should exist
But group "<group_id3>" 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
Expand Down
17 changes: 17 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" has been created
And group "<group_id2>" has been created
And group "<group_id3>" has been created
When the administrator adds user "<user_id>" to group "<group_id1>" 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 "<group_id1>"
But user "brand-new-user" should not belong to group "<group_id2>"
And user "brand-new-user" should not belong to group "<group_id3>"
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
Expand Down
16 changes: 16 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" has been created
And group "<group_id2>" has been created
And group "<group_id3>" has been created
When the administrator deletes group "<group_id1>" using the provisioning API
Then the OCS status code should be "200"
And the HTTP status code should be "200"
And group "<group_id1>" should not exist
But group "<group_id2>" should exist
And group "<group_id3>" 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"
Expand Down
20 changes: 20 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" has been created
When the administrator gets all the members of group "<group_id2>" 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
Expand Down
11 changes: 11 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
20 changes: 20 additions & 0 deletions tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 "<group_id1>" has been created
And group "<group_id2>" has been created
And group "<group_id3>" has been created
And user "brand-new-user" has been added to group "<group_id1>"
And user "brand-new-user" has been added to group "<group_id2>"
And user "brand-new-user" has been added to group "<group_id3>"
When the administrator removes user "<user_id>" from group "<group_id1>" 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 "<group_id1>"
But user "brand-new-user" should belong to group "<group_id2>"
And user "brand-new-user" should belong to group "<group_id3>"
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
Expand Down
3 changes: 3 additions & 0 deletions tests/acceptance/features/bootstrap/BasicStructure.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)) {
Expand Down Expand Up @@ -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)) {
Expand Down Expand Up @@ -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)) {
Expand Down
Loading