Access - Usar String publica UsuarioActivo para rellenar un formulario

Buenas noches a todos,

Lo primero, como es mi primer post, dar las gracias a todos por hacer que los novatos podamos aprender con vosotros. Llevo tiempo leyendo y hasta hoy he conseguido avanzar mucho en mi base de datos con la información publicada, sin embargo llevo dos días probando cosas he intentando implementar esto, pero no lo consigo, me explico:

Tengo una base de datos de proyectos, donde genero nuevos proyectos y ficho horas de trabajo sobre dichos proyectos. He añadido un control de entrada, login y pass, así como privilegios según el usuario.

En el formulario menu principal recojo el nombre de usuario y lo muestro en un campo de texto.


Pero ahora quería ir un paso más allá y por ejemplo usar esa string declarado en un módulo.

Public LogedUser As String

En el formulario fichajes, hasta ahora tenía un campo lista donde seleccionábamos de la tabla "empleados" el "usuario" que iba a fichar para generar un nuevo registro, pero me gustaría eliminar esta lista para que este campo no sea seleccionable, que dependa del login automáticamente.

He encontrado este post, donde se habla de este tema y he consultado los vídeos que indican, pero no me queda claro como declararlo...

https://www.lawebdelprogramador.com/foros/Access/1609432-Agregar-usuario-al-guardar-registro.html

He probado mil cosas, con Dlookup, aplicando el atributo LogedUser para intentar cogerlo, pero no lo consigo.


¿Podéis ayudarme?

Gracias de antemano,

Un saludo

Hola

Por lo que entiendo de tu codigo estas tratando de pasar al formulario Menu Principal el LogedUser

Para recoger ese valor debes usar la propiedad OpenArgs



Saludos

Hola,

Gracias por tu respuesta y perdona pero me cuesta un poco. Me dices de "recoger el valor" con OpenArgs y como me suena a chino he buscado un poco más y la verdad aquí se explica bastante bien, pero no acabo de entenderlo.

https://support.office.com/es-es/article/openargs-propiedad-c8616938-cd58-4b1a-84cf-3d043f59e13b

Lo primero, intento explicar mejor lo que quiero hacer:

Un usuario entra a la base con Usuario y Contraseña, al aceptar el login, necesito guardar su nombre para usarlo después, se supone que lo guardo aqui: (Public LogedUser As String 'Guardado en el módulo público para que esté siempre accesible'.

Ahora, ese usuario entra a un formulario donde debe fichar con los siguientes campos:

id_fichaje - Autonumeración
id_proyecto - (Selecciona un proyecto del cuadro lista) - Texto corto
id_tarea - (Selecciona una tarea del cuadro lista) - Texto corto
id_empleado - (Selecciona un usuario del cuadro lista) - Texto corto
horas - (Escribe un número de horas para fichar a esa tarea y proyecto especifico) - Número Grande

Lo que intento es que no tenga que seleccionar al usuario de una lista desplegable ni escribirlo, necesito "Almacenar" el nombre "Usuario" que valido en el formulario de acceso "Login", verificar que se encuentra en la tabla Empleados y que cuando introduzca los siguientes datos...

id_fichaje - Autonumeración
id_proyecto - (Selecciona un proyecto del cuadro lista) - Texto corto
id_tarea - (Selecciona una tarea del cuadro lista) - Texto corto
horas - (Escribe un número de horas para fichar a esa tarea y proyecto especifico) - Número Grande

... se rellene automáticamente el:

id_empleado - (Selecciona un usuario del cuadro lista) - Texto corto

¿Me explico?

Analizando un poco más tu respuesta... en el formulario Fichajes: (Tengo la misma etiqueta que en el menu principal, lbl_UsuarioActivo):


Mmm, vale lo he probado y me reporta Error (94), uso no valido de Null. Todo el código son las 3 lineas... me he encontrado el siguiente post pero hoy no me da tiempo a probar todas las cosas que ponen ahí.

https://rstopup.com/openargs-es-nulo-error.html

Si consigo que OpenArgs funcione... lo siguiente sería añadir una linea más de código para que coja el valor de OpenArgs y lo use para indicar al formulario que el id_empleado es el valor que esta guardando OpenArgs, ¿No?

id_empleado = Forms!Fichajes.OpenArgs 'Entiendo que aquí igualo el valor del id_empleado que necesito con el almacenado en
OpenArgs ¿Verdad?'

Si hay una variable PUBLICA que define al usuario activo …. ¿Qué inconveniente existe en que se utilice allá donde se necesite?

Lo único exigible (para que sea realmente publica esa variable) es que el modulo en que se ha declarado sea un modulo IN-dependiente (esto es, que el modulo no pertenezca a un informe o formulario)

En el caso de no disponer de un modulo cualquiera (de ese tipo) al que añadir esa definición, se crea uno aunque solo sirva (de momento) para eso, pues a los módulos independientes se les puede añadir código que permita ser compartido (por ejemplo entre un formulario y su asociado informe).

Lo que veo claro es como se utiliza actualmente esto:

Porque en algún momento hay que darle valor a esa variable y suele hacerse cuando el usuario se identifica por primera vez …. si se pretende utilizar en el momento en que el usuario se esta identificando (la variable esta sin inicializarse), se puede entran en un bucle muy muy raro.

Lo normal suele ser crear dos variables, una que define al usuario y otra para sus permisos, así se evitaría que -conocido el usuario- se precisase localizar de forma reiterativa sus permisos para aplicarlo ante cualquier evento.

Lo máximo que se podría necesitar es consultar esta variable en un entorno que no sea VBA (por ejemplo una macro o una consulta) ….

La solución es una función muy simple, supongamos que a la función se la denomine 'User_Actv' (podemos utilizar el mismo modulo en que se declaro la variable … ya va teniendo mas funcionalidad el modulo independiente)


Alla donde se necesite (incluso dentro de VBA pero seria redundante) … ejemplo: un filtro que se utilice en una consulta sobre el usuario activo podría ser algo similar a esto.

Respuesta muy sencilla y fácil de entender, que maravilla. Lo pruebo y os devuelvo el feedback.

Muchas gracias!

Ya estoy por aquí de nuevo, de momento en el módulo publico defino como bien dices la seguridad, aunque la tengo de momento desactivada y no la uso:

Option Compare Database
Option Explicit

Public vForm As String
Public UserLevel As Integer
Public LogedUser As String

Public Sub PassPermisos()

If vForm = "Permisos" Then
UserLevel = (IsNull(DLookup("[Seguridad]", "Empleados", "[usuario]" = 2 _
& " AND [pass] = '" & Form_Autorizar.pass & "'")))
End If

If vForm = "Usuarios" Then
UserLevel = (IsNull(DLookup("[Seguridad]", "Empleados", "[usuario]" = 2 _
& " AND [pass] = '" & Form_Autorizar.pass & "'")))
End If

End Sub

Public Function User_Actv() As String

User_Actv = LogedUser

End Function


Como ves, he pegado al final tu código. Pero como dices tu para algo tan fácil llevo cuatro horas haciendo pruebas... Entiendo que con eso declarado en el módulo, solo tendría que ir al formulario donde tengo el campo lista o cuadro combinado configurado así:

La tabla Empleados, tiene un campo usuario, donde uno de los registro es Javier.
El usuario que entra con Login se llama Javier.
Origen de control: usuario 'Entiendo que es el nombre del cuadro lista'
Origen de la fila: SELECT Empleados.usuario FROM Empleados;
Tabla/ Origen de la fila: Tabla/Consulta.

Con ese código me devuelve el listado de empleados, pero no encuentro un sitio donde establecer el filtro al cargar.
Cuando accedo al generador de expresiones para probar ahí, no aparece la clausula where...

He probado a poner lo que me decías, sin filtro de fecha en código y con filtro, pero nada.
Where Operario = Usuario()

¿Podríais ser un poco más específicos?

Añado el código para definir User_Actv = LogedUser y tengo un cuadro lista que resultado de los usuarios. ¿Donde aplico el filtro WHERE?

Se aprecia que estas en terreno con bruma ….

Por favor, no tomes los ejemplos al pie de la letra (máxime cuando se especifica que es un ejemplo y los datos son inventados).

Desconozco esa aplicación, pero lo que se suele aplicar es ….

Un formulario que es el primero que se debe de abrir y solo vale para 'reconocer al usuario y sus permisos'.

Si no se conoce a quien entra … debería prohibírsele el paso, a lo sumo se crearía un usuario genérico (incluso sin clave) que solo pudiese acceder a datos públicos sin mas derecho que el de verlos.

En ese formulario (que estéticamente y ergonómicamente depende del gusto del diseñador) se solicitaría:
.- el nombre (o se selecciona de un cuadro de lista … combo)
.- la contraseña
.- se valida la contraseña
.- opcionalmente se puede poner un contador que se incrementa con cada 'error' y al llegar a un determinado numero se le expulsa (incluso durante un tiempo) o directamente se le envía al administrador para que lo desbloquee.

Si conoce la contraseña (o acierta por eso del ensayo/error), se le asigna valor a las variables que definen al usuario activo (y de tener control de acceso por zonas) su nivel de acceso.

Dado que estas variables (en teoría) no se modificaran a lo largo de la sesión de trabajo, cuando se precisen …..

.- en VBA se utilizan libremente (ojo se leen pero NO se cambian o modifican)
.- si se necesitan fuera del entorno de VBA se crea una función para cada una de ellas (normalmente no se requieren ambas al tiempo, pero eso depende del programador y su peculiar diseño).

Puede ocurrir que la aplicación no este depurada y se produzca un error o mas dignos de ser solucionados, en esas ocasiones las variables (por publicas que sean y por simple seguridad también) se reinician.

Una función puede resolver el problema, es sencilla de crear:

Supongamos que se llama 'Verifica_User', antes de entrar en el apartado que exige seguridad se la llama (sin parámetros) y ella se encargaría de …
.- ¿Hay un usuario activo? … sale de forma trasparente y aquí no paso nada
.- ¿No lo hay? ( por la causa que fuere, incluso entrar por la puerta falsa): se le envía al formulario que solicita usuario ( por supuesto abierto en forma modal) y recuera el usuario activo (bien porque el error de la aplicación lo perdió, bien porque entro …. a por el queso)

El supuesto control:

Nota: Lo que depara abrir un formulario en modo dialogo, es que funciona de forma similar a un MSGBOX en el sentido de que mientras no le haga caso no deja continuar, detiene todos los procesos y al cerrar el formulario retorna al mismo punto que lo llamo (es como abrir un paréntesis en el tiempo).

Se da por supuesto que el formulario que solicita 'un usuario', se encarga de regenerar al usuario y sus permisos o lo pone de patitas en la calle
Por cierto a esta función que verifica la seguridad se la puede llamar desde cualquier ubicación, es mas, si se la llama desde la macro Autoexec (dado que no existiría un usuario todavía) la aplicación se iniciaría directamente en la solicitud de usuario

Todo esto que he expuesto (y lo anterior también) hay que tomarlo como simple referencia, tras el análisis y si funcionalmente es útil es cuando se adaptaría a la actual aplicación

-- en mi opinión ---

.- Modificar la aplicación para utilizar la idea tal cual … ==> es como mover el piano
.- Modificar la idea para adaptarla a la aplicación … ==> es como mover la banqueta

En cualquier caso (se mueva el piano o la banqueta) la cuestión es que se pueda dar el concierto de piano.