Ámbitos: quién ve qué

La misma aplicación, la misma versión y la misma base de datos, pero cada instalación —y si hace falta cada usuario— con sus formularios, su menú y sus informes. Eso son los ámbitos.

Lo que se configura por ámbito son hoy tres cosas, y las tres funcionan igual:

Las tres tablas llevan los mismos tres campos en su clave primaria, detrás de lo que identifica el objeto (COD_FORM, COD_MENU o COD_PROC):

Los campos que no aplican no se dejan en blanco: llevan el comodín *. Forman parte de la clave primaria, y una clave con un hueco vacío no se puede guardar. La aplicación los rellena sola cuando se crea la definición desde la pantalla de listado.

<note>Solo hay tres tipos de ámbito para cinco niveles de precedencia, porque dos pares comparten fila: una definición US vale para el usuario y para quien herede de él, y una CI vale para la clave de instalación y para la del grupo. Lo que cambia es contra qué valor casa COD_AMBITO, no cómo se guarda la fila.</note>

Cuando la aplicación necesita un layout, un menú o un informe, el procedimiento PWA_GET_* busca en este orden y se queda con el primero que exista:

Las claves de instalación tienen tres caracteres y las de grupo cuatro, así que nunca se confunden aunque compartan campo. El censo de instalaciones, con sus claves, está en Z_LICENCIAS, y la clave de la empresa en la que se trabaja sale de EMPRESA.

El mismo código de usuario existe en varias empresas —hay un JUANMA en cada una— y los scripts de mantenimiento se aplican a todas. Sin la clave de instalación, la definición del usuario de un cliente le caería encima al usuario homónimo de otro. Por eso, en las filas US, CLAVE_INSTALACION es obligatoria y la aplicación no deja crearlas sin ella.

<note important>Cada definición describe el objeto entero, no un parche sobre el general.</note>

Una instalación con su propio layout de albarán tiene todo el layout del albarán; una con su propio menú tiene todo el menú. La consecuencia:

• lo que se añade al general no llega a quien tiene lo suyo. Una pestaña nueva en el formulario general de cliente no la verá la instalación que se hizo el suyo hace seis meses;
• y por eso conviene tener pocos ámbitos propios, y crearlos copiando el general para partir de lo mismo.

La pantalla de menús trae para esto la opción Comparar con el general, que dice qué opciones tiene el general y a este ámbito le faltan. Es lo primero que hay que mirar cuando alguien dice «a mí no me sale eso que habéis puesto».

Desde la aplicación, en el listado correspondiente —Formularios, Menús o Diseños de informe— con el botón de nuevo registro. Se piden solo el código del objeto y el ámbito; los comodines los pone la aplicación:

1. COD_FORM / COD_MENU / COD_PROC: qué pantalla, qué menú o qué consulta.
2. TIPO_AMBITO: US, CI o G.
3. COD_AMBITO: el usuario o la clave. En la general se deja vacío: se guarda el comodín.
4. CLAVE_INSTALACION: solo si el tipo es US.

La aplicación comprueba lo que no puede salir bien y lo dice con estas mismas palabras:

• «El tipo de ámbito debe ser US, CI o G.»
• «Los ámbitos distintos del general necesitan el usuario o la clave de instalación.»
• «Las definiciones de usuario necesitan la clave de instalación: el mismo código de usuario existe en varias empresas.»

Recién creada, la definición está vacía: hay que pegarle el texto del general (o el de otra instalación parecida) y quitarle lo que no aplique. En los menús ese paso es una sola opción: Copiar a otro ámbito, desde la definición que sirve de origen.

La barra de título de las pantallas de edición lo dice: «Formulario albaran-venta-edit · Usuario JUANMA (026)», «· Clave de instalación 026» o «· General». Es la manera rápida de comprobar que se está tocando la definición que se cree.

Los ámbitos viven en la base de datos de cada cliente, así que un cambio hecho aquí no viaja solo. Las pantallas de formularios y de menús traen:

• Copiar script de actualización: deja en el portapapeles el UPDATE OR INSERT de esta definición.
• Descargar script (.sql): lo mismo en un archivo.

Ese script es idempotente —se puede ejecutar las veces que haga falta— y es lo que se incorpora a la base del cliente por la vía de siempre. Las definiciones generales están además versionadas en el repositorio (db/pwa_forms_layouts.sql, db/pwa_menus_datos.sql), que es de donde salen para todos los clientes; las de instalación o de usuario, al ser de uno solo, no se versionan ahí.

• Empezar siempre por el general. Si algo tiene que verlo todo el mundo, va al general; un ámbito propio es la excepción, no el punto de partida.
• Preferir CI a US. Lo que necesita un usuario suele necesitarlo su puesto, no su persona; y un ámbito de usuario es uno que nadie recuerda que existe cuando algo no sale.
• Usar el grupo cuando varias instalaciones del mismo cliente comparten manera de trabajar: una fila en vez de cinco.
• No dejar definiciones vacías. Una fila creada y sin texto es una definición que gana al general y no enseña nada; si se crea por error, se borra.
• Al añadir algo al general, repasar quién tiene lo suyo, con la comparación de menús o mirando las filas de esa pantalla en PWA_FORMS.