feat: el agente puede declarar y leer las cmsTables de un modulo
Las cmsTables (tablas del CMS cuyo contenido MUESTRA un modulo) ya se definen desde Forge y desde el CMS legacy; faltaba que el agente las entendiera. - update_module_metadata acepta cmsTables. El endpoint del server ya la validaba, asi que solo habia que declararla en el schema Zod. - get_module_config_vars la devuelve: sale gratis porque el handler ya resolvia el schema del modulo para uploadFields/varsMeta. - Docs (01, 03, 09) con el matiz que mas se puede confundir: `tables` es donde viven los VALORES de las vars (siempre builder_custom, lo pone el compilador) y `cmsTables` es que contenido MUESTRA el modulo. Para el agente lo util no es solo escribirlas: al recibirlas sabe donde esta de verdad el contenido visible. Si le piden cambiar lo que muestra un listado de noticias, los registros estan en esa tabla, no en las vars del modulo. Se documenta ademas que la metadata del builder.json es la UNICA parte editable del fichero (y solo con esta tool): el resto lo regenera el compilador en cada compilacion.
This commit is contained in:
@@ -7,22 +7,27 @@ import { getCurrentProjectInfo } from "../files/helpers.js";
|
||||
|
||||
// Tool: update_module_metadata
|
||||
// Edita la metadata de builder.json de un modulo (label, description,
|
||||
// onlyAdminModule, MJMLModule) delegando en /api/modules/update-metadata.
|
||||
// El id/carpeta del modulo NO se puede renombrar y el endpoint rechaza los
|
||||
// modulos generados del layout (custom-header/footer[-twig]).
|
||||
// onlyAdminModule, MJMLModule, cmsTables) delegando en
|
||||
// /api/modules/update-metadata. El id/carpeta del modulo NO se puede renombrar
|
||||
// y el endpoint rechaza los modulos generados del layout
|
||||
// (custom-header/footer[-twig]).
|
||||
|
||||
// Claves editables del builder.json. Se envian solo las que llegan definidas,
|
||||
// de modo que el endpoint hace un merge parcial y no pisa el resto.
|
||||
const EDITABLE_KEYS = ["label", "description", "onlyAdminModule", "MJMLModule"];
|
||||
const EDITABLE_KEYS = ["label", "description", "onlyAdminModule", "MJMLModule", "cmsTables"];
|
||||
|
||||
export function registerUpdateModuleMetadataTool(server) {
|
||||
server.tool(
|
||||
"update_module_metadata",
|
||||
`Edit a module's metadata in its builder.json: 'label' (display name shown in the visual builder), 'description' (short help text for editors), 'onlyAdminModule' (true = the module is only visible to admin users in the builder), 'MJMLModule' (true = the module is an email/MJML module).
|
||||
`Edit a module's metadata in its builder.json: 'label' (display name shown in the visual builder), 'description' (short help text for editors), 'onlyAdminModule' (true = the module is only visible to admin users in the builder), 'MJMLModule' (true = the module is an email/MJML module), 'cmsTables' (CMS tables whose content this module displays).
|
||||
|
||||
Use 'cmsTables' when the module renders records from a CMS table — a news list, a product grid, a blog carousel. Declare the tables it reads (e.g. ["noticias"]). The editor then shows a direct link to each of those tables from any page that includes the module, so whoever edits that page can reach the content without hunting for it. A module that only shows its own variables (a banner with a title and an image) needs no cmsTables.
|
||||
|
||||
Do NOT confuse 'cmsTables' with the 'tables' key of builder.json: 'tables' is where the module's VARIABLE VALUES are stored (always builder_custom) and is managed by the compiler. 'cmsTables' is what content the module DISPLAYS, and is chosen by a human or by you.
|
||||
|
||||
The module id (its folder name under template/estandar/modulos/) CANNOT be renamed with this tool — there is no rename option at all. Only the fields above change; everything else in builder.json is preserved.
|
||||
|
||||
At least one of label, description, onlyAdminModule or MJMLModule is required. Fields you omit are left untouched.
|
||||
At least one of label, description, onlyAdminModule, MJMLModule or cmsTables is required. Fields you omit are left untouched. Passing cmsTables replaces the whole list, so include the tables you want to keep; pass [] to clear it.
|
||||
|
||||
Not applicable to the generated layout modules (custom-header, custom-footer, custom-header-twig, custom-footer-twig): those are artifacts of the global layout and the request will be rejected — use set_layout_field for them.`,
|
||||
withAuthParams({
|
||||
@@ -31,11 +36,12 @@ Not applicable to the generated layout modules (custom-header, custom-footer, cu
|
||||
description: z.string().optional().describe("Short description shown to editors in the builder"),
|
||||
onlyAdminModule: z.boolean().optional().describe("If true, the module is only visible to admin users in the builder"),
|
||||
MJMLModule: z.boolean().optional().describe("If true, the module is treated as an email (MJML) module"),
|
||||
cmsTables: z.array(z.string()).optional().describe("CMS tables whose records this module displays, e.g. [\"noticias\"]. Replaces the whole list; [] clears it. Only real tables of the project — they become direct links to the CMS."),
|
||||
}),
|
||||
{ readOnlyHint: false, destructiveHint: false },
|
||||
withAuth(async ({ module, label, description, onlyAdminModule, MJMLModule }, _extra) => {
|
||||
withAuth(async ({ module, label, description, onlyAdminModule, MJMLModule, cmsTables }, _extra) => {
|
||||
try {
|
||||
const provided = { label, description, onlyAdminModule, MJMLModule };
|
||||
const provided = { label, description, onlyAdminModule, MJMLModule, cmsTables };
|
||||
|
||||
// Validacion temprana: sin ninguna clave editable no tiene
|
||||
// sentido llamar al endpoint. Ojo con los booleanos false —
|
||||
|
||||
Reference in New Issue
Block a user