VJavascript ejemplo cargar plurales

En este artículo vamos a escribir un ejemplo de VJavascript que nos servirá para hacer algo super frecuente en v7: Cargar plurales, pero de forma genérica.

De esta forma podremos aprovechar el fichero javascript para cargar cualquier plural de cualquier tabla. Solo tendremos que crear el objeto proceso en v7 que nos índique cual es la ficha origen y cual la lista destino, y asociarlo con este fichero. Con la salvedad que la lista destino tiene que ser de un histórico de la ficha origen.

Fichero: CargarPlurales.js

// IN.- Ficha
// OUT.- Lista de historico (Cargar plurales en v7 )
// Este proceso puede recibir una ficha de cualquier tabla
// Retornará la lista del historico de esa ficha, que espere a la salida

// Recogemos la información de las dos tablas
var TableInfoEntrada = VRegisterIn.tableInfo();
var TableInfoOut = VRegisterListOut.tableInfo();

var ListOut = VRegisterList;

var NumHist = TableInfoEntrada.PluralCount();

// Suponemos que la numeración de los historicos es de 0 a n-1
for (h= 0; h < NumHist; h++ )
{

if ( TableInfoEntrada.pluralBoundedTableId( h ) == TableInfoOut.id() )
{
ListOut = VRegisterIn.loadPlurals( TableInfoEntrada.pluralId( h ) );

     h = NumHist;
}

}

// Retornamos la lista
VRegisterListOut.append( ListOut );

Controlando el acceso a los datos

Cuando se hacen aplicaciones para empresas, es normal que se requiera controlar los permisos de acceso al programa dependiendo del departamento. En este artículo os voy a explicar como lo hemos solucionado.

La aplicación está pensada para poder ser heredada y aplicarla a aplicaciones de cualquier fin, pudiendo incluso ser usada simultáneamente por más de una aplicación.

Distingo dos niveles de acceso:

1. Acceso a menús
2. nivel de autorización para crear/modificar datos

El control de accesos lo vamos a hacer a nivel de grupos de usuario, aprovechando la tabla que existe en vBase

Por lo que he creado cuatro tablas:

Acciones. En ella se dan de alta las acciones de menú que vamos a permitir activar o bloquear.

Tablas. Donde creamos las tablas que tendrán control de acceso a la información

Grupos – tablas. Donde definiremos los permisos de cada grupo de usuario con las tablas

Grupos – acciones. Para dar o quitar el acceso a las acciones por grupo.

Este es el esquema:

A nivel de acciones de menú no hay mas que dos posibilidades, o se permite o no se permite. Sin embargo en las tablas la cosa se puede complicar mucho (todo lo que queramos), desde controlar alta-modificación-baja, hasta controlar el acceso a cada campo (ver/modificar).

Manejando búsquedas

En el artículo anterior, explicabamos como hacer una búsqueda clásica de v6, mediante variables locales, aprovechando que la v7 recoge de forma automática las variables locales del formulario que tiene asociado, si estas existen también en la búsqueda.

Bien, ahora vamos a independizar el formulario de la tabla, y por tanto también de la búsqueda. Antes teníamos un formulario PAI_BUS (con origen la tabla PAI)  y una búsqueda PAI_BUS con el formulario anterior asociado.

Ahora copiamos el mismo formulario anterior, pero le quitamos la tabla, dejándolo como un formulario sin origen (BUS_VAR), como todos los datos que pedíamos eran de variables locales, funcionará sin errores. Copiamos también la búsqueda a PAI_BUS_VAR, quitándole el formulario asociado.

Ahora crearemos un proceso sin origen, y con destino lista de la tabla PAI.

En este proceso, primero debemos llamar al formulario sin origen, para pedir las variables, y a continuación pasarle las variables a la búsqueda y ejecutarla. Todo esto se consigue gracias a las instrucciones de manejo de objetos.

En el proceso crearemos las mismas variables locales que habíamos creado en el formulario y la búsqueda

Búsquedas con variables locales

Uno de los grandes cambios entre v6 y v7 son las variables. En la v6 casi todo pasaba por variables en memoria globales, y ahora en la v7 son las variables locales las grandes protagonistas.

Hasta el punto de no recomendar el uso de variables globales, salvo casos muy claros. Esta variables locales, han pasado a ser la forma natural y limpia de conectar valores entre procesos y objetos. Hoy vamos a explicar su uso con las búsquedas.

En las búsquedas se pueden definir variables locales, pero lo primero que nos preguntamos es ¿como les damos valor?.

Bien el caso más habitual es que la búsqueda tenga asociado un formulario, y resulta que todas las variables locales que tenga ese formulario, si coinciden en nombre con variables locales de la búsqueda su valor es enviado a ella. Por lo tanto lo único que tenemos que hacer es crear un formulario con variables locales del mismo nombre.

Vamos a desarrollar el ejemplo: Tenemos una tabla con los índices clásicos:

- ID.- Código

- NAME.- Alfabético

- WORDS.- Palabras

- PARTS.- Trozos

- MOD_TIM.- Fecha de modificación

y queremos hacer una búsqueda que no permita utilizar cualquiera de esos índices. En la búsqueda definimos las siguientes variables locales:

- ID.- Numérica, y nos permitirá buscar un código determinado

- NOM.- Alfabético, texto a buscar por los índices NAME, WORDS o PARTS.

- BUS_TIP.- Alfabético. Esta variable recibirá el tipo de búsqueda a realizar con el texto recibido en NOM. Vamos a permitir 4 tipos (A.- alfabético, P.- todas las palabras, G.- alguna palabra, T.- trozos)

- FCH_ON.- Booleana. Índica que queremos buscar por la fecha de modificación.

- FCH_DES.- Fecha. Fecha desde la que buscar

- FCH_HST.- Fecha. Fecha hasta

Almacén de objetos en v7

Los que venimos de velneo v6, sabemos lo que es el almacén de objetos y la metamorfosis al vuelo. Y nuestra pregunta es ¿Cómo puedo tener un almacén de objetos en v7?.

Precedentes

En v6, solía venir con la instalación de la herramienta un pequeño almacén de objetos. En esencia eran pequeños mapas (proyectos). Existían dos tipos:

1. Programas sencillos con una funcionalidad, que por un lado te servían de ejemplo a los no iniciados, y por otro podías incorporarlos a tus desarrollos.
2. Objetos visuales de una tabla tipo (VMAESTRO). Eran mapas (proyectos) que tenías todos los objetos visuales de una tabla, con un estilo concreto.

Mas tarde salieron las plantillas empresariales (vBase, vGestion,….). Este código abierto además de ayudar a aprender la programación en Velneo, a un nivel más avanzado que los programas que venían de serie con la herramienta, permitía partir de un código elaborado para crear aplicaciones.

Con estas aparecieron los complementos (vMail, vODBC,….). Código reutilzable en diversas soluciones.

Una vez que ya caminabas solo, y eras capaz de hacer tus propias aplicaciones. Por un lado utilizabas los complementos que te pudiesen interesar, y muchos eran interesantes, para incluirlos en tus aplicaciones. Pero sobre todo utilizabas el almacén de objetos para el desarrollo rápido de aplicaciones, aprovechando la metamorfosis al vuelo. Quien mas quien menos tenía sus módulos en el almacén, de lo cuales tiraba para crear nuevas tablas o nuevos objetos de tablas existentes.

La actualidad

En la v7 existen las Open Apps . Estas permiten cubrir por un lado el aprendizaje, y por otro (gracias a la herencia) la disposición de complementos reutilizables, con la gran diferencia de que el código está siempre separado; por lo que puedes veneficiarte de nuevas versiones sin tener que tocar nada de tu código, con solo actualizar el complemento lo tendrás operativo en todas las soluciones que lo use. Esto es una gran ventaja de la v7.

v7. Control del acceso a la base de datos

Precedentes

Debido a la ley de protección de datos, a la implantación de controles de calidad y seguridad, cada vez es mayor la necesidad de delimitar dentro de la empresa, quien accede a cada información, y quien puede modificar ciertos datos.

Sobre todo cuando el perfil de la empresa es medio / alto, estos requerimientos de seguridad se tornan exigencias.

Por lo tanto las aplicaciones deben facilitar el establecer múltiples niveles de acceso a la información. Y las bases de datos no pueden permitir que cualquier usuario pueda hacer consultas indiscriminadas de los datos.

Ejemplo

Una ficha de clientes contendrá información con distinto nivel de relevancia:

1. Datos personales. Que podrán ver cualquier persona de la empresa, pero modificar solo, por ejemplo el departamento comercial.
2. Condiciones de venta. Estos datos es muy posible que solo lo puedan ver el departamento comercial, pero solo modificarlo el director comercial.
3. Datos de riesgo. Estos podrían ser vistos por departamento comercial y administrativo, pero solo modificados por este último.

Al igual que este ejemplo se podrían exponer de cualquier información que se maneje (documentos de compra, venta, etc…)

Estos controles se pueden realizar dentro de la aplicación, pero si no se pueden implementar dentro de la propia base de datos, nos encontramos con que toda la seguridad analizada es saltada en el momento que se accede desde fuentes externas, mediante ODBC u otros medios (vDataClient en v7).

Hay que tener en cuenta, que cada vez es mas frecuente el acceder desde estos medios, y además por personal variado, para, por ejemplo, hacer mailings.

Necesidades

Por lo tanto se hace necesario, poder crear perfiles de acceso, tanto a nivel de tablas como de campos, de forma que un usuario a la hora de hacer un “SELECT” de una tabla solo vea los campos a los que tiene acceso, independientemente del medio por el que realiza la consulta.

Y sería bueno que estos controles se puediesen definir desde la propia solución (aplicación), por el usuario, sin tener que hacerlo desde el vServer.

Es decir, que se puedan crear dentro del programa tablas de perfiles de acceso y el usuario asignado como administrador pueda decidir las tablas/campos que puede ver cada usuario.

Funciones APIVEL para v7

Explicación de las mejoras que creo deberían tener las APIVEL de Velneo en la v7.

Estas nos permitirían crear exportaciones / importaciones a XML, así como tener mas flexibilidad para hacer generadores de listados o de exportaciones definidas por el cliente.

Unos posibles cambios serían:

Nueva función: Get identificador de campo por número

Sería como la función de la imagen, pero que devuelva el identificador.

Además en esta función, ¿en que idioma devolverá el nombre?.

Esto nos permitiría, por ejemplo, crear una exportación de la tabla a XML del tipo:

De forma que la etiqueta sea el Identificador, y no el nombre que cambiará según el idioma.

<registro><id>1 </id><name>NOMBRE</name></registro>

Modificar: Get numero de campo por identificador

Poder introducir el identificador, no como un desplegable, si no con una variable.

De esta forma podremos incorporar el fichero XML anterior, obteniendo el identificador del tag.

Condición activo/visible en v7

En algunos objetos (formulario, rejilla) tenemos las siguientes propiedades, que considero deberían extenderse a muchos otros:

Objetos visuales, donde deberían estar: Acciones, Imprescindible poder activar o desactivar acciones según el usuario, menús
Y sobre todo en:
Tablas y campos de tabla
¿Que nos permitiría tener estar propiedades en estos objetos?
Sobretodo nos daría un control en el acceso a los datos desde cualquier medio (vDataclient, ODBC,…), pudiendo el programador establecer los controles que considere oportunos de acceso dependiente del usuario que se identifique, esto no nos es posible hacerlo utilizando el estilo “privado”, puesto que nos condiciona el hacerlo a través del servidor, no de la aplicación, y nos limitan las condiciones, al no poder utilizar información del proyecto.
Al poder controlar estas condiciones mediante variables – fórmulas del programa, tenemos toda la flexibilidad para establecer los perfiles de acceso a la información.
Ejemplos:
Tabla, condición visible: Tabla de estadísticas de venta, nadie podría acceder a esta tabla (es como si no existiera para él) si su usuario, no cumple la condición de visibilidad, con lo que a través de ODBC no podría obtener esta información.
Campo, condición visible: impedir ver campos como riesgo, a ciertos usuarios.
Campo, condición activo: Poder configurar a nivel de datos que usuarios modifican que datos. A ciertos niveles de empresa, es muy común que datos de una misma tabla sean mantenidos por unos usuarios, y otros solo los puedan ver, pero nunca modificar (ejemplo condiciones de venta).

Con las propiedades a nivel de formulario, rejilla, podemos controlarlo, pero, tenemos un gran agujero de seguridad en el momento que acceden a los datos por otros medios, y es algo que será muy común. Por lo tanto estableciendo estas reglas a nivel de datos (parte izquierda de v6), la aplicación quedará robusta.
Por otra parte, con definirlos aquí, ya sería suficiente, sin tener que hacerlo es cada objeto visual.