Sabemos de los clásicos formularios de Alta, Modificación y Baja en las rejillas; ¿pero qué pasa si tenemos usuarios a los que solo queremos dar acceso a consultas? ¿Cómo manejan esto en sus sistemas? Obligatoriamente al dar doble click a un registro en una rejilla, nos toma uno de los 3 formularios antes mencionados. ¿Sería la única forma poner condiciones a los controles según el tipo de usuario logueado? Esto último nos llevaría a crear un sistema de usuarios y grupos de usuarios para algo que debería ser más práctico. Les agradecería sus consejos.
Yo he preferido desactivar el formulario de alta en las rejillas, y en su lugar he colocado un botón “Nuevo”. El botón puede tener una condición de activo relacionada con el grupo al que pertenece el usuario.
En la rejilla dejo activados los formularios de modificación y baja, pero están enlazadas a un mismo formulario, donde puedes ocultar el botón “Eliminar” con la condición de visible.
Considero que el doble-click en la parte en blanco de un formulario para crear un alta no es tan intuitivo y si el usuario no conoce esta función de las rejillas, entonces no le hará tanta falta.
Realmente debo usar un formulario sin tabla asociada para el alta de un nuevo registro. El botón nuevo ejecuta la acción “Disparar objeto” que abre este formulario. En este formulario almaceno los campos en variables y con el botón aceptar ejecuta un proceso que crea una nueva ficha en memoria , luego traslada las variables a los campos y finalmente hace el alta con la instrucción “Alta de ficha”.
Requiere un poco más de trabajo que un formulario con tabla asociada, pero me ha permitido más control. El formulario de edición/borrado si tiene una tabla asociada y se abre desde la rejilla.
Espero que esta alternativa sea de utilidad.
Saludos,
Creo que dar de alta una Ficha en un formulario de Velneo, usando solo variables locales, es una tarea inútil en la mayoría de los casos. Solo tienes que pensar en los campos punteros a maestro.
No veo ningún problema de usar un formulario nativo de Velneo para las Altas de Fichas, hasta que el usuario no pulse Aceptar, la Ficha no se guarda en disco.
En general y para muchos aspectos de nuestras aplicaciones, intentar hacer algo de manera distinta a como lo tiene automatizado Velneo, nos llevará la mayoría de las veces a un callejón sin salida.
Hola, estoy de acuerdo con Paco. No te salgas del “camino velneano”… Para darte una ayuda concreta te diría que puedes implementar el método que tiene vERP para asignar o desasignar permisos, lo puedes imitar; básicamente son flags que asignas a una tabla y estas a otra tabla de usuarios, afirmando o negando permisos entonces cuando el usuario abra X formulario, en el PRE-INI de ese formulario le colocas la validación, si no tiene asignado ese permiso o si tiene asignado un permiso negativo “salta” mensaje de advertencia y cierras formulario o dejas pasar sin decir nada.
Totalmente de acuerdo Paco, que lo mejor es usar lo que Velneo automatiza de forma nativa.
Esto de las altas de ficha con variables lo he retomado de un caso de aplicación para un dispositivo móvil, donde se usa un formato tipo asistente (wizard), donde en cada pantalla se ingresa un solo campo a la vez, y con un botón “Siguiente” vas avanzando. Al final aparece el botón “Guardar”. Es cierto que requiere más programación velneo (aunque tampoco necesito usar javascript), pero para el usuario es una interfaz más manejable que seleccionar opciones en una caja de texto con vista de datos, o una caja de fecha con o sin calendario, a menos que le agregues CSS para aumentar su tamaño. Para móviles también reconozco que lo mejor será utilizar QML, pero todavía no he logrado programar en QML.
Todavía no he encontrado otra forma de implementar un wizard en un formulario con tabla asociada, que sería lo ideal.
Gracias por tus comentarios.