The flow we need to cover: a standard user submits an expense claim, an admin approves it, and the standard user sees it move to approved.
@user:standard gives me one role. I cannot see how to get a second one without splitting this into two scenarios that depend on each other, which the tagging policy tells me not to do. What is the intended way?
Accepted answer
Give the browser one role and the second role the API.
@hybrid @regression @user:standard
Scenario: An admin approves a submitted claim
Given I am on the claims page
When I submit a claim for "48.20"
And I use a leased user with role "admin" for API calls
And I send a POST request to "/claims/{{claimId}}/approve"
Then the response status should be 200
And the claim "{{claimId}}" should show status "Approved"The for API calls variant of the leased-user step leases an admin and leaves the browser context alone, so the page keeps the standard user's session. It is in the core data steps. One caveat: it only puts a bearer token on the API client when your auth strategy exposes one, or when sdods auth capture already wrote one for that user. Otherwise it says so in the log and the request goes out with the environment credential, which is usually not the admin you wanted.
That is not a workaround, incidentally — the approval is a state change, and driving it over HTTP is faster and less brittle than driving a second person's UI. What you are testing in the browser is that the standard user sees the result.
If you genuinely need two simultaneous browser sessions — a chat, a live-updating board — that is a project step opening its own context, and you give up the cached storage state for the second one. Worth being sure you need it first.
Have the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question