Variables globales, panos de ejecucion y demás

Velneo
1

Hola a todos.

Ayer hice una consulta sobre las variables globales:

http://velneo.es/foros/topic/triggers-y-variables-locales/

Todavía estoy liado, a ver si alguien me puede orientar.

Tenía hecho un sistema de permisos, por el cual en los triggers de la bbdd comprobaba si el usuario actual tenía permiso para hacer alta , modificación o borrado en esa tabla.

Funcionaba perfectamente, ya que usaba la variable sysUserName para saber el nombre de usuario y consultaba una tabla de permisos.

Se me ha ocurrido hacer una tabla de usuarios y hacer un login personalizado, cuando entras te logas y se guarda en una variable global el usuario con el que has entrado.

Cambié la función que comprueba los permisos de sysUserName a dicha variable global en memoria.

Por supuesto no funciona, la variable en el server no tiene valor.

No veo cómo conseguir que el servidor sepa con qué usuario has entrado.

He probado ha hacer una tabla en memoria de sesiones y cargar en tercer plano un registro, pero una vez insertado ya no sé cómo recuperarlo.

He buscado alguna variable o función javascript del tipo sysUserName pero que me devuelva un id de sesión o algo para poder usar una tabla de sesiones con usuarios o algo, pero no he encontrado nada.

¿Cómo puedo enfocarlo para conseguirlo? ¿alguien se ha visto en situación similar?

Gracias por adelantado y perdonar el tostón.

Un saludo.

2

Hola Sergi, no se muy bien si entiendo lo que quieres, pero yo tengo un programa con una tabla de usuarios, y uso una variable global para que coga al entrar el usuario que está entrando.
Lo que hago es en el evento on_init del autoexec, guardo en una variable local quién entra, (al entrar les pido dato usuario), y luego cargo lista de usuarios, indice nombre, resolucion la variable local usuario que han introducido, si hay registros en la tabla qeu coincidan con ese usuario, selecciono ficha por posicion uno, leo ficha seleccionada y modifico variable global usuario con el código del usuario.
A mi me funciona, me coge valor la global nada más entrar.
No se si será lo que quieres, pero espero que te valga de algo

3

Buenas, puedes mirarte la vBase y verás como obtienen el id del usuario actual para guardarlo en la tabla.

4

Gracias a los 2.

Lydia, me parece que no me explicado bien.

Lo hago exáctamente como dices, guardo en una variable local en memoria el usuario que se ha logado y es eso lo que uso a lo largo de la aplicación.

El problema es que en la capa de datos, esa variable no tiene valor, si tengo un trigger que consulta esa variable, resulta que está vacía, porque la tiene el cliente y no el servidor.

Yo tengo tablas de permisos y triggers en cada tabla que comprueban si el usuario actual (guardado en la variable) tiene permiso para esa tabla, el problema es que como la variable está vacía, por supuesto no funciona.

Miraré con calma vBase como dice wikan para ver si veo algo inspirador.

5

Por experiencia del usuario, validar en un trigger los accesos, no es comodo, pues si ya accedi a los forms hice cosas y tal, para que a la hora de grabar me diga que no tengo permisos, no lo veo amigable para el usuario final, por eso se valida la entrada a la interfaz en la misma aplicacion. Es mas existen comandos de interfaz como “deshabilitar, ocultar accion” etc, que te permitiran una vez validados los permisos, tener los accesos correctos habilitados/deshabilitados segun correspondan. Si lo haces quizas para asegurarte que habiendo ingresado a la interfaz en ultimo momento se denega el acceso, entonces validalo nuevamente en el aceptar del formulario, pero son casos muy muy extranos, es como si le das la llave alguien y una vez que entro decides que no, que hacer. Creo que el tema va mas a como manejo la gestion de permisos desde la aplicacion. Cambiar Chip en velneo es muy importante.
Slds y espero haber interpretado tu duda bien sino, fue un comentario.

6

Hola Sergi:

Yo soy mas partidario de lo que dice Juan. En un evento ON-INIT del formulario que actúe como menú pondría funciones con llamadas a las distintas opciones de dicho menú (alta, baja, edita, buscar, etc). Miraría según el usuario y el módulo las activas o no.

Ten en cuenta que si lo pones en el proyecto de datos… el usuario no se entera de porqué no puede grabar o eliminar un registro

Un saludo

7

Hola.
Estoy de acuerdo en controlar los permisos del usuario como indican Juan y Vila.

Pero no poder recoger, desde un triger, datos del usuario o la sesión desde que se lanzo una actualización, no me parece buena idea.

Por ejemplo si queremos hacer una auditoría profunda, es una información básica. Supongamos que queremos guardar quien modificó un registro desde DataClient y que dato ha modificado.

No se si me expliqué. Desde luego es un problema que tendré que resolver.

Saludos.

Manuel Cabrera
Valdetecno Solutions

8

Es cierto en temas de auditoria, queda corto, aun mas si no podemos gestionar los usuarios fuera del vAdmin, una api de acceso a los usuarios se hace necesaria. Dado que la auditoria de velneo se basa en los usarios de vadmin y no los q nosotros ponemos en nuestra aplicacion. y aun mas en el tema de auditoria deberia ser automatico. En otras herramientas lo es.

9

Hola Sergi, aunque estoy totalmente deacuerdo con que la gestión de permisos se debe de realizar en la interfaz, tengo una idea para tu problema para que no pierdas el trabajo realizado.

En mi caso a casi todas mis tablas les añado 4 campos con el fin de dejar rastro de auditoria:

  • usuario_creación
  • usuario_creación
  • usuario_modificacion
  • fecha_modificacion

y el usuario lo lleno cuando abro el form que voy a usar, asi en tu caso cuando el registro se vaya a guardar solo tienes que mirar que el usuario indicado en la columna “usuario_creacion” tiene permisos, de resto no se me ocurre más

un Saludo,

10

Buenas también podéis hacer como hace vBase.

En vez de guardar el id del usuario por defecto en una variable lo que podéis hacer es llamar a una función que recoja el id del usuario buscando por el sysUserName.

Así te servirá tanto para procesos que se ejecuten en cualquier plano, contenidos inciales, triggers, etc.

Un saludo.

11

Hola, en primer lugar muchas gracias por vuestras respuestas.

La única forma es usando el user de velneo, teniendo tus tablas de usuarios “sincronizadas” con las de velneo, ya que lo único que puedes usar es sysUserName, no hay nada más a nuestro alcance que esté en los 2 planos.

Esto sería mucho más amigable si como dicen existiera un API para crear user de velneo.

Tampoco estaría mal una variable del sistema con el id de sesión compartida entre los 2 planos, así podrías hacerte una tabla de sesiones y controlar el user desde ahí.

Sobre lo de hacer todas las comprobaciones en la capa de interfaz, bueno, es cierto que hay que cambiar el chip con velneo, pero me cuesta, ya que mi máxima siempre ha sido acercar la lógica a los datos, y en velneo me está resultando imposible, cada vez que intento hacer cosas en la capa de datos me encuentro con escollos insalvables, y sí, sé que hay que cambiar el chip, pero en ningún lenguaje ni sistema había tenido estos problemas.

Hacer las comprobaciones en la capa de aplicación funciona, pero a mi parecer te lleva a tener que controlar las mismas cosas una y otra vez en distintas partes de la aplicación, cuando son conceptos indisociables de los datos, pienso que es antimodular y hace que poco código se pueda reutilizar realmente, ya que si los mismos datos (con la misma lógica asociada) se usan en diferentes contextos, forms, procesos etc…, toca repetir código en cada sitio.

Personalmente, por lo que llevo trabajado, no le veo ninguna utilidad a la máxima de velneo de separar el “qué hace” y “cómo lo hace”, y sí desventajas como las que comento, es justo lo contrario a la programación orientada a objetos.

Poco a poco le voy cogiendo el tanquilo pero seguro que no es la última vez que pregunto cosas porque me chocan muchos conceptos, jejejeje.

Muchas gracias a todos!