mirror of https://github.com/OpenVidu/openvidu.git
openvidu-dashboard: archive remove-info-license, keep only the specs
juancarmore
parent
1890b6c61f
commit
17dd82e389
|
|
@ -1,2 +0,0 @@
|
|||
schema: spec-driven
|
||||
created: 2026-10-27
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
# Design
|
||||
|
||||
## Context
|
||||
|
||||
- `InfoService.build()` reads an optional `license` callback, bound in the container to `TOKENS.LicenseInfo` (`() =>
|
||||
undefined` on CE). It spreads the result into the response only when it is defined.
|
||||
- The `GET /api/v1/info` route declares `license` as an optional object of its zod response schema, so the OpenAPI
|
||||
document shows it.
|
||||
- `FeatureKey.LICENSE_INFO` has a copy in `FEATURE_COPY`, but no route or page gates on it.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- No edition can add license data to `GET /api/v1/info`, and the OpenAPI document does not suggest it.
|
||||
|
||||
**Non-Goals:**
|
||||
- Changing `info.license` of the OpenAPI document or `apiLicense`.
|
||||
- Any other key of the info response.
|
||||
|
||||
## Decisions
|
||||
|
||||
### Remove the seam, not only the field
|
||||
|
||||
The token, the service option, the type and the schema property all go. An extending edition can no longer rebind
|
||||
`LicenseInfo`, because the token no longer exists. The response schema has no `license` property, so the document
|
||||
never declares it.
|
||||
|
||||
Alternative rejected: keeping the token with a CE default and dropping only the schema property. The response
|
||||
would still carry whatever a rebinding returned, without documentation.
|
||||
|
||||
### Drop the feature identifier
|
||||
|
||||
`license-info` gated nothing. Keeping it would advertise a feature in `features` that no page offers.
|
||||
|
||||
### OpenAPI shape
|
||||
|
||||
- `GET /api/v1/info`: the `200` schema loses `license`, and `features` items lose `license-info`.
|
||||
- Paths, parameters and status codes do not change. No query, index or performance budget is involved.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- **[Removing a key from `v1`]** → The key was never released, so the versioning policy for released fields does not
|
||||
apply.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
# Proposal
|
||||
|
||||
## Why
|
||||
|
||||
`GET /api/v1/info` declares an optional `license` block, and the feature catalogue a `license-info` key. No page
|
||||
shows either, and the dashboard is not meant to expose license data, in the UI or through the API.
|
||||
|
||||
## What Changes
|
||||
|
||||
- **BREAKING (unreleased):** `GET /api/v1/info` loses the optional `license` key: no edition reports it, and the
|
||||
OpenAPI document no longer declares it.
|
||||
- The `license-info` identifier leaves the `FeatureKey` enumeration and the lock catalogue of the UI.
|
||||
- The backend loses the `LicenseInfo` extension token, the `InfoLicense` type and the info service option that
|
||||
filled the key.
|
||||
|
||||
Scope excludes the following:
|
||||
- The OpenAPI document's `info.license` (the license of the API itself) and the `apiLicense` option of
|
||||
`startDashboard()`.
|
||||
- CE's lack of license checks, which stays as specified.
|
||||
|
||||
Edition: CE, and the seams an extending edition uses. Repository: dashboard only (`openvidu-dashboard/` in
|
||||
`OpenVidu/openvidu`).
|
||||
|
||||
CHANGELOG: none. The key and the feature identifier never shipped in a release.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
None.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- `editions-info`: the Info endpoint keys, the migration outcome requirement (replaced by one without the license)
|
||||
and the feature catalogue.
|
||||
|
||||
## Impact
|
||||
|
||||
- Typings: `api/info.ts` (`InfoLicense`, `InfoResponse.license`) and `api/features.ts` (`LICENSE_INFO`).
|
||||
- Backend: `di/tokens.ts`, `di/container.ts`, `info/info-service.ts` and `info/info-routes.ts`. Rebinding
|
||||
`LicenseInfo` from `DashboardOptions.configure` is no longer possible.
|
||||
- Frontend: `components/lock/features.ts`.
|
||||
- Tests: the typings UI contract, the info, shell and settings specs, and the settings e2e suite.
|
||||
- Docs: `dashboard-ce/backend/AGENTS.md`, which lists the extension tokens.
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Info endpoint
|
||||
|
||||
Edition: CE. With a valid bearer token `GET /api/v1/info` SHALL answer `200` with the keys `edition`, `versions`,
|
||||
`schema`, `migration`, `retention?`, `database`, `storage`, `features`, `limits` and `openapiDocsEnabled`, where
|
||||
`schema.status` is the writer schema gate's `ok`, `newer`, `older` or `uninitialized` and `openapiDocsEnabled` tells
|
||||
whether the docs routes are served.
|
||||
|
||||
#### Scenario: CE with a running writer
|
||||
|
||||
- **GIVEN** the CE dashboard 3.10.0 expects schema 1 and `schema_meta` records writer schema 1, server 3.10.0, a
|
||||
completed migration and the default retention, with the default `DASHBOARD_LIST_TOTAL_MAX_RANGE`
|
||||
- **WHEN** the client requests `GET /api/v1/info` with a valid token
|
||||
- **THEN** the response is `200` with `edition: "ce"`, `versions: { dashboard: "3.10.0", server: "3.10.0" }`,
|
||||
`schema: { dashboard: 1, writer: 1, status: "ok" }`, `migration.state: "completed"`, `migration.progress.processed`
|
||||
and `.total`, `retention: { eventsMs: 604800000, statsMs: 604800000, tracksMs: 604800000,
|
||||
entitiesMs: 7776000000, rollups5MinMs: 604800000, rollupsHourlyMs: 34560000000, rollupsDailyMs: null }`,
|
||||
`features: []`, `limits: { rankedSortMaxRangeMs: 604800000, participantRankedSortMaxRangeMs: 86400000 }` and
|
||||
`openapiDocsEnabled: false`
|
||||
|
||||
#### Scenario: Migration in progress
|
||||
|
||||
- **GIVEN** the writer's migration document has `state: 'running'`, `processed: 400000` and `total: 1200000`
|
||||
- **WHEN** the client requests `GET /api/v1/info` with a valid token
|
||||
- **THEN** `migration` is `{ state: "running", progress: { processed: 400000, total: 1200000, startedAt } }`
|
||||
|
||||
#### Scenario: Nested keys
|
||||
|
||||
- **WHEN** a client with a valid bearer token requests `GET /api/v1/info`
|
||||
- **THEN** `versions` holds `dashboard` and `server?`, `schema` holds `dashboard`, `writer?` and `status`, `migration`
|
||||
holds `state`, `progress?` and `error?`, and `limits` holds `rankedSortMaxRangeMs` and
|
||||
`participantRankedSortMaxRangeMs`
|
||||
|
||||
### Requirement: Feature catalogue
|
||||
|
||||
Edition: CE. `features` SHALL be an array of `FeatureKey` identifiers from a shared enumeration (`room-detail`,
|
||||
`participant-detail`, `egress-detail`, `ingress-detail`, `analytics-quality`, `analytics-diagnostics`,
|
||||
`analytics-top-rooms`, `track-detail`, `per-node-breakdown`), empty on CE; every PRO feature has its identifier in it.
|
||||
|
||||
#### Scenario: CE feature list
|
||||
|
||||
- **WHEN** the CE dashboard answers `GET /api/v1/info`
|
||||
- **THEN** `features` is `[]`
|
||||
|
||||
#### Scenario: Unknown identifier tolerated
|
||||
|
||||
- **GIVEN** a PRO backend newer than the UI reports a feature the UI does not know
|
||||
- **WHEN** the UI reads `features`
|
||||
- **THEN** it ignores the unknown identifier and keeps working
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Migration outcome in info
|
||||
|
||||
Edition: CE. `migration.progress` SHALL carry `processed`, `total`, `startedAt?` and `finishedAt?`, and `migration.error`
|
||||
SHALL carry the reason of a `failed` migration.
|
||||
|
||||
#### Scenario: Failed migration
|
||||
|
||||
- **GIVEN** the writer's migration document has `state: 'failed'`, `finishedAt` and `error: 'legacy event without a room'`
|
||||
- **WHEN** the client requests `GET /api/v1/info` with a valid token
|
||||
- **THEN** `migration` has `state: "failed"`, `progress.finishedAt` and `error: "legacy event without a room"`
|
||||
|
||||
## REMOVED Requirements
|
||||
|
||||
### Requirement: Migration outcome and license in info
|
||||
|
||||
**Reason**: Info no longer reports a license; the migration outcome moves to "Migration outcome in info".
|
||||
|
||||
**Migration**: None. The `license` key never shipped in a release.
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
# Tasks
|
||||
|
||||
## 1. Typings
|
||||
|
||||
- [x] 1.1 Remove `InfoLicense` and `InfoResponse.license` from `typings/src/api/info.ts`, and `LICENSE_INFO` from
|
||||
`typings/src/api/features.ts`. Drop the `license` assertion of `typings/test/ui-contract.test.ts`. Verify with the
|
||||
typings typecheck and tests.
|
||||
|
||||
## 2. Backend
|
||||
|
||||
- [x] 2.1 Remove `TOKENS.LicenseInfo`, its default binding and the `license` option of `InfoService`, and the
|
||||
`license` property of the info response schema. Verify with the backend typecheck and unit tests, and that the
|
||||
OpenAPI document of the integration suite has no `license` under the info response.
|
||||
|
||||
## 3. Frontend
|
||||
|
||||
- [x] 3.1 Remove the `license-info` entry of `FEATURE_COPY` and the uses of that identifier and of "License" in the
|
||||
info, shell and settings specs. Verify with the library unit tests.
|
||||
|
||||
## 4. Tests
|
||||
|
||||
- [x] 4.1 In `e2e/tests/settings.spec.ts`, drop the `license` of the PRO info and the "License" checks, keeping the
|
||||
PRO badge check. Verify with the e2e suite.
|
||||
|
||||
## 5. Docs and CHANGELOG
|
||||
|
||||
- [x] 5.1 Remove `LicenseInfo` from the extension tokens of `dashboard-ce/backend/AGENTS.md`. No CHANGELOG line: the
|
||||
key never shipped. Verify by reading the file against the change.
|
||||
|
||||
## 6. Integration check
|
||||
|
||||
- [x] 6.1 Run lint, format check, typecheck, spec validation, unit, integration and e2e tests. Verify that they pass.
|
||||
|
|
@ -10,9 +10,9 @@ them from the same contract.
|
|||
### Requirement: Info endpoint
|
||||
|
||||
Edition: CE. With a valid bearer token `GET /api/v1/info` SHALL answer `200` with the keys `edition`, `versions`,
|
||||
`schema`, `migration`, `retention?`, `database`, `storage`, `features`, `limits`, `license?` and `openapiDocsEnabled`,
|
||||
where `schema.status` is the writer schema gate's `ok`, `newer`, `older` or `uninitialized` and `openapiDocsEnabled`
|
||||
tells whether the docs routes are served.
|
||||
`schema`, `migration`, `retention?`, `database`, `storage`, `features`, `limits` and `openapiDocsEnabled`, where
|
||||
`schema.status` is the writer schema gate's `ok`, `newer`, `older` or `uninitialized` and `openapiDocsEnabled` tells
|
||||
whether the docs routes are served.
|
||||
|
||||
#### Scenario: CE with a running writer
|
||||
|
||||
|
|
@ -39,11 +39,10 @@ tells whether the docs routes are served.
|
|||
holds `state`, `progress?` and `error?`, and `limits` holds `rankedSortMaxRangeMs` and
|
||||
`participantRankedSortMaxRangeMs`
|
||||
|
||||
### Requirement: Migration outcome and license in info
|
||||
### Requirement: Migration outcome in info
|
||||
|
||||
Edition: CE. `migration.progress` SHALL carry `processed`, `total`, `startedAt?` and `finishedAt?`, and `migration.error`
|
||||
SHALL carry the reason of a `failed` migration. `license` (`validUntil?`, `maskedKey`) SHALL be reported only by a
|
||||
licensed PRO deployment; CE never reports it.
|
||||
SHALL carry the reason of a `failed` migration.
|
||||
|
||||
#### Scenario: Failed migration
|
||||
|
||||
|
|
@ -51,12 +50,6 @@ licensed PRO deployment; CE never reports it.
|
|||
- **WHEN** the client requests `GET /api/v1/info` with a valid token
|
||||
- **THEN** `migration` has `state: "failed"`, `progress.finishedAt` and `error: "legacy event without a room"`
|
||||
|
||||
#### Scenario: No license on CE
|
||||
|
||||
- **GIVEN** the CE dashboard
|
||||
- **WHEN** the client requests `GET /api/v1/info` with a valid token
|
||||
- **THEN** the response has no `license` property
|
||||
|
||||
### Requirement: Info fields recorded by the writer
|
||||
|
||||
Edition: CE. `versions.server`, `schema.writer`, `migration` and `retention` (`eventsMs`, `statsMs`, `tracksMs`,
|
||||
|
|
@ -118,8 +111,7 @@ subset.
|
|||
|
||||
Edition: CE. `features` SHALL be an array of `FeatureKey` identifiers from a shared enumeration (`room-detail`,
|
||||
`participant-detail`, `egress-detail`, `ingress-detail`, `analytics-quality`, `analytics-diagnostics`,
|
||||
`analytics-top-rooms`, `track-detail`, `per-node-breakdown`, `license-info`), empty on CE; every PRO feature has its
|
||||
identifier in it.
|
||||
`analytics-top-rooms`, `track-detail`, `per-node-breakdown`), empty on CE; every PRO feature has its identifier in it.
|
||||
|
||||
#### Scenario: CE feature list
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue