Feature Requests

Add an Public API endpoint that returns information about which user a given authentication token belongs to. Could be useful for Debugging authentication issues Fetching user role and type

Our automation team uses the Qase v2 API for uploading bulk test results at the end of an automation test run. It would be nice to be able to include the tags we have on our Cucumber tests in the API request to be synced to Qase. As an example, the following JSON would set the Tags on the the Qase Test Case to "Bugged" and "Login". { "execution": { "status": "passed" }, "fields": { "tags": [ "Bugged", "Login" ] }, ... } This would be helpful for us to have an additional way to filter on test cases.

Please add or extend APIs to support retrieving "assignee" for cases in TestRun. I want to use it in our custom application.

When I run my automated test suite via Robot Framework, the pass/fail results are sent to a test run in Qase. It would be extremely beneficial if I was able to also attach the automation report (includes detailed steps and screenshots).

It would be a great addition to choose whether a test run is always updated when tests are run in pytest or whether the test run is only updated when the tests pass. For example, there are tests which are executed daily and we require at least 1 pass. This means that I only want to update the test run corresponding to these daily tests, when a test inside pytest has passed. If a test from this set of tests subsequently failed, I would not want to update the test run's corresponding test as failed, since I only require a single pass.

Currently, the traceability reports only bring in the github issues. Now that issues can be linked to others within github, it would be nice to see that same hierarchy being translated into the reports.

Currently, there's no way to link an external app issue such as a Jira story to a Qase test run via the API. An example use case being an option to specify the associated Jira ticket for an automated test run, say in the form of an environment variable or CLI option. A suggested workaround is to include the Jira defect link in the run’s description, which is already a parameter in the run_create endpoint. Since the description field supports Markdown, the link could be formatted as follows: **Jira Story:** [ABC-123](https://your-site.atlassian.net/ABC/123) But, it would be better to have the link defined in the designated feature for consistency.

Currently, there is no way to automatically mark an *Automated test run as “Aborted” either via the UI or from the Qase's Public API. This limitation impacts test automation workflows, as users need to recognise stalled or failed runs. For example, an unexpected failure or system-level non-zero exit status, then test run in Qase could be marked with 'Aborted' status. Eg: Pytest exit codes: https://docs.pytest.org/en/stable/reference/exit-codes.html

Description Currently, with all of Qase reporters on v2.x, custom field data is recorded in the test result but is not updated at the test case level. This applies whether a Qase ID is present or not. Behavior When no Qase ID is present and Auto-Create is ON: If a custom field with the same name exists, its value is recorded in the result. However, values are not updated at the test case level. When a Qase ID is present and update is ON: The behavior remains the same—custom field values are recorded in the result but not updated in the test case. Request To add an option to update custom field data at the test case level in addition to the result. Why? Enabling this feature would ensure that test case data stays up to date with the latest test results, reducing manual updates and improving data consistency across code, results, and test case in repository.

Scenario: I’m running an end-to-end (E2E) test with Playwright configured as follows: • Browser: Chrome • Theme: Dark mode • App Version: Android Currently, there is no option to set these configuration parameters directly in the reporter options. As a result, users must manually edit these settings through the UI after the test run. Suggestion: Implement a feature that allows users to start a test run with predefined configuration options. If these configurations do not already exist, the system should automatically create them and link them to the test run.