## Problem Saving or importing an ECA model that uses a tamper action produces a config schema warning for every key the tamper plugin itself contributes: ``` eca.eca.eca_lib_0005:actions.Activity_1825os9.configuration.mode ``` `eca_data` and `eca_token_name` are fine, because `eca_tamper.schema.yml` declares them explicitly. `mode` comes from the tamper plugin's own schema, and that schema is never applied. ### Why `config/schema/eca_tamper.schema.yml` inherits the tamper plugin's schema through a dynamic type: ```yaml action.configuration.eca_tamper:*: type: tamper.[%parent.original_id] ``` `[%parent.original_id]` is resolved against the **parent configuration data**, but `original_id` is not stored in configuration. It exists only in the plugin definition, where `TamperDeriver` sets it: ```php // src/Plugin/Action/TamperDeriver.php:49 'original_id' => $definition['id'], ``` In an `eca.eca.*` model the parent of `configuration` is the action item, whose keys are: ``` label, plugin, configuration, successors ``` There is no `original_id` among them, so the dynamic type resolves to `tamper.` — which is not a defined schema — and the inherited mapping never applies. The same line exists for `eca.condition.plugin.eca_tamper_condition:*` and has the same problem. Verified on a site running eca_tamper 2.0.10 and tamper 1.0.0. Walking the typed configuration of a model that uses two `eca_tamper:encode` actions reports exactly and only: ``` actions.Activity_1825os9.configuration.mode actions.Activity_1fim0pa.configuration.mode ``` while `tamper.encode` itself is present and does define `mode`: ```yaml tamper.encode: mapping: mode: type: string label: 'Serialization mode' ``` ## Steps to reproduce 1. Install `eca_tamper`. 2. Add a "Tamper: encode" action to an ECA model and set its mode. 3. Save the model, or apply a recipe that ships it. The warning above is emitted. The stored value is otherwise correct, so this is not data loss — but the key is unvalidated, and every save and every recipe application is noisy. ## Proposed resolution Resolve the tamper schema per derivative rather than through `%parent`, since the derivative is known at the point the schema is built. A `hook_config_schema_info_alter()` implementation can register one entry per tamper plugin: ```php foreach ($this->tamperManager->getDefinitions() as $id => $definition) { foreach (["action.configuration.eca_tamper:$id", "eca.condition.plugin.eca_tamper_condition:$id"] as $key) { if (isset($definitions[$key])) { continue; } $definitions[$key] = $definitions[substr($key, 0, strrpos($key, ':')) . ':*']; $definitions[$key]['type'] = 'tamper.' . $id; } } ``` That keeps the explicit `eca_data` / `eca_token_name` mapping and gains the tamper plugin's own keys, without storing anything new in configuration and without touching existing models. Two alternatives that do not work, for the record: * `type: tamper.[%parent.plugin]` — the stored plugin ID is `eca_tamper:encode`, while the schema is named `tamper.encode`, and config schema has no way to strip the prefix. * Writing `original_id` into the action configuration — this would change stored configuration for every existing model and is a migration for a validation problem. ## Remaining tasks Review the approach and decide whether the condition side should be covered in the same change. It has the identical dynamic type and so presumably the identical symptom, though I only reproduced the action side. ## User interface changes None. ## API changes None. ## Data model changes None. Stored configuration is unchanged; only its schema coverage improves.