@camstack/addon-provider-reolink 1.2.59 → 1.2.60

package/dist/addon.js

@@ -5943,6 +5943,40 @@ var BaseAddon = class {
 	deviceSettingsSchema() {
 		return null;
 	}
+	/**
+	* INTEGRATION-LEVEL SETTINGS — declare which of this addon's global sections
+	* ARE the configuration of its integration.
+	*
+	* Return the `ConfigSection.id`s, from {@link globalSettingsSchema}, that an
+	* operator should find on the addon's integration page (System →
+	* Integrations → <name>) rather than only in the cluster-wide list of every
+	* addon. Empty (the default) means the addon has no integration-level
+	* settings and no such surface is offered — this is opt-in, because whether
+	* an addon's configuration IS its integration's configuration depends on the
+	* nature of the integration.
+	*
+	* WHAT THIS IS NOT. It is not a scope. The selected sections keep living in
+	* the ONE global schema, in the ONE addon store, written by the ONE
+	* `updateGlobalSettings` path. There is deliberately no
+	* `updateIntegrationSettings`: a second write path is how a surface acquires
+	* a second store key, and this repo has shipped that twice (`btmPath@hub`,
+	* D266). Selecting sections cannot introduce a key that selecting cannot.
+	*
+	* WHY IT IS A LIST OF SECTION IDS AND NOT A MARKER ON THE SECTION.
+	* `ConfigFieldBase` used to carry `scope?: 'device' | 'global'` and it was
+	* removed with the reason recorded at
+	* `packages/types/src/interfaces/config-ui.ts:249` — *"a field's scope is
+	* determined by WHICH schema it lives in, not by a field-level marker."* A
+	* marker sprinkled across sections also has to borrow a field that already
+	* means something else; borrowing `section.tab` put the literal word
+	* "integration" into an operator-facing tab bar, because `tab` means "how to
+	* GROUP this visually" and cannot also mean "where this lives" (D269
+	* supersedes D268). One declaration, in one place, next to the schema whose
+	* ids it names.
+	*/
+	integrationSettingSections() {
+		return [];
+	}
 	async getGlobalSettings(overlay, cap, nodeId) {
 		const schema = this.globalSettingsSchema(cap);
 		if (!schema) return { sections: [] };
@@ -5953,6 +5987,55 @@ var BaseAddon = class {
 		} : projected);
 	}
 	/**
+	* The integration-level view of this addon's settings: exactly the sections
+	* named by {@link integrationSettingSections}, hydrated from the SAME store
+	* `getGlobalSettings` reads, and narrowed to cluster-scoped fields.
+	*
+	* Returns `null` when the addon declared nothing — an addon that opts out has
+	* no integration settings surface at all, rather than an empty one that reads
+	* as a failed load.
+	*
+	* Three properties hold BY CONSTRUCTION, which is why they are here in core
+	* and not in whichever UI happens to render this:
+	*
+	*  1. **One key.** The payload is a SUBSET of the global schema, so a field
+	*     shown here is the same field, with the same bare key, that the addon's
+	*     own page shows. There is no integration-specific writer — callers save
+	*     through `updateGlobalSettings` — so a second store key is unreachable,
+	*     not merely discouraged.
+	*  2. **No node scope.** `perNode: true` fields are DROPPED. Their store key
+	*     is `<key>@<nodeId>` and an integration is not a node; whichever node
+	*     such a field silently picked would be a wrong answer for the operator
+	*     who opened the page (D266).
+	*  3. **No silent typo.** A declared id that names no section throws. The
+	*     alternative — skip it — turns a rename into a surface that quietly
+	*     empties, which looks exactly like an addon with nothing to configure.
+	*/
+	async getIntegrationSettings(nodeId) {
+		const declared = this.integrationSettingSections();
+		if (declared.length === 0) return null;
+		const schema = this.globalSettingsSchema();
+		if (!schema) throw new Error(`${this.constructor.name}: integrationSettingSections() names [${declared.join(", ")}] but globalSettingsSchema() returns null.`);
+		const byId = new Map(schema.sections.map((section) => [section.id, section]));
+		const sections = [];
+		for (const id of declared) {
+			const section = byId.get(id);
+			if (!section) throw new Error(`${this.constructor.name}: integrationSettingSections() names unknown section "${id}". Known sections: [${[...byId.keys()].join(", ")}].`);
+			const fields = dropPerNodeFields(section.fields);
+			if (fields.length === 0) continue;
+			sections.push({
+				...section,
+				fields
+			});
+		}
+		if (sections.length === 0) return null;
+		const projected = await this.resolveGlobalStore(nodeId);
+		return hydrateSchema({
+			...schema,
+			sections
+		}, projected);
+	}
+	/**
 	* The raw addon store PROJECTED onto the target node's bare per-node keys:
 	* every `perNode: true` field carries THAT node's scoped value on its bare
 	* key (absent scoped key ⇒ key absent, so the schema `default` wins — no
@@ -6256,6 +6339,41 @@ var BaseAddon = class {
 * `hydrateSchema` does. Valueless structural fields (separator/info/…)
 * don't declare `perNode` and are excluded by the `in` narrowing.
 */
+/**
+* The same fields with every `perNode: true` one removed, recursing into layout
+* containers exactly as {@link collectPerNodeFieldKeys} does. A container left
+* with no child is dropped rather than rendered empty.
+*
+* Used by `getIntegrationSettings`: an integration is not a node, so a field
+* whose store key is `<key>@<nodeId>` has no node to belong to there.
+*/
+function dropPerNodeFields(fields) {
+	const kept = [];
+	for (const field of fields) {
+		if (field.type === "group") {
+			const inner = dropPerNodeFields(field.fields);
+			if (inner.length > 0) kept.push({
+				...field,
+				fields: inner
+			});
+			continue;
+		}
+		if (field.type === "sub-tabs") {
+			const tabs = field.tabs.map((tab) => ({
+				...tab,
+				fields: dropPerNodeFields(tab.fields)
+			})).filter((tab) => tab.fields.length > 0);
+			if (tabs.length > 0) kept.push({
+				...field,
+				tabs
+			});
+			continue;
+		}
+		if ("perNode" in field && field.perNode === true) continue;
+		kept.push(field);
+	}
+	return kept;
+}
 function collectPerNodeFieldKeys(fields) {
 	const collected = [];
 	for (const field of fields) {
@@ -9863,6 +9981,9 @@ method(object({
 	kind: "mutation",
 	auth: "admin"
 }), method(object({
+	addonId: string(),
+	nodeId: string().optional()
+}), SettingsSchemaWithValuesSchema.nullable()), method(object({
 	addonId: string(),
 	deviceId: number(),
 	nodeId: string().optional()
@@ -32545,6 +32666,12 @@ Object.freeze({
 		addonId: null,
 		access: "view"
 	},
+	"addonSettings.getIntegrationSettings": {
+		capName: "addon-settings",
+		capScope: "system",
+		addonId: null,
+		access: "view"
+	},
 	"addonSettings.updateDeviceSettings": {
 		capName: "addon-settings",
 		capScope: "system",
@@ -240899,6 +241026,12 @@ var ReolinkEmailPushServer = class {
 //#endregion
 //#region src/email-push-schema.ts
 /**
+* The ids of the sections above, in render order — the value the addon hands
+* to `BaseAddon.integrationSettingSections()`. Exported so the declaration and
+* the schema cannot drift: core throws if an id here names no section.
+*/
+var EMAIL_PUSH_SECTION_IDS = ["email-push", "email-push-auth"];
+/**
 * Addon-level settings UI for the Reolink email/SMTP push intake.
 *
 * Rendered under the provider's addon settings (Cluster → addon config).
@@ -240910,6 +241043,28 @@ var ReolinkEmailPushServer = class {
 * `requiresRestart` is intentionally NOT set — the provider handles the
 * restart itself in `onConfigChanged` (a targeted SMTP rebind, not a full
 * addon teardown).
+*
+* ── These sections ARE the Reolink integration's configuration ──────────
+*
+* Both are declared in `ReolinkAddon.integrationSettingSections()`, so core
+* serves them on System → Integrations → Reolink. The operator looks for "the
+* Reolink SMTP port" under Reolink; this puts it there.
+*
+* They EARN that placement, and the reason is the test any future declaration
+* must pass: they configure ONE SMTP server in ONE provider process, serving
+* every Reolink camera at once. There is no per-camera copy to confuse them
+* with, which is exactly why a per-camera home would be nonsense and a
+* per-integration home is correct. A setting that differs per camera belongs
+* in `deviceSettingsSchema`, never here.
+*
+* The declaration does not move the values: they remain the same bare keys in
+* the same addon store, still reachable from System → Settings, still written
+* by `updateGlobalSettings` — there is no integration-specific writer at all.
+* See ADR-0269.
+*
+* `tab` is deliberately NOT used to express this. It means "how to group this
+* visually", and an earlier design that overloaded it put the literal word
+* "integration" into an operator-facing tab bar (D268 → D269).
 */
 function buildEmailPushSettingsSchema(recommendedHost) {
 	return { sections: [{
@@ -241278,9 +241433,30 @@ var ReolinkProviderAddon = class extends BaseDeviceProvider {
 			this.ctx.logger.warn("email-push: restart after settings change failed", { meta: { error: err instanceof Error ? err.message : String(err) } });
 		});
 	}
-	async getGlobalSettings() {
-		const raw = await this.resolveGlobalStore();
-		return hydrateSchema(buildEmailPushSettingsSchema(listLanHosts()[0] ?? "127.0.0.1"), raw);
+	/**
+	* The addon's global settings schema.
+	*
+	* This used to override `getGlobalSettings()` wholesale, on the belief that a
+	* dynamic `recommendedHost` could not come from a static schema declaration.
+	* It can: `listLanHosts()` is synchronous, so the schema builder runs here
+	* and `BaseAddon.getGlobalSettings` does the identical
+	* `resolveGlobalStore` + `hydrateSchema` the override did by hand.
+	*
+	* Declaring the SCHEMA rather than overriding the GETTER is what lets core
+	* serve `getIntegrationSettings()` — it selects the declared sections out of
+	* this schema, so an addon that hides its schema behind a getter has nothing
+	* for core to select from.
+	*/
+	globalSettingsSchema() {
+		return buildEmailPushSettingsSchema(listLanHosts()[0] ?? "127.0.0.1");
+	}
+	/**
+	* Both email-push sections ARE this integration's configuration — one SMTP
+	* server serving every Reolink camera. See `email-push-schema.ts` for why
+	* that earns a per-integration home and not a per-camera one.
+	*/
+	integrationSettingSections() {
+		return EMAIL_PUSH_SECTION_IDS;
 	}
 	async onInitialize() {
 		const regs = await super.onInitialize();

package/dist/addon.mjs

@@ -5938,6 +5938,40 @@ var BaseAddon = class {
 	deviceSettingsSchema() {
 		return null;
 	}
+	/**
+	* INTEGRATION-LEVEL SETTINGS — declare which of this addon's global sections
+	* ARE the configuration of its integration.
+	*
+	* Return the `ConfigSection.id`s, from {@link globalSettingsSchema}, that an
+	* operator should find on the addon's integration page (System →
+	* Integrations → <name>) rather than only in the cluster-wide list of every
+	* addon. Empty (the default) means the addon has no integration-level
+	* settings and no such surface is offered — this is opt-in, because whether
+	* an addon's configuration IS its integration's configuration depends on the
+	* nature of the integration.
+	*
+	* WHAT THIS IS NOT. It is not a scope. The selected sections keep living in
+	* the ONE global schema, in the ONE addon store, written by the ONE
+	* `updateGlobalSettings` path. There is deliberately no
+	* `updateIntegrationSettings`: a second write path is how a surface acquires
+	* a second store key, and this repo has shipped that twice (`btmPath@hub`,
+	* D266). Selecting sections cannot introduce a key that selecting cannot.
+	*
+	* WHY IT IS A LIST OF SECTION IDS AND NOT A MARKER ON THE SECTION.
+	* `ConfigFieldBase` used to carry `scope?: 'device' | 'global'` and it was
+	* removed with the reason recorded at
+	* `packages/types/src/interfaces/config-ui.ts:249` — *"a field's scope is
+	* determined by WHICH schema it lives in, not by a field-level marker."* A
+	* marker sprinkled across sections also has to borrow a field that already
+	* means something else; borrowing `section.tab` put the literal word
+	* "integration" into an operator-facing tab bar, because `tab` means "how to
+	* GROUP this visually" and cannot also mean "where this lives" (D269
+	* supersedes D268). One declaration, in one place, next to the schema whose
+	* ids it names.
+	*/
+	integrationSettingSections() {
+		return [];
+	}
 	async getGlobalSettings(overlay, cap, nodeId) {
 		const schema = this.globalSettingsSchema(cap);
 		if (!schema) return { sections: [] };
@@ -5948,6 +5982,55 @@ var BaseAddon = class {
 		} : projected);
 	}
 	/**
+	* The integration-level view of this addon's settings: exactly the sections
+	* named by {@link integrationSettingSections}, hydrated from the SAME store
+	* `getGlobalSettings` reads, and narrowed to cluster-scoped fields.
+	*
+	* Returns `null` when the addon declared nothing — an addon that opts out has
+	* no integration settings surface at all, rather than an empty one that reads
+	* as a failed load.
+	*
+	* Three properties hold BY CONSTRUCTION, which is why they are here in core
+	* and not in whichever UI happens to render this:
+	*
+	*  1. **One key.** The payload is a SUBSET of the global schema, so a field
+	*     shown here is the same field, with the same bare key, that the addon's
+	*     own page shows. There is no integration-specific writer — callers save
+	*     through `updateGlobalSettings` — so a second store key is unreachable,
+	*     not merely discouraged.
+	*  2. **No node scope.** `perNode: true` fields are DROPPED. Their store key
+	*     is `<key>@<nodeId>` and an integration is not a node; whichever node
+	*     such a field silently picked would be a wrong answer for the operator
+	*     who opened the page (D266).
+	*  3. **No silent typo.** A declared id that names no section throws. The
+	*     alternative — skip it — turns a rename into a surface that quietly
+	*     empties, which looks exactly like an addon with nothing to configure.
+	*/
+	async getIntegrationSettings(nodeId) {
+		const declared = this.integrationSettingSections();
+		if (declared.length === 0) return null;
+		const schema = this.globalSettingsSchema();
+		if (!schema) throw new Error(`${this.constructor.name}: integrationSettingSections() names [${declared.join(", ")}] but globalSettingsSchema() returns null.`);
+		const byId = new Map(schema.sections.map((section) => [section.id, section]));
+		const sections = [];
+		for (const id of declared) {
+			const section = byId.get(id);
+			if (!section) throw new Error(`${this.constructor.name}: integrationSettingSections() names unknown section "${id}". Known sections: [${[...byId.keys()].join(", ")}].`);
+			const fields = dropPerNodeFields(section.fields);
+			if (fields.length === 0) continue;
+			sections.push({
+				...section,
+				fields
+			});
+		}
+		if (sections.length === 0) return null;
+		const projected = await this.resolveGlobalStore(nodeId);
+		return hydrateSchema({
+			...schema,
+			sections
+		}, projected);
+	}
+	/**
 	* The raw addon store PROJECTED onto the target node's bare per-node keys:
 	* every `perNode: true` field carries THAT node's scoped value on its bare
 	* key (absent scoped key ⇒ key absent, so the schema `default` wins — no
@@ -6251,6 +6334,41 @@ var BaseAddon = class {
 * `hydrateSchema` does. Valueless structural fields (separator/info/…)
 * don't declare `perNode` and are excluded by the `in` narrowing.
 */
+/**
+* The same fields with every `perNode: true` one removed, recursing into layout
+* containers exactly as {@link collectPerNodeFieldKeys} does. A container left
+* with no child is dropped rather than rendered empty.
+*
+* Used by `getIntegrationSettings`: an integration is not a node, so a field
+* whose store key is `<key>@<nodeId>` has no node to belong to there.
+*/
+function dropPerNodeFields(fields) {
+	const kept = [];
+	for (const field of fields) {
+		if (field.type === "group") {
+			const inner = dropPerNodeFields(field.fields);
+			if (inner.length > 0) kept.push({
+				...field,
+				fields: inner
+			});
+			continue;
+		}
+		if (field.type === "sub-tabs") {
+			const tabs = field.tabs.map((tab) => ({
+				...tab,
+				fields: dropPerNodeFields(tab.fields)
+			})).filter((tab) => tab.fields.length > 0);
+			if (tabs.length > 0) kept.push({
+				...field,
+				tabs
+			});
+			continue;
+		}
+		if ("perNode" in field && field.perNode === true) continue;
+		kept.push(field);
+	}
+	return kept;
+}
 function collectPerNodeFieldKeys(fields) {
 	const collected = [];
 	for (const field of fields) {
@@ -9858,6 +9976,9 @@ method(object({
 	kind: "mutation",
 	auth: "admin"
 }), method(object({
+	addonId: string(),
+	nodeId: string().optional()
+}), SettingsSchemaWithValuesSchema.nullable()), method(object({
 	addonId: string(),
 	deviceId: number(),
 	nodeId: string().optional()
@@ -32540,6 +32661,12 @@ Object.freeze({
 		addonId: null,
 		access: "view"
 	},
+	"addonSettings.getIntegrationSettings": {
+		capName: "addon-settings",
+		capScope: "system",
+		addonId: null,
+		access: "view"
+	},
 	"addonSettings.updateDeviceSettings": {
 		capName: "addon-settings",
 		capScope: "system",
@@ -240879,6 +241006,12 @@ var ReolinkEmailPushServer = class {
 //#endregion
 //#region src/email-push-schema.ts
 /**
+* The ids of the sections above, in render order — the value the addon hands
+* to `BaseAddon.integrationSettingSections()`. Exported so the declaration and
+* the schema cannot drift: core throws if an id here names no section.
+*/
+var EMAIL_PUSH_SECTION_IDS = ["email-push", "email-push-auth"];
+/**
 * Addon-level settings UI for the Reolink email/SMTP push intake.
 *
 * Rendered under the provider's addon settings (Cluster → addon config).
@@ -240890,6 +241023,28 @@ var ReolinkEmailPushServer = class {
 * `requiresRestart` is intentionally NOT set — the provider handles the
 * restart itself in `onConfigChanged` (a targeted SMTP rebind, not a full
 * addon teardown).
+*
+* ── These sections ARE the Reolink integration's configuration ──────────
+*
+* Both are declared in `ReolinkAddon.integrationSettingSections()`, so core
+* serves them on System → Integrations → Reolink. The operator looks for "the
+* Reolink SMTP port" under Reolink; this puts it there.
+*
+* They EARN that placement, and the reason is the test any future declaration
+* must pass: they configure ONE SMTP server in ONE provider process, serving
+* every Reolink camera at once. There is no per-camera copy to confuse them
+* with, which is exactly why a per-camera home would be nonsense and a
+* per-integration home is correct. A setting that differs per camera belongs
+* in `deviceSettingsSchema`, never here.
+*
+* The declaration does not move the values: they remain the same bare keys in
+* the same addon store, still reachable from System → Settings, still written
+* by `updateGlobalSettings` — there is no integration-specific writer at all.
+* See ADR-0269.
+*
+* `tab` is deliberately NOT used to express this. It means "how to group this
+* visually", and an earlier design that overloaded it put the literal word
+* "integration" into an operator-facing tab bar (D268 → D269).
 */
 function buildEmailPushSettingsSchema(recommendedHost) {
 	return { sections: [{
@@ -241258,9 +241413,30 @@ var ReolinkProviderAddon = class extends BaseDeviceProvider {
 			this.ctx.logger.warn("email-push: restart after settings change failed", { meta: { error: err instanceof Error ? err.message : String(err) } });
 		});
 	}
-	async getGlobalSettings() {
-		const raw = await this.resolveGlobalStore();
-		return hydrateSchema(buildEmailPushSettingsSchema(listLanHosts()[0] ?? "127.0.0.1"), raw);
+	/**
+	* The addon's global settings schema.
+	*
+	* This used to override `getGlobalSettings()` wholesale, on the belief that a
+	* dynamic `recommendedHost` could not come from a static schema declaration.
+	* It can: `listLanHosts()` is synchronous, so the schema builder runs here
+	* and `BaseAddon.getGlobalSettings` does the identical
+	* `resolveGlobalStore` + `hydrateSchema` the override did by hand.
+	*
+	* Declaring the SCHEMA rather than overriding the GETTER is what lets core
+	* serve `getIntegrationSettings()` — it selects the declared sections out of
+	* this schema, so an addon that hides its schema behind a getter has nothing
+	* for core to select from.
+	*/
+	globalSettingsSchema() {
+		return buildEmailPushSettingsSchema(listLanHosts()[0] ?? "127.0.0.1");
+	}
+	/**
+	* Both email-push sections ARE this integration's configuration — one SMTP
+	* server serving every Reolink camera. See `email-push-schema.ts` for why
+	* that earns a per-integration home and not a per-camera one.
+	*/
+	integrationSettingSections() {
+		return EMAIL_PUSH_SECTION_IDS;
 	}
 	async onInitialize() {
 		const regs = await super.onInitialize();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@camstack/addon-provider-reolink",
-  "version": "1.2.59",
+  "version": "1.2.60",
   "description": "Reolink camera device provider addon for CamStack — native Baichuan protocol",
   "keywords": [
     "camstack",