In the Xray Project Settings, you can manage Test Step statuses at the Project level. All Test Step statuses created at the Admin level will be displayed on the Project's Test Step statuses screen, with the option to enable or disable each status for that specific project.
|
|
If you have a status that doesn't apply to the workflow of a project, you should consider disabling it to help clean up your workflows. Technically, all statuses are Global statuses. |
1 - Is there a required permission level to view or modify these settings?
There are no additional permissions required. If you could edit the statuses at the Global level before, you would get access to the features there. Likewise, with the Project level settings, if you had access to them previously, you will be able to toggle on/off the statuses.
2 - What happens if a user disables a Step Status at the Project level?
2.1 - Will it disappear from existing Test Executions?
It follows the same pattern as deleting a status at the Global level. If the status is in use, the admin will see the screen to migrate the use of the status to an enabled one.
2.2 - Can it still be seen in historical data?
No, as it will have been migrated to a different status.
3 - Can statuses be re-enabled later without data loss?
Yes, statuses can be re-enabled with no consequence. They will effectively be a new status.
4 - Will the status options be filtered automatically in dropdowns based on Project configuration?
Yes. Wherever statuses are displayed, they will be based on the scope of the Project.
5 - Can different Projects have entirely different enabled statuses, or is there a fallback/default behavior?
All projects will have the default PASSED, TODO, EXECUTING, and FAILED statuses, as it is currently. They cannot be deleted, nor will they be able to be disabled. But other than that, they can have unique lists.
6 - Are these Project-specific settings inherited from the Global ones, or do they override them?
They are the same setting (so inherited, not overridden), but it can be done at the admin level to avoid needing to go Project by Project.
7 - Is there an audit log or trace of when a status is enabled/disabled at the Project level?
No.
8 - Are there known limitations/impacts on other features or compatibility Issues users should be aware of?
No.
9 - What’s the intended use of the project ID in the API changes?
So users can check which statuses are available for a given Project.
10 - Should external users expect these changes to impact how test statuses are returned in GraphQL queries or REST APIs?
No.
11 - Are these changes backward compatible?
Yes, since it is an optional parameter.