Add provisioning API tests for usernames with special characters

owncloud · Dec 20, 2019 · 8be87ce · 8be87ce
1 parent c8ba37a
commit 8be87ce
Show file tree

Hide file tree

Showing 12 changed files with 160 additions and 0 deletions.
diff --git a/tests/acceptance/features/apiProvisioning-v1/addUser.feature b/tests/acceptance/features/apiProvisioning-v1/addUser.feature
@@ -16,6 +16,18 @@ Feature: add user
     And user "brand-new-user" should exist
     And user "brand-new-user" should be able to access a skeleton file
 
+  Scenario Outline: admin creates a user with special characters in the username
+    Given user "<username>" has been deleted
+    When the administrator sends a user creation request for user "<username>" password "%alt1%" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And user "<username>" should exist
+    And user "<username>" should be able to access a skeleton file
+    Examples:
+      | username |
+      | a@-+_.b  |
+      | a space  |
+
   Scenario: admin tries to create an existing user
     Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API

diff --git a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
@@ -15,6 +15,19 @@ Feature: delete users
     And the HTTP status code should be "200"
     And user "brand-new-user" should not exist
 
+  Scenario Outline: Delete a user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | email   |
+      | <username> | <email> |
+    When the administrator deletes user "<username>" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And user "<username>" should not exist
+    Examples:
+      | username | email               |
+      | a@-+_.b  | a.b@example.com     |
+      | a space  | a.space@example.com |
+
   Scenario: Delete a user, and specify the user name in different case
     Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator deletes user "Brand-New-User" using the provisioning API

diff --git a/tests/acceptance/features/apiProvisioning-v1/disableUser.feature b/tests/acceptance/features/apiProvisioning-v1/disableUser.feature
@@ -15,6 +15,19 @@ Feature: disable user
     And the HTTP status code should be "200"
     And user "user1" should be disabled
 
+  Scenario Outline: admin disables an user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | email   |
+      | <username> | <email> |
+    When the administrator disables user "<username>" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And user "<username>" should be disabled
+    Examples:
+      | username | email               |
+      | a@-+_.b  | a.b@example.com     |
+      | a space  | a.space@example.com |
+
   @smokeTest
   Scenario: Subadmin should be able to disable an user in their group
     Given these users have been created with default attributes and skeleton files:

diff --git a/tests/acceptance/features/apiProvisioning-v1/editUser.feature b/tests/acceptance/features/apiProvisioning-v1/editUser.feature
@@ -15,6 +15,19 @@ Feature: edit users
     And the OCS status code should be "100"
     And the email address of user "brand-new-user" should be "[email protected]"
 
+  Scenario Outline: the administrator can edit a user email of an user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | email   |
+      | <username> | <email> |
+    When the administrator changes the email of user "<username>" to "[email protected]" using the provisioning API
+    Then the HTTP status code should be "200"
+    And the OCS status code should be "100"
+    And the email address of user "<username>" should be "[email protected]"
+    Examples:
+      | username | email               |
+      | a@-+_.b  | a.b@example.com     |
+      | a space  | a.space@example.com |
+
   @smokeTest
   Scenario: the administrator can edit a user display (the API allows editing the "display name" by using the key word "display")
     Given user "brand-new-user" has been created with default attributes and skeleton files

diff --git a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature
@@ -16,6 +16,20 @@ Feature: enable user
     And the HTTP status code should be "200"
     And user "user1" should be enabled
 
+  Scenario Outline: admin enables an user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | email   |
+      | <username> | <email> |
+    And user "<username>" has been disabled
+    When the administrator enables user "<username>" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And user "<username>" should be enabled
+    Examples:
+      | username | email               |
+      | a@-+_.b  | a.b@example.com     |
+      | a space  | a.space@example.com |
+
   Scenario: admin enables another admin user
     Given user "another-admin" has been created with default attributes and skeleton files
     And user "another-admin" has been added to group "admin"

diff --git a/tests/acceptance/features/apiProvisioning-v1/getUser.feature b/tests/acceptance/features/apiProvisioning-v1/getUser.feature
@@ -18,6 +18,21 @@ Feature: get user
     And the display name returned by the API should be "Brand New User"
     And the quota definition returned by the API should be "default"
 
+  Scenario Outline: admin gets an existing user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | displayname   | email   |
+      | <username> | <displayname> | <email> |
+    When the administrator retrieves the information of user "<username>" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And the display name returned by the API should be "<displayname>"
+    And the email address returned by the API should be "<email>"
+    And the quota definition returned by the API should be "default"
+    Examples:
+      | username | displayname  | email               |
+      | a@-+_.b  | A weird b    | a.b@example.com     |
+      | a space  | A Space Name | a.space@example.com |
+
   Scenario: admin tries to get a not existing user
     When the administrator retrieves the information of user "not-a-user" using the provisioning API
     Then the OCS status code should be "998"

diff --git a/tests/acceptance/features/apiProvisioning-v2/addUser.feature b/tests/acceptance/features/apiProvisioning-v2/addUser.feature
@@ -16,6 +16,18 @@ Feature: add user
     And user "brand-new-user" should exist
     And user "brand-new-user" should be able to access a skeleton file
 
+  Scenario Outline: admin creates a user with special characters in the username
+    Given user "<username>" has been deleted
+    When the administrator sends a user creation request for user "<username>" password "%alt1%" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And user "<username>" should exist
+    And user "<username>" should be able to access a skeleton file
+    Examples:
+      | username |
+      | a@-+_.b  |
+      | a space  |
+
   Scenario: admin tries to create an existing user
     Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API

diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
@@ -15,6 +15,19 @@ Feature: delete users
     And the HTTP status code should be "200"
     And user "brand-new-user" should not exist
 
+  Scenario Outline: Delete a user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | email   |
+      | <username> | <email> |
+    When the administrator deletes user "<username>" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And user "<username>" should not exist
+    Examples:
+      | username | email               |
+      | a@-+_.b  | a.b@example.com     |
+      | a space  | a.space@example.com |
+
   Scenario: Delete a user, and specify the user name in different case
     Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator deletes user "Brand-New-User" using the provisioning API

diff --git a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature
@@ -15,6 +15,19 @@ Feature: disable user
     And the HTTP status code should be "200"
     And user "user1" should be disabled
 
+  Scenario Outline: admin disables an user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | email   |
+      | <username> | <email> |
+    When the administrator disables user "<username>" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And user "<username>" should be disabled
+    Examples:
+      | username | email               |
+      | a@-+_.b  | a.b@example.com     |
+      | a space  | a.space@example.com |
+
   @smokeTest
   Scenario: Subadmin should be able to disable an user in their group
     Given these users have 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
@@ -15,6 +15,19 @@ Feature: edit users
     And the OCS status code should be "200"
     And the email address of user "brand-new-user" should be "[email protected]"
 
+  Scenario Outline: the administrator can edit a user email of an user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | email   |
+      | <username> | <email> |
+    When the administrator changes the email of user "<username>" to "[email protected]" using the provisioning API
+    Then the HTTP status code should be "200"
+    And the OCS status code should be "200"
+    And the email address of user "<username>" should be "[email protected]"
+    Examples:
+      | username | email               |
+      | a@-+_.b  | a.b@example.com     |
+      | a space  | a.space@example.com |
+
   @smokeTest
   Scenario: the administrator can edit a user display (the API allows editing the "display name" by using the key word "display")
     Given user "brand-new-user" has been created with default attributes and skeleton files

diff --git a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature
@@ -16,6 +16,20 @@ Feature: enable user
     And the HTTP status code should be "200"
     And user "user1" should be enabled
 
+  Scenario Outline: admin enables an user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | email   |
+      | <username> | <email> |
+    And user "<username>" has been disabled
+    When the administrator enables user "<username>" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And user "<username>" should be enabled
+    Examples:
+      | username | email               |
+      | a@-+_.b  | a.b@example.com     |
+      | a space  | a.space@example.com |
+
   Scenario: admin enables another admin user
     Given user "another-admin" has been created with default attributes and skeleton files
     And user "another-admin" has been added to group "admin"

diff --git a/tests/acceptance/features/apiProvisioning-v2/getUser.feature b/tests/acceptance/features/apiProvisioning-v2/getUser.feature
@@ -18,6 +18,21 @@ Feature: get user
     And the display name returned by the API should be "Brand New User"
     And the quota definition returned by the API should be "default"
 
+  Scenario Outline: admin gets an existing user with special characters in the username
+    Given these users have been created with skeleton files:
+      | username   | displayname   | email   |
+      | <username> | <displayname> | <email> |
+    When the administrator retrieves the information of user "<username>" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And the display name returned by the API should be "<displayname>"
+    And the email address returned by the API should be "<email>"
+    And the quota definition returned by the API should be "default"
+    Examples:
+      | username | displayname  | email               |
+      | a@-+_.b  | A weird b    | a.b@example.com     |
+      | a space  | A Space Name | a.space@example.com |
+
   Scenario: admin tries to get a not existing user
     When the administrator retrieves the information of user "not-a-user" using the provisioning API
     Then the OCS status code should be "404"