Los campos personalizados no son solo una función: cómo evaluar la flexibilidad del modelo de datos en una aplicación empresarial autoalojada
Los campos personalizados pueden hacer que una aplicación empresarial se adapte a su proceso o crear datos incoherentes, inaccesibles y difíciles de migrar. Utilice este marco basado en evidencias para comprobar el modelo de datos subyacente antes de comprometer registros operativos.
Los campos personalizados son una decisión de gobierno de datos, no una casilla de verificación
Que una página de producto diga «se admiten campos personalizados» responde muy poco. Un campo puede ser una caja de texto sin restricciones, una lista controlada de valores permitidos, un enlace a otro registro o una tabla repetible de registros relacionados. Estas opciones determinan si las personas pueden introducir datos coherentes, si la aplicación puede aplicar reglas de negocio y si la información sigue siendo útil en informes, exportaciones e integraciones.
Aborde la evaluación como una cuestión de ajuste del modelo de datos: ¿puede la aplicación representar las entidades, relaciones y reglas que utiliza realmente su operación? Una demostración rápida de configuración no es evidencia suficiente. Debe observar cómo se comporta la misma información personalizada cuando los registros se crean, editan, finalizan, buscan, exportan, importan y son accedidos por usuarios con distintos permisos.
Esto es especialmente importante en una aplicación autoalojada. El alojamiento le da control sobre dónde se ejecuta la carga de trabajo, pero no decide qué campos deben existir, quién puede acceder a ellos, cómo se interpreta un valor retirado o si una integración depende de una definición de campo. Esas son decisiones de gobierno que su organización debe tomar.
- No califique «campos personalizados: sí/no». Califique el ciclo de vida completo de un campo representativo.
- Diferencie la comodidad de la interfaz de usuario de las reglas de datos aplicadas y del control de acceso.
- Solicite evidencias en un entorno de pruebas utilizando sus propios registros realistas, no solo ejemplos del proveedor.
Empiece con un modelo de registro pequeño y real
Antes de abrir una instancia de prueba, anote un flujo de trabajo pequeño pero importante. Un registro de prestación de servicios, una cuenta de cliente, una solicitud de compra o una solicitud de cambio de proyecto suelen ser mejores puntos de partida que una lista abstracta de campos deseados. Incluya información compartida en todo el registro, información que pertenece a otra entidad e información que se repite.
Para cada elemento, decida qué significa estructuralmente. Una nota de texto libre es apropiada cuando se espera variación y no se requiere una agrupación fiable. Un valor controlado es más adecuado para un estado, categoría o motivo empresarial que debe filtrarse e incluirse en informes de forma coherente. Una relación es apropiada cuando el valor es realmente otra entidad mantenida, como un cliente, proveedor o responsable. Los elementos relacionados repetidos deben modelarse como filas repetidas cuando la aplicación admita ese patrón, en lugar de incluirlos en un campo de texto separado por comas.
La documentación de Frappe ilustra estas diferencias: Data es texto genérico; Select utiliza valores especificados en sus opciones; Link conecta con otro maestro; y Table representa una relación de tabla secundaria. La documentación de Child DocType también describe los registros secundarios como adjuntos a un registro principal y que conservan información del principal y de la secuencia de filas. Los nombres exactos difieren entre productos, pero la pregunta de evaluación es universal: ¿la estructura disponible coincide con el significado de su información? Consulte la documentación de Field Types de Frappe (https://docs.frappe.io/framework/user/en/basics/doctypes/fieldtypes) y la documentación de Child / Table DocType (https://docs.frappe.io/framework/user/en/basics/doctypes/child-doctype).
- Enumere las entidades principales: por ejemplo, cliente, proyecto, solicitud y persona.
- Identifique relaciones uno a uno, uno a muchos y muchos a uno.
- Marque todos los valores que deben estar controlados en vez de poder escribirse libremente.
- Identifique los datos repetitivos, como varios contactos, hitos, elementos o aprobaciones.
- Escriba las reglas de negocio que hacen que un registro esté completo o sea válido.
Verifique los tipos de campo y las reglas en la documentación oficial
Lea la documentación oficial de la aplicación sobre tipos de campo y configuración de reglas, y después verifique esas capacidades en la versión que planea utilizar. Vaya más allá de comprobar si se puede añadir un campo. Determine si puede ser obligatorio, recibir un valor predeterminado, validarse, limitarse a valores controlados y hacerse obligatorio o de solo lectura de manera condicional.
Por ejemplo, Frappe documenta ajustes independientes para valores predeterminados, mandatory_depends_on y read_only_depends_on. Esto permite, en principio, probar reglas como exigir un motivo cuando un registro alcanza un estado determinado o impedir más ediciones cuando se cumple una condición. No deduzca que otra aplicación tiene un comportamiento idéntico solo porque ambas ofrecen campos personalizados. Consulte la documentación de DocField de Frappe: https://docs.frappe.io/framework/user/en/basics/doctypes/docfield.
Pruebe deliberadamente entradas no válidas. ¿Puede un usuario dejar vacío un valor obligatorio? ¿Puede elegir una categoría no válida? ¿El valor predeterminado es visible y comprensible? ¿La aplicación aplica la regla al guardar, al importar y mediante la API cuando esas rutas sean pertinentes? Una regla que solo funciona en un formulario puede seguir dejando registros incoherentes en otros lugares.
- Cree un campo obligatorio e intente guardar sin completarlo.
- Añada un valor predeterminado y compruebe cuándo se aplica.
- Use un campo de valores controlados para una categoría de informes; intente introducir un valor no aprobado.
- Pruebe una condición que haga que un campo sea obligatorio o de solo lectura.
- Registre si cada regla se aplica en la interfaz, las importaciones y las API compatibles.
Pruebe la coherencia entre registros, equipos y flujos de trabajo
Una configuración utilizable debe aplicarse de forma coherente a la escala de su operación. Cree varios registros a través del flujo de trabajo normal, utilizando distintos usuarios o roles si es posible. Confirme que cada equipo ve las mismas definiciones de campo previstas, valores predeterminados y valores controlados allí donde la política exija coherencia.
Preste especial atención a los límites del flujo de trabajo. Un campo que puede editarse después de finalizar un documento puede cambiar su significado, estado, valor o efectos posteriores. La guía Allow on Submit de Frappe advierte explícitamente que los campos editables después del envío deben poder modificarse de forma segura y señala las dependencias en informes, flujos de trabajo, integraciones, permisos y lógica del lado del servidor. Aplique este principio incluso si evalúa otra plataforma. Consulte la documentación Allow on Submit de Frappe: https://docs.frappe.io/framework/doctypes/allow-on-submit.
Cuando un proceso requiera verdad histórica, decida qué valores deben permanecer fijos después de la aprobación o finalización y cuáles son seguros de modificar desde el punto de vista operativo. Registre el resultado como una regla, no como una expectativa informal.
- Cree registros equivalentes en más de un contexto de equipo.
- Compare disponibilidad de campos, valores y valores predeterminados.
- Mueva un registro por sus etapas significativas de estado o aprobación.
- Intente ediciones permitidas y prohibidas después de la finalización.
- Identifique los informes, integraciones y permisos afectados por cada campo editable.
Evalúe los permisos por separado para registros, campos, informes, exportaciones e importaciones
Las pruebas de permisos no deben detenerse en «¿puede este usuario abrir el registro?». Determine quién puede ver, crear, editar y eliminar registros; quién puede ver o editar campos sensibles; y quién puede cambiar la propia definición del campo. Pruebe también los informes, las exportaciones y las importaciones de forma independiente. Una persona que no puede cambiar un registro aún podría exportar información si esa capacidad se concede por separado.
Frappe documenta permisos distintos para leer, escribir, crear, eliminar, ver informes, exportar CSV/Excel y utilizar su herramienta Data Import Tool. También documenta niveles de permisos que pueden agrupar campos y aplicar distintos roles a cada nivel. Estos ejemplos muestran por qué una única comprobación amplia de permisos es inadecuada. Consulte la documentación Users and Permissions de Frappe: https://docs.frappe.io/framework/user/en/basics/users-and-permissions.
No trate los campos ocultos como seguros de forma predeterminada. Determine, mediante la documentación oficial del producto y una prueba con una cuenta restringida, si los campos sensibles se omiten de formularios, informes, exportaciones y métodos compatibles de acceso remoto, y si se deniegan los intentos directos de leerlos o escribirlos. Pruebe el comportamiento del producto y la versión específicos que está considerando, en lugar de asumir que un ajuste de visibilidad es un control de acceso.
- Pruebe un usuario estándar, un gerente, un usuario de informes y un administrador.
- Intente ver, editar y crear valores de campos sensibles con cada rol.
- Pruebe el acceso a informes y la exportación de datos como acciones independientes.
- Pruebe si un usuario de importación puede rellenar campos restringidos.
- Utilice una cuenta restringida para intentar lecturas y escrituras de datos sensibles mediante API compatibles.
- Documente quién puede modificar las definiciones de campo y las listas de valores controlados.
Compruebe si los datos personalizados funcionan donde se toman las decisiones
Un campo personalizado solo tiene valor operativo si las personas pueden utilizarlo más allá del formulario de registro. Pruébelo en vistas de lista, filtros, ordenación, vistas guardadas, paneles, informes y exportaciones. Verifique que los resultados sean comprensibles cuando un campo está vacío, cuando los valores cambian con el tiempo y cuando un registro tiene varias filas secundarias.
Frappe documenta capacidades de lista que incluyen filtros, ordenación y paginación, y documenta Query Reports con columnas y filtros configurables vinculados a un DocType de referencia para el control de acceso. Son capacidades útiles que conviene buscar, no una suposición de que todas las aplicaciones exponen los campos personalizados de las mismas formas. Consulte la documentación List de Frappe: https://docs.frappe.io/framework/user/en/api/list.
Utilice una pregunta de su rutina operativa semanal. Por ejemplo: «¿Qué solicitudes activas tienen un motivo de alto riesgo y ningún responsable asignado?». Si no puede responderla de manera fiable sin abrir registros manualmente o exportar y reparar una hoja de cálculo, el diseño de campo propuesto aún no ha demostrado su valor.
- Filtre registros por cada campo personalizado importante.
- Ordene por un campo de fecha, numérico o de valor controlado cuando sea pertinente.
- Cree o inspeccione un informe que contenga campos personalizados y datos de relaciones.
- Exporte un conjunto de registros representativo e inspeccione nombres de columnas, valores y campos vacíos.
- Compruebe si los permisos de informes y exportación se ajustan a su política de acceso.
Rastree los campos personalizados a través de API, importaciones y aplicaciones conectadas
Una integración puede convertir un campo bien diseñado en una dependencia frágil si su nombre, valores permitidos, permisos o comportamiento de actualización no están claros. Identifique todas las rutas por las que un registro representativo puede crearse o modificarse: la interfaz de la aplicación, las importaciones, una API compatible y cualquier flujo de trabajo conectado que pretenda utilizar.
La documentación REST de Frappe describe la selección de campos, el filtrado por condiciones, la ordenación y la paginación de registros. Esos comportamientos documentados ilustran una prueba eficaz: verifique que sus campos personalizados se devuelven cuando se solicitan y que se pueden filtrar cuando es necesario. Por separado, pruebe cualquier comportamiento de creación, actualización o eliminación que requiera su integración con la documentación oficial y la versión que planea usar. Consulte la documentación de REST API de Frappe: https://docs.frappe.io/framework/user/en/api/rest.
Las operaciones masivas merecen su propia prueba. La documentación de Data Import de ERPNext indica que las hojas cargadas se validan antes de la importación, que se presentan advertencias por fila o columna y deben resolverse antes de importar, y que las importaciones correctas se registran en un registro de importación. Tanto si la aplicación elegida funciona así como si no, determine si los errores se detectan antes de confirmar los datos empresariales y si el resultado es auditable. Consulte la documentación Data Import de ERPNext: https://docs.frappe.io/erpnext/data-import.
- Cree un registro representativo a través de cada ruta compatible requerida.
- Léalo de vuelta y compare cada valor personalizado con el origen.
- Actualice un campo permitido y confirme los efectos esperados en el flujo de trabajo.
- Intente una actualización no válida e inspeccione el error y el estado resultante del registro.
- Pruebe la selección de campos, el filtrado, la ordenación y la paginación en la API si las integraciones los necesitan.
- Ejecute una importación pequeña que contenga filas válidas y filas deliberadamente no válidas.
Evalúe la seguridad de los cambios de esquema antes de necesitarlos
Los campos evolucionan. Los equipos renombran categorías, sustituyen procesos y retiran valores. La pregunta esencial no es simplemente si un administrador puede realizar un cambio, sino qué ocurre después con los registros existentes, los informes, las integraciones y la interpretación histórica.
Mantenga un registro de cambios para cada campo relevante: propósito empresarial, responsable, tipo, valores permitidos, valor predeterminado, validación, política de acceso, dependencias y enfoque de retirada. Antes de aprobar un cambio, identifique qué informes guardados, importaciones, consumidores de API y flujos de trabajo hacen referencia a él. Pruebe el cambio en copias de registros representativos antes de aplicarlo de forma generalizada.
Los valores controlados requieren especial cuidado. La documentación ORM de Odoo describe una alternativa ondelete para opciones Selection ampliadas, que incluye establecer un valor como nulo, eliminar en cascada, establecer un valor predeterminado, asignar un reemplazo especificado o ejecutar procesamiento personalizado. Es un patrón útil para tomar decisiones: cuando se retira un valor, decida explícitamente cómo se tratarán los registros que contienen ese valor. Nunca permita que el significado histórico sea accidental. Consulte la documentación ORM API de Odoo: https://www.odoo.com/documentation/19.0/developer/reference/backend/orm.html.
- Cambie el nombre de un campo de prueba no crítico e inspeccione informes, exportaciones e integraciones.
- Intente un cambio de tipo de campo utilizando valores existentes representativos.
- Retire un valor controlado y verifique el tratamiento de los registros existentes.
- Documente un reemplazo aprobado, un valor nulo u otro enfoque de conservación para los valores retirados.
- Compruebe si los registros finalizados requieren un control de cambios más estricto.
- Conserve un registro de las decisiones de esquema y sus fechas de entrada en vigor.
Preguntas frecuentes
¿Cuál es la prueba más importante al evaluar campos personalizados?
Construya un modelo de registro realista y sígalo durante todo el ciclo de vida: introducción, validación, flujo de trabajo, permisos, búsqueda, informes, exportación, importación y cualquier integración de API necesaria. Un campo que solo funciona en un formulario aún no ha demostrado que sea útil operativamente.
¿Debería cada categoría personalizada ser un menú desplegable o un valor controlado?
No. Utilice valores controlados cuando se necesite coherencia para filtrado, informes, automatización o gobierno. Utilice texto libre cuando se espere variación significativa y no deba forzarse a una lista artificial. Si el valor es realmente otro objeto empresarial mantenido, pruebe una relación en lugar de un menú desplegable.
¿Por qué deberíamos probar el acceso por API a campos restringidos?
Ocultar un campo en una interfaz de usuario no es evidencia suficiente de que los datos subyacentes estén protegidos. Pruebe a un usuario restringido mediante todas las rutas de acceso compatibles que planee utilizar, incluidas API, informes, exportaciones e importaciones, para verificar que los controles de acceso se aplican.
¿Qué debemos preservar durante una migración?
Conserve identificadores de registro estables cuando la aplicación los utilice para actualizaciones, asigne las relaciones deliberadamente y pruebe por separado los adjuntos y las filas secundarias repetibles. La documentación de ERPNext, por ejemplo, indica que las actualizaciones utilizan la columna ID exportada y que eliminar una fila de tabla secundaria de un archivo de actualización se trata como una eliminación intencionada. Su aplicación de destino puede diferir, por lo que debe ensayar su comportamiento real. Consulte la documentación Data Import de ERPNext: https://docs.frappe.io/erpnext/data-import.
¿Cuándo es una aplicación configurable la elección equivocada?
Elija un sistema diseñado para un propósito específico o desarrollo dedicado cuando su proceso central dependa de reglas de dominio complejas, cálculos especializados, controles regulatorios excepcionalmente estrictos, gestión de relaciones de gran volumen o un modelo de datos que no pueda representarse y gobernarse limpiamente con las estructuras compatibles de la aplicación. La configuración debe reducir el riesgo operativo, no ocultar una incompatibilidad fundamental.
Fuentes y lecturas adicionales
- Field Types — Frappe Framework
- DocField — Frappe Framework
- Child / Table DocType — Frappe Framework
- Users and Permissions — Frappe Framework
- REST API — Frappe Framework
- List — Frappe Framework
- Query Report — Frappe Framework
- Data Import — ERPNext
- Allow on Submit — Frappe Framework
- ORM API — Odoo