CVE Record State Transition Rules #364
Description
User Story
As a program member, I want the CVE Services to adhere only to allowed state transitions for records, so that record states can stay consistent and predictable.
Acceptance Criteria
General Acceptance statement:
Valid state changes to a record must also be applied to the ID object for that record. The state for a CVE ID and the Record for that CVE ID (as soon as the record is created) must stay in sync.
Scenario 1 The Record and the CVE ID states must change together
Given: A user submits a request to the update CVE endpoint PUT /cve/:cve-id
And: the user is a member of owning CNA
And: the change includes a STATE change
Then: RSUS updates the STATE for the CVE ID while applying the change to the record
And: finishes processing the request
Scenario 2: ADP or non-owning CNA changing record state
Given: A user submits a request to the update CVE endpoint PUT /cve/:cve-id
And: the user is a member of an ADP or non-Owning CNA
And: the changes include a STATE change
Then: RSUS rejects the request
And: RSUS logs the request
And: RSUS returns a 403: Forbidden with an error message a state change is only permitted by the owning CNA
Scenario 3: Specific State Change from published -> REJECTED without a reason (description)
Given: The record in question is in a PUBLIC state
When: a PUT request attempts to change the state of the record to REJECTED
Then: The record must also contain a value for the description (we must assume this to convey the reason)
Else: The API returns a 403 Forbidden with an error message that states a reason in the description is necessary to reject a public record.
Note: the schema does not allow for empty description when rejected
Scenario 4: An attempt to change a record to RESERVED
Else: The API returns a 403 Forbidden with an error message that states a record cannot be in reserved.
Scenario 5
Given: Record in Public state changing to Rejected with reason state
And: User has to be the owning CNA/CNA of last resort
And: User provides a reason in description field
Then: State gets changed
Scenario 6
Given: Record in Reserved state changing to Rejected with reason state
And: User has to be the owning CNA/CNA of last resort
And: User provides a reason in description field
Then: State gets changed
Scenario 7
Given: Record in Reject with reason state changing to Public state
And: User has to be the owning CNA/CNA of last resort
And: User provides 5.0 valid schema
And: User provides public data
Then: State gets changed
Then: Record gets updated.
Definition of Done
There is at least one unit test per scenario, proving the expectations of the scenario have been met.
There is at least one endpoint (black box) test per scenario, proving the code fulfills the scenario with the application set up similar to its production state.
The openapi.yml file has been updated to document proper use of the new endpoint.
This includes:
- Describing how different roles can interact with the system when applicable
- Successful response
- Possible error responses
- Additional comments made to properly convey the behavior changed or added if the Open API spec does not provide an appropriate medium to document it