82 lines
3.2 KiB
Gherkin
82 lines
3.2 KiB
Gherkin
Feature: Invitation-only private accounts
|
|
@WJ-010 @service
|
|
Scenario: Redeem an invitation exactly once
|
|
Given an unused invitation created less than seven days ago
|
|
When two different recipients redeem it concurrently
|
|
Then exactly one new account is created
|
|
And the other request is rejected
|
|
|
|
@WJ-011 @service
|
|
Scenario Outline: Reject unavailable invitations
|
|
Given an invitation that is <state>
|
|
When a new recipient attempts registration with it
|
|
Then registration is rejected
|
|
Examples:
|
|
| state |
|
|
| expired |
|
|
| revoked |
|
|
| used |
|
|
|
|
@WJ-012 @service
|
|
Scenario: Administrators cannot inspect another user's tracking data
|
|
Given Alice has work entries and habit counts
|
|
And Bob is an administrator with his own private records
|
|
When Bob requests Alice's records by their identifiers
|
|
Then no private record is returned or changed
|
|
And Bob can still administer account status
|
|
|
|
@WJ-013 @service
|
|
Scenario: Disable an account with existing sessions
|
|
Given Alice is signed in on two devices
|
|
When an administrator disables Alice's account
|
|
Then both devices are denied on their next protected request
|
|
And no new reminder is sent for Alice
|
|
And Alice's stored tracking data remains intact
|
|
|
|
@WJ-014 @service
|
|
Scenario: Expire an inactive login
|
|
Given a device login has had no user activity for thirty days
|
|
And background heartbeats have continued
|
|
When the device requests private data
|
|
Then a new login is required
|
|
|
|
@WJ-015 @browser
|
|
Scenario: Sign out everywhere
|
|
Given Alice has active sessions and push subscriptions on two devices
|
|
When Alice selects sign out everywhere
|
|
Then all her sessions are revoked
|
|
And all her push subscriptions are disabled
|
|
And each reachable client removes its local drafts
|
|
And an unreachable client removes them on its next authenticated contact
|
|
|
|
@WJ-016 @service
|
|
Scenario: Delete and register again
|
|
Given Alice has confirmed deletion using a dedicated email code
|
|
When Alice explicitly confirms account deletion
|
|
Then her active account data and access credentials are removed
|
|
When the same person redeems a new valid invitation
|
|
Then a new empty account without former permissions is created
|
|
|
|
@WJ-017 @service
|
|
Scenario: Recover after the last administrator deletes their account
|
|
Given the last administrator has deleted their account
|
|
Then the old setup code does not enable registration
|
|
When the operator explicitly enables recovery with a new one-time code
|
|
And a recipient successfully redeems that code
|
|
Then that recipient becomes administrator
|
|
And the recovery code cannot be reused
|
|
|
|
@WJ-018 @service
|
|
Scenario: Account creation requires an invitation or authorized setup code
|
|
Given a visitor has no application account
|
|
And it has no valid invitation or authorized setup code
|
|
When the visitor attempts to create an account
|
|
Then no application account or tracking access is granted
|
|
|
|
@WJ-019 @service
|
|
Scenario: Deletion requires fresh identity confirmation
|
|
Given Alice has an existing application session
|
|
When she attempts to delete her account without a fresh deletion proof
|
|
Then deletion is not performed
|
|
And a dedicated email confirmation is required
|