sevenhill/QSfera
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Used kebab case for example table header name (#8676)

Browse Source
This commit is contained in:
Prarup Gurung
2024-03-18 17:55:29 +05:45
committed by GitHub
parent 35b9ea7cb6
commit ebaa59637e
4 changed files with 23 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/acceptance/features/apiAccountsHashDifficulty/addUser.feature
+3 -3
View File
@@ -9,14 +9,14 @@ Feature: add user
Scenario Outline: admin creates a user Scenario Outline: admin creates a user
Given using OCS API version "<ocs_api_version>" Given using OCS API version "<ocs-api-version>"
And user "brand-new-user" has been deleted And user "brand-new-user" has been deleted
When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API When the administrator sends a user creation request for user "brand-new-user" password "%alt1%" using the provisioning API
Then the OCS status code should be "<ocs_status_code>" Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200" And the HTTP status code should be "200"
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 user "brand-new-user" should be able to access a skeleton file
Examples: Examples:
| ocs_api_version | ocs_status_code | | ocs-api-version | ocs-status-code |
| 1 | 100 | | 1 | 100 |
| 2 | 200 | | 2 | 200 |
tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature
+15 -15
View File
@@ -6,11 +6,11 @@ Feature: assign role
Scenario Outline: only admin user can see all existing roles Scenario Outline: only admin user can see all existing roles
Given user "Alice" has been created with default attributes and without skeleton files Given user "Alice" has been created with default attributes and without skeleton files
And the administrator has given "Alice" the role "<userRole>" using the settings api And the administrator has given "Alice" the role "<user-role>" using the settings api
When user "Alice" tries to get all existing roles When user "Alice" tries to get all existing roles
Then the HTTP status code should be "<statusCode>" Then the HTTP status code should be "<http-status-code>"
Examples: Examples:
| userRole | statusCode | | user-role | http-status-code |
| Admin | 201 | | Admin | 201 |
| Space Admin | 201 | | Space Admin | 201 |
| User | 201 | | User | 201 |
@@ -18,11 +18,11 @@ Feature: assign role
@issue-5032 @issue-5032
Scenario Outline: only admin user can see assignments list Scenario Outline: only admin user can see assignments list
Given user "Alice" has been created with default attributes and without skeleton files Given user "Alice" has been created with default attributes and without skeleton files
And the administrator has given "Alice" the role "<userRole>" using the settings api And the administrator has given "Alice" the role "<user-role>" using the settings api
When user "Alice" tries to get list of assignment When user "Alice" tries to get list of assignment
Then the HTTP status code should be "<statusCode>" Then the HTTP status code should be "<http-status-code>"
Examples: Examples:
| userRole | statusCode | | user-role | http-status-code |
| Admin | 201 | | Admin | 201 |
| Space Admin | 401 | | Space Admin | 401 |
| User | 401 | | User | 401 |
@@ -30,12 +30,12 @@ Feature: assign role
Scenario Outline: a user cannot change own role Scenario Outline: a user cannot change own role
Given user "Alice" has been created with default attributes and without skeleton files Given user "Alice" has been created with default attributes and without skeleton files
And the administrator has given "Alice" the role "<userRole>" using the settings api And the administrator has given "Alice" the role "<user-role>" using the settings api
When user "Alice" changes his own role to "<desiredRole>" When user "Alice" changes his own role to "<desired-role>"
Then the HTTP status code should be "400" Then the HTTP status code should be "400"
And user "Alice" should have the role "<userRole>" And user "Alice" should have the role "<user-role>"
Examples: Examples:
| userRole | desiredRole | | user-role | desired-role |
| Admin | User | | Admin | User |
| Admin | Space Admin | | Admin | Space Admin |
| Space Admin | Admin | | Space Admin | Admin |
@@ -49,12 +49,12 @@ Feature: assign role
| username | | username |
| Alice | | Alice |
| Brian | | Brian |
And the administrator has given "Alice" the role "<userRole>" using the settings api And the administrator has given "Alice" the role "<user-role>" using the settings api
When user "Alice" changes the role "<desiredRole>" for user "Brian" When user "Alice" changes the role "<desired-role>" for user "Brian"
Then the HTTP status code should be "<statusCode>" Then the HTTP status code should be "<http-status-code>"
And user "Brian" should have the role "<expectedRole>" And user "Brian" should have the role "<expected-role>"
Examples: Examples:
| userRole | desiredRole | statusCode | expectedRole | | user-role | desired-role | http-status-code | expected-role |
| Admin | User | 201 | User | | Admin | User | 201 | User |
| Admin | Space Admin | 201 | Space Admin | | Admin | Space Admin | 201 | Space Admin |
| Admin | Admin | 201 | Admin | | Admin | Admin | 201 | Admin |
tests/acceptance/features/apiAccountsHashDifficulty/createShareToSharesFolder.feature
+3 -3
View File
@@ -9,13 +9,13 @@ Feature: sharing
Scenario Outline: creating a share of a file with a user Scenario Outline: creating a share of a file with a user
Given using OCS API version "<ocs_api_version>" Given using OCS API version "<ocs-api-version>"
And user "Alice" has been created with default attributes and without skeleton files And user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Brian" has been created with default attributes and without skeleton files And user "Brian" has been created with default attributes and without skeleton files
When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0" And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0"
Examples: Examples:
| ocs_api_version | | ocs-api-version |
| 1 | | 1 |
| 2 | | 2 |
tests/acceptance/features/apiAccountsHashDifficulty/uploadFile.feature
+2 -2
View File
@@ -9,13 +9,13 @@ Feature: upload file
Scenario Outline: upload a file and check download content Scenario Outline: upload a file and check download content
Given using OCS API version "<ocs_api_version>" Given using OCS API version "<ocs-api-version>"
And user "Alice" has been created with default attributes and without skeleton files And user "Alice" has been created with default attributes and without skeleton files
And using <dav-path-version> DAV path And using <dav-path-version> DAV path
When user "Alice" uploads file with content "uploaded content" to "/upload.txt" using the WebDAV API When user "Alice" uploads file with content "uploaded content" to "/upload.txt" using the WebDAV API
Then the content of file "/upload.txt" for user "Alice" should be "uploaded content" Then the content of file "/upload.txt" for user "Alice" should be "uploaded content"
Examples: Examples:
| ocs_api_version | dav-path-version | | ocs-api-version | dav-path-version |
| 1 | old | | 1 | old |
| 1 | new | | 1 | new |
| 2 | old | | 2 | old |