refac: DELETE /v1/user/{id}?expected_role_id=N, user.remove audit event, 409 target_role_not_found, GetAll returns its error, Own-scope visibility filter moved into repos, JSON tags removed from use-case types
This commit is contained in:
Florian Sylvain committed
1 parent
5d6f378fce
commit
b39a41be88
124 files changed
+8816
-523
No files matched your search
@@ -0,0 +1,87 @@
|
||||
Feature: Integration page: permission-gated routes and role-aware copy
|
||||
|
||||
As a developer reading the API reference
|
||||
I want routes that need a permission to say so, and the authentication copy to describe roles as they are now
|
||||
So that a key's owner knows which permission a route needs
|
||||
|
||||
Background:
|
||||
Given the spec of record is docs/design/screens/integration.md (Page copy, EndpointCard states, Error messages) and docs/design/change-log-roles-sync.md "Integration page"
|
||||
And the catalogue is web/src/data/apiCatalogue.ts and its search index; routes are gated in api/router.go by container.require(...) with the permission keys of internal/domain/role
|
||||
And the real gating is:
|
||||
| route | permission label (lib/permissionNames.ts) |
|
||||
| POST /v1/content-type/ | Create and edit content types |
|
||||
| PUT /v1/content-type/{key} | Create and edit content types |
|
||||
| DELETE /v1/content-type/{key} | Delete content types |
|
||||
| GET /v1/builtin-type/ | View content types |
|
||||
| GET /v1/builtin-type/{key} | View content types |
|
||||
| GET /v1/media/purge-settings | View settings |
|
||||
| PATCH /v1/media/purge-settings | Edit general settings |
|
||||
| GET /v1/media/purge-preview | Delete files |
|
||||
| POST /v1/media/purge | Delete files |
|
||||
And DELETE /v1/user/{id} ("Remove users") is added by features/roles_sync_remove_user.feature with the same chip
|
||||
And a missing permission answers 403 with the literal plain-text body `missing_permission`
|
||||
And the SPA lives in web/src, Nuxt UI only, design tokens only, EN and FR in i18n/messages.ts, no comments in code
|
||||
|
||||
Rule: Access chip
|
||||
|
||||
Scenario Outline: The nine routes
|
||||
Given the endpoint card <route>
|
||||
Then its access chip reads "Needs permission"
|
||||
And its description ends with the sentence Needs the permission "<permission>".
|
||||
And the chip is not "Owner or admin"
|
||||
Examples:
|
||||
| route | permission |
|
||||
| POST /v1/content-type/ | Create and edit content types |
|
||||
| PUT /v1/content-type/{key} | Create and edit content types |
|
||||
| DELETE /v1/content-type/{key} | Delete content types |
|
||||
| GET /v1/builtin-type/ | View content types |
|
||||
| GET /v1/builtin-type/{key} | View content types |
|
||||
| GET /v1/media/purge-settings | View settings |
|
||||
| PATCH /v1/media/purge-settings | Edit general settings |
|
||||
| GET /v1/media/purge-preview | Delete files |
|
||||
| POST /v1/media/purge | Delete files |
|
||||
|
||||
Scenario: The access level type
|
||||
Then the access levels are Public, Verified user, Needs permission, Owner only
|
||||
And "Owner or admin" is no longer a chip anywhere in the catalogue
|
||||
And "Owner only" stays on the routes that are owner-only
|
||||
|
||||
Scenario: The permission names stay in step with the product
|
||||
Then each permission named in a description equals the label returned by lib/permissionNames.ts for the key the router requires
|
||||
|
||||
Rule: Per-route 403 line
|
||||
|
||||
Scenario: missing_permission
|
||||
Given any of the nine expanded cards
|
||||
Then the Errors list shows a 403 chip with the caption `missing_permission` in code style
|
||||
And "Only owners and admins can do this." no longer appears
|
||||
|
||||
Scenario: The Errors table
|
||||
Then the 403 row lists "This action needs a real session.", `missing_permission` (code style, literal body) and "You must verify your account to access this resource."
|
||||
And the note under the row reads "`missing_permission` is the literal body, not a sentence. Site SEO defaults need the permission to manage sites. Article SEO fields need only the right to edit the article."
|
||||
And "Only the owner can do this." and "Only owners and admins can do this." no longer appear
|
||||
|
||||
Rule: Section copy
|
||||
|
||||
Scenario: Authentication, API key card
|
||||
Then the card reads "Send `Authorization: Bearer rcms_…`. Requests act as the user who created the key, with that user's role as it is now. A key never has more rights than its creator. A route that needs a permission answers 403 "missing_permission" to a key whose creator's role lacks it."
|
||||
And "(owner or admin)" no longer appears
|
||||
|
||||
Scenario: Content types section intro
|
||||
Then it reads "Define your own kind of content, like events or recipes. A user whose role can create and edit content types defines a type made of 1 to 50 ordered fields; the type then has its own entry routes."
|
||||
And it no longer says "An owner or admin creates a type"
|
||||
|
||||
Scenario: Entries section intro
|
||||
Then it reads "Read and write the content of a custom type. Each route needs the matching content permission of the key creator's role."
|
||||
And it no longer says "Any verified user can write entries"
|
||||
|
||||
Scenario: Sentences that still mention owner or admin
|
||||
Then no sentence of the Authentication section or the content-type and built-in groups says that owner or admin routes answer 403 to a key whose creator is neither
|
||||
|
||||
Rule: Search
|
||||
|
||||
Scenario: The search index follows the catalogue
|
||||
When the person types "permission" in the palette
|
||||
Then the permission-gated routes match through the access chip and the description, and the live region announces the count
|
||||
And typing "missing_permission" matches the error code of those routes
|
||||
And "owner or admin" no longer matches the nine routes
|
||||
Reference in new issue
Block a user