Manual de AGF App: Administración
Este capítulo explica las funciones del perfil administrador: datos maestros, configuración del sistema, usuarios, grupos, permisos y acciones de control. La administración es la base que permite que AGF App funcione de forma ordenada, segura y segregada por departamento. Los nombres de botones pueden variar ligeramente según la versión de AGF App.
1. Función del administrador
El administrador mantiene la configuración común que permite el funcionamiento de AGF App como plataforma operativa integrada. Sus principales áreas de responsabilidad son:
Base de datos y datos maestros
Valores reutilizables: tipos, estados, ambientes, clientes, conceptos de fichaje.
Configuración del sistema
Parámetros globales: logo, horarios, usuarios especiales, conceptos.
Usuarios y grupos
Creación, edición, activación/desactivación y organización por roles.
Permisos: asignación y gestión
Concesión individual, por grupo y uso del Explorador de permisos.
Explorador de permisos
Punto central para revisar, gestionar y auditar permisos en toda la plataforma.
Los cambios de administración pueden afectar a varios módulos y usuarios. Después de guardar cualquier cambio, debe comprobarse que el resultado es el esperado. Los cambios en datos maestros o permisos pueden alterar la visibilidad de información para usuarios finales.
2. Base de datos y datos maestros
2.1. Contenido y estructura
El apartado Base de datos concentra todos los datos maestros utilizados por AGF App. Estos valores son reutilizables y condicionan cómo funciona la aplicación.
Categorías principales:
- Proyectos: Tipos y estados de proyecto.
- Tareas: Tipos y estados de tarea.
- Informes: Tipos y asuntos de informe.
- Documentos: Tipos, estados, grupos y plantillas de documentos.
- Comentarios: Tipos de comentario.
- Fichajes: Conceptos o categorías de imputación de tiempo.
- Usuarios y grupos: Definición de roles y asociaciones.
- Clientes y proveedores: Base de contactos externos.
- Paquetes de contratación: Cuando correspondan (para GEM, jefatura de obra).
- Entidades transversales: Elementos, referencias, códigos.
Estos datos maestros condicionan:
- Los formularios que ven los usuarios.
- Los filtros disponibles.
- Las reglas de visibilidad de la información.
- El funcionamiento de lógicas internas.
Un dato maestro bien definido ahorra trabajo futuro. Un dato mal estructurado o duplicado puede generar confusión y errores de filtrado.
2.2. Organización por origen y ambiente
Origen: Cada registro en la AGF App (tarea, informe, comentario) pertenece a un origen o área funcional:
- COM: Comercial.
- GP: Gestión de Proyectos.
- ING: Ingeniería.
- GEM: Gestión de Ejecución Material (campo, contratas, inventario).
- JO: Jefatura de Obra (desarrollo futuro).
El origen controla dónde aparece la información. Un comentario con origen COM no aparecerá en el listado de ING.
Ambiente: Dentro de cada origen, los usuarios se posicionan en un ambiente o fase del proyecto. Los ambientes pueden variar por área:
| Área | Ambientes típicos |
|---|---|
| Comercial | Contacto, Oferta, Propuesta, Seguimiento, Post-venta |
| Ingeniería | Ingeniería Básica, Proyecto Técnico, Ingeniería de Detalle, Ingeniería de Ejecución, Puesta en marcha |
| GP | Planificación, Ejecución, Puesta en operación, Cierre |
| GEM | Montaje en taller, Obra civil, Instalación eléctrica, Montaje en campo, Operación |
Antes de crear un dato maestro (tipo de tarea, tipo de documento), definir claramente a qué área y ambiente corresponde. Esto facilita que después aparezca en los lugares correctos.
2.3. Crear o editar un dato maestro
Procedimiento:
- Acceder a Base de datos en el menú de administración.
- Abrir la categoría correspondiente (Tipos de tarea, Ambientes, Tipos de documento, etc.).
- Crear un registro nuevo o editar uno existente.
- Completar:
- Nombre: claro, único, sin duplicados similares.
- Color o etiqueta visual: para identificación rápida (no concede permisos).
- Descripción (si aplica): qué representa este valor.
- Origen (si aplica): a qué área funcional pertenece (COM, GP, ING, GEM, etc.).
- Usuarios permitidos / Grupos permitidos (si aplica): quién puede verlo o usarlo.
- Guardar.
- Verificar que el valor aparece donde debe utilizarse en la aplicación.
2.4. Restricciones de visibilidad mediante permisos
Algunos datos maestros permiten indicar usuarios permitidos y grupos permitidos. Esto restringe quién puede ver o usar ese valor.
Ejemplo: Tipo de proyecto restringido
Si se crea un tipo de proyecto "Desarrollo experimental" y se restringe al grupo "Dirección", solo los usuarios pertenecientes a ese grupo podrán:
- Ver proyectos de ese tipo.
- Crear proyectos de ese tipo.
- Acceder a información vinculada a esos proyectos.
Ejemplo: Tipo de documento restringido
Si se restringe el tipo de documento "Contrato confidencial" al grupo "Comercial + Dirección", solo esos usuarios podrán crear o consultar documentos de ese tipo.
Crítico: Antes de limitar un dato maestro, comprobar que TODOS los usuarios que deban trabajar con él tienen acceso. Si se restringe mal, se puede bloquear trabajo operativo.
2.5. Control de acceso en informes
Los informes aplican dos controles independientes de acceso:
- Permiso sobre el tipo de informe (p. ej., "Informe técnico").
- Permiso sobre el asunto del informe (p. ej., "Especificaciones de equipos").
El usuario debe tener permiso en AMBOS niveles para acceder al informe.
Si un usuario tiene permiso para "Informe técnico" pero no para "Especificaciones de equipos", no podrá ver informes técnicos sobre ese asunto.
Esta doble restricción permite control granular de información sensible. Ejemplo: Permitir que todos vean "Informes técnicos", pero solo ciertos usuarios vean "Informes económicos".
2.6. Criterios de mantenimiento de datos maestros
- Reutilizar valores existentes cuando representen el mismo concepto. No crear duplicados.
- Evitar nombres duplicados o demasiado similares. Ejemplo: No tener "Oferta v1" y "Oferta 1.0".
- Revisar permisos antes de guardar un tipo restringido.
- No eliminar ni renombrar un valor en uso sin comprobar impacto en:
- Proyectos activos.
- Tareas históricas.
- Filtros guardados.
- Informes.
- Documentos.
- Documentar cambios importantes en datos maestros para comunicar a usuarios.
3. Configuración del sistema
La sección Configuración del sistema solo está disponible para administradores. Permite modificar parámetros globales que afectan a toda la aplicación.
3.1. Parámetros configurables
Entre otras opciones, pueden incluir:
- Logo y datos corporativos: Identidad visual de AGF.
- Horarios de cierre automático de fichajes: Controla cuándo se detienen automáticamente los fichajes abiertos.
- Usuarios especiales: Placeholders utilizados por lógicas internas (p. ej., "Sala de Diseño", "Taller", "Reuniones").
- Conceptos de fichaje: Categorías disponibles para imputar tiempo.
- Parámetros de jornada: Horarios laborales (futuro: configurables por usuario).
- Integraciones: APIs, conexiones a sistemas externos.
3.2. Cierre automático de fichajes
La AGF App realiza cierres automáticos de fichajes en horarios configurados. Actualmente se ejecutan a las 15:00 (mediodía/tarde).
Propósito: Evitar que queden fichajes abiertos indefinidamente, lo que distorsionaría las métricas de tiempo.
Comportamiento:
- A la hora configurada, el sistema detiene automáticamente cualquier fichaje que siga abierto.
- El tiempo acumulado hasta ese momento se imputa a la tarea.
- El usuario ve que su fichaje se ha cerrado automáticamente (no es un error).
Para revisar o modificar el horario:
- Acceder a Configuración del sistema.
- Localizar la sección de Fichajes o Cierre automático.
- Ajustar el horario acordado.
- Guardar el cambio.
- Comunicar a los usuarios afectados el nuevo horario.
Si un fichaje se detiene a la hora configurada, probablemente se debe al cierre automático y no a un error del usuario. Es normal.
Un horario mal configurado puede interrumpir trabajo. Coordinar cambios con el equipo antes de ejecutarlos.
3.3. Usuarios especiales y placeholders
Algunos módulos (diseño, taller, reuniones) utilizan usuarios placeholders para enrutar tareas automáticamente. Ejemplo:
- Tareas de diseño pueden asignarse automáticamente a usuario "Sala de Diseño".
- Tareas de taller pueden asignarse a usuario "Taller".
Antes de modificar o eliminar un usuario especial, confirmar que la lógica asociada sigue siendo necesaria. Cambios mal hechos pueden afectar el enrutamiento de tareas.
4. Gestión de usuarios
4.1. Estructura del usuario: datos fundamentales
Cada usuario en AGF App debe tener definido:
| Campo | Descripción | Obligatorio |
|---|---|---|
| Nombre | Nombre de pila. | ✓ |
| Apellido 1 | Primer apellido. | ✓ |
| Apellido 2 | Segundo apellido (si aplica). | |
| Alias | Inicial del nombre + iniciales de apellidos, en mayúsculas. Ej: Javier Cuenca Torres → JCT | ✓ |
| Correo | Correo corporativo. Fundamental para recibir credenciales. | ✓ |
| Teléfono | Teléfono de contacto. | |
| Fotografía | Imagen de perfil (opcional pero recomendada). | |
| Estado | Activo / Inactivo. Los usuarios inactivos no pueden acceder. | ✓ |
| Administrador | Sí / No. Solo asignar cuando sea necesario. | ✓ |
| Grupos | Roles a los que pertenece el usuario. | ✓ |
| Contraseña | Generada por el sistema. Se envía por correo. | ✓ |
El alias es importante. Se usa para identificar rápidamente al usuario en comentarios, asignaciones y logs. Seguir el formato: inicial del nombre + iniciales de apellidos.
4.2. Alta de usuario: procedimiento recomendado
Paso a paso:
- Crear ficha: Acceder a Usuarios → Nuevo usuario.
- Datos básicos:
- Nombre, apellidos.
- Calcular alias automáticamente (inicial + iniciales apellidos).
- Correo corporativo.
- Teléfono.
- Estado: Marcar como Activo.
- Fotografía: Subir una foto (recomendado para reconocimiento visual).
- Condición de administrador: Marcar SOLO si el usuario debe gestionar la plataforma.
aviso
Solo los administradores deben crear usuarios, configurar permisos, editar datos maestros.
- Grupos: Asignar los grupos que correspondan:
- Ingeniería.
- Comercial.
- Control de calidad.
- Dirección.
- Etc.
- Permisos individuales: Asignar solo si hay excepciones. Preferir usar grupos.
- Contraseña: Generar y confirmar.
- Guardar.
- Verificación: El usuario recibirá un correo con credenciales. Comprobar que accede correctamente.
Si el correo es incorrecto, el usuario no recibirá credenciales y no podrá acceder. Verificar antes de guardar.
4.3. Edición de usuario
Se puede modificar:
- Datos de contacto (correo, teléfono).
- Fotografía.
- Grupos asignados.
- Permisos.
- Estado (activo/inactivo).
No editar directamente la contraseña. Si el usuario la olvida, usar "Restablecer contraseña".
4.4. Restablecer contraseña
Cuando un usuario olvida su contraseña o la necesita cambiar:
- Buscar al usuario en Usuarios.
- Pulsar Restablecer contraseña (ícono de llave naranja).
- Confirmar la operación.
- El sistema genera una contraseña temporal y la envía por correo.
Verificar que el correo en la ficha es correcto ANTES de resetear.
4.5. Desactivación vs. Eliminación de usuario
Desactivar usuario (recomendado):
- El usuario ya no puede acceder a AGF App.
- Se conservan todos sus registros (tareas, fichajes, comentarios).
- Permite auditoría y trazabilidad históricas.
- Procedimiento: Cambiar estado a Inactivo.
Eliminar usuario (uso excepcional):
- Se borra el usuario y toda su información asociada.
- Pérdida irreversible de históricos.
CRÍTICO: Solo si no hay datos asociados o han sido previamente migrados. Consultar antes.
Antes de eliminar un usuario, comprobar:
- ¿Tiene tareas asignadas? (Reasignarlas antes)
- ¿Tiene fichajes registrados? (¿Necesito ese histórico?)
- ¿Tiene comentarios? (¿Son relevantes para auditoría?)
- ¿Es el responsable de documentos? (¿Cambiar responsable?)
- Si hay duda, desactivar en lugar de eliminar.
5. Grupos y permisos
5.1. Concepto de grupo
Un grupo es un conjunto de usuarios con un rol o función común. Los grupos simplifican la gestión de permisos.
Ejemplos de grupos:
| Grupo | Función | Permisos típicos |
|---|---|---|
| Dirección | Acceso total, supervisión. | Todos, eliminar, supervisar. |
| Administración | Mantener plataforma, usuarios, datos. | Crear usuarios, editar permisos, datos maestros. |
| Ingeniería | Diseño, cálculos, documentos técnicos. | Crear/editar tareas ING, ver documentos técnicos. |
| Comercial | Ofertas, clientes, negociación. | Crear/editar tareas COM, documentos comerciales. |
| Gestión de Proyectos | Coordinación con cliente. | Ver todo, comentar, crear tareas GP. |
| GEM | Campo, contratas, inventario. | Tareas GEM, entradas de campo, inventario. |
| Control de Calidad | Supervisión de calidad. | Ver documentos, validar, comentar. |
5.2. Asignación de permisos: individual vs. grupo
Opción A: Permisos por grupo (recomendado)
- Un usuario pertenece a uno o varios grupos.
- Cada grupo tiene permisos definidos.
- Cambiar un permiso de grupo afecta a todos los usuarios del grupo.
- Ventaja: Mantenimiento centralizado, consistencia.
- Desventaja: Menos flexible para casos puntuales.
Opción B: Permisos individuales (excepción)
- Asignar permiso directamente a un usuario.
- Solo aplica a ese usuario.
- Ventaja: Máxima flexibilidad.
- Desventaja: Difícil de mantener, propenso a inconsistencias, requiere auditoría constante.
Regla de oro: Usar grupos para funciones comunes. Permisos individuales solo para excepciones documentadas.
5.3. Permisos efectivos: lógica de merge
AGF App combina permisos de dos fuentes:
- Permisos asignados directamente al usuario.
- Permisos heredados de todos los grupos a los que pertenece.
La lógica es acumulativa (unión): Si el usuario O cualquiera de sus grupos tiene un permiso, el usuario lo tiene.
Ejemplo:
- Usuario "Juan" tiene permiso individual: "Eliminar tareas".
- Usuario "Juan" pertenece al grupo "Ingeniería" (que NO tiene permiso de eliminar).
- Resultado: Juan SÍ puede eliminar tareas (porque lo tiene como individual).
Consecuencia crítica:
- Retirar un permiso de la ficha individual no garantiza revocarlo si el usuario lo mantiene a través de un grupo.
- Solución: Usar el Explorador de permisos para ver el estado real.
Un permiso otorgado puede estar cubierto por múltiples fuentes (individual + grupo A + grupo B). Para revocarlo completamente, hay que quitarlo de TODAS las fuentes.
5.4. Explorador de permisos: herramienta central
El Explorador de permisos es el punto único de verdad para gestionar permisos. Permite ver:
- Qué usuarios tienen un permiso.
- Qué grupos tienen un permiso.
- Las fuentes (individual, grupo A, grupo B, etc.).
Procedimiento para gestionar un permiso:
- Acceder a Base de datos → Explorador de permisos.
- Buscar el permiso deseado (p. ej., "Eliminar tareas", "Crear documentos", "Supervisar").
- Revisar qué usuarios y grupos lo tienen asignado actualmente.
- Añadir: Cliquear en usuario/grupo y marcar el permiso.
- Retirar: Desmarcar el permiso en usuario/grupo.
- Guardar cambios.
- Verificar el resultado volviendo a ver el permiso para confirmar que está como deseado.
El Explorador de permisos es especialmente valioso para revocar permisos. Un permiso puede estar concedido por:
- Asignación individual.
- Grupo A.
- Grupo B.
- Grupo C.
Si solo lo quitas de la asignación individual, el usuario sigue teniéndolo por los grupos. El Explorador lo muestra todo junto.
5.5. Matriz de permisos recomendada
Como referencia, una estructura típica podría ser:
| Permiso | Dirección | Admin | Ingeniería | Comercial | GP | GEM | Control QA |
|---|---|---|---|---|---|---|---|
| Ver todo | ✓ | ✓ | (ING) | (COM) | ✓ | (GEM) | ✓ |
| Crear proyectos | ✓ | ✓ | |||||
| Crear tareas (su área) | ✓ | ✓ | ✓ | ✓ | ✓ | ||
| Eliminar tareas | ✓ | ✓ | |||||
| Editar datos maestros | ✓ | ||||||
| Crear usuarios | ✓ | ||||||
| Supervisar tareas | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Exportar reportes | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Acceder a GEM | ✓ | ✓ | ✓ |
Esta es una propuesta. Cada organización debe adaptar según su estructura y sensibilidad de información.
5.6. Criterios de administración de permisos
- Principio de menor privilegio: Conceder solo los permisos necesarios.
- Preferir grupos para funciones comunes.
- Usar permisos individuales como excepción documentada.
- Revisar periódicamente (p. ej., cada trimestre) los permisos de usuario cuando cambie de puesto.
- Revisar los perfiles de administrador: No distribuir ese rol innecesariamente.
- Documentar cambios sensibles: Quién hizo qué, cuándo y por qué.
- Usar el Explorador de permisos como herramienta principal: No editar dispersamente por usuario/grupo.
6. Visibilidad y segregación por origen
6.1. El concepto de origen
La AGF App utiliza una base de datos común, pero segrega información por origen (área funcional):
- COM: Comercial (ofertas, clientes, documentos comerciales).
- GP: Gestión de Proyectos (coordinación con cliente, reuniones).
- ING: Ingeniería (documentos técnicos, tareas de diseño).
- GEM: Gestión de Ejecución Material (campo, contratas, inventario).
- JO: Jefatura de Obra (obra, puesta en marcha).
Cada tarea, comentario, documento e informe pertenece a UN origen.
6.2. Cómo funciona la visibilidad
La visibilidad de un registro depende de tres capas:
- Origen del registro: ¿Es COM, GP, ING o GEM?
- Permisos del usuario sobre el origen: ¿Tiene permiso para ver información de ese origen?
- Restricciones de dato maestro: ¿El tipo de tarea/documento está restringido por usuario/grupo?
Un usuario ve un registro SÍ Y SOLO SÍ:
- Tiene acceso al origen (COM, GP, ING, etc.).
- Tiene permiso para el tipo específico.
- No hay restricción de grupo que lo bloquee.
Cuando un usuario no ve información:
- Verificar que el origen sea correcto.
- Verificar que tiene permisos para ese origen.
- Verificar que el tipo de tarea/documento no está restringido.
- Consultar los logs si hay duda.
7. Trazabilidad y acciones sensibles
7.1. Logs de actividad: auditoría de cambios
Los logs registran quién hizo qué, cuándo y en qué elemento. Son la base de la auditoría en AGF App.
Para consultar los logs de un elemento:
- Abrir la ficha del elemento (proyecto, tarea, documento, etc.).
- Hacer clic derecho dentro de la ficha.
- Seleccionar Consultar log.
- Se abre una ventana con el historial de cambios.
Qué se registra en un log:
- Usuario que hizo el cambio.
- Fecha y hora exacta.
- Qué campo se modificó.
- Valor anterior y valor nuevo.
- Motivo (si aplica).
Uso operativo:
- Investigar cuándo se modificó algo y quién lo hizo.
- Reconstruir el histórico de un proyecto.
- Verificar conformidad y auditoría.
- Detectar cambios no autorizados.
Los logs están en formato técnico. Una interfaz mejorada está en desarrollo para hacerlos más legibles.
7.2. Clonación: reutilización de estructuras
Una funcionalidad potente es clonar proyectos o tareas.
Casos de uso:
- Un proyecto está bien estructurado. Usar como plantilla para otro similar.
- Copiar un árbol de tareas de un proyecto a otro.
- Reutilizar documentos y entregables.
Lo que se puede clonar:
- Estructura completa del proyecto.
- Grupos de tareas.
- Tipos de documentos.
- Comentarios (opcional).
Ejemplo: Si el proyecto 226 (Murcia) está bien organizado, clonar su estructura al proyecto 373 (Nazaret) ahorra trabajo y asegura consistencia.
La capacidad de clonar mejorará en el futuro. Cuando se completen varios proyectos con tiempos bien imputados, la AGF App podrá estimar tiempos esperados para nuevos proyectos similares.
7.3. Eliminación de elementos: máxima precaución
La eliminación de registros (tareas, documentos, comentarios) es irreversible. Antes de eliminar:
- Comprobar que NO debe conservarse como historial.
- Revisar si hay elementos dependientes.
- Consultar los logs.
- Documentar por qué se elimina.
- Confirmar SOLO cuando el impacto esté claro.
Antes de eliminar una tarea:
- ¿Tiene subtareas? (Resolverlas primero)
- ¿Tiene fichajes? (¿Necesito esos datos?)
- ¿Tiene comentarios importantes? (¿Documentación para auditoría?)
- ¿Es un ejemplo o plantilla? (¿Otros la usan?)
Mejor opción: Cerrar la tarea en lugar de eliminarla. Así se preserva el histórico.
8. Integración y futuro: Sage y automatización
8.1. Integración con Sage (en desarrollo)
La AGF App está diseñada para integrar con Sage (sistema de contabilidad y administración) mediante API.
Objetivo:
- Información operativa (órdenes de compra, recepciones) fluye automáticamente a Sage.
- Reducir trabajo manual en administración.
- Evitar duplicación de datos.
- Mejorar exactitud.
Elementos que fluirán:
- Órdenes de compra.
- Recepciones de compras.
- Información de proyectos (para análisis de costos).
- Tiempos imputados (para análisis de productividad).
8.2. Automatización futura
Funcionalidades en desarrollo:
- Generación automática de órdenes de compra desde especificaciones.
- Carga automática de CSV/listados desde ingeniería.
- Actualización automática de inventario desde mediciones de campo.
- Exportación automática a Sage de datos contables.
Estas mejoras reducirán entrada manual de datos y aumentarán calidad.
9. Lista de comprobación administrativa
Antes de cerrar una intervención administrativa, verificar:
- El usuario o dato maestro tiene nombre claro y único.
- No hay duplicados o similares que creen confusión.
- En usuarios nuevos: nombre, apellidos, alias (formato: N+Ap1+Ap2), correo, teléfono, estado activo.
- El correo del usuario es correcto (recibirá credenciales allí).
- Se han asignado los grupos apropiados (preferir grupos a permisos individuales).
- Los permisos se han revisado mediante el Explorador de permisos (no individualmente).
- Las restricciones de dato maestro (si existen) son conscientes y documentadas.
- Los cambios de configuración (horarios, usuarios especiales) se han comunicado a los usuarios afectados.
- El resultado se ha verificado después de guardar.
- Antes de eliminar un usuario, se ha confirmado que no hay datos críticos asociados. Si hay duda: desactivar.
- Las acciones sensibles están justificadas y documentadas (logs, comentarios).
- La segregación por origen está clara: COM, GP, ING, GEM están diferenciadas.
10. Glosario de administración
| Término | Significado |
|---|---|
| Dato maestro | Valor reutilizable de configuración (tipo, estado, ambiente). Condiciona formularios y filtros. |
| Origen | Área funcional a la que pertenece un registro (COM, GP, ING, GEM, JO). Controla visibilidad. |
| Ambiente | Fase o momento del proyecto dentro de un origen. Ejemplo: Ingeniería Básica, Proyecto Técnico. |
| Grupo | Conjunto de usuarios con rol y permisos comunes. Simplifica gestión. |
| Permiso | Capacidad para realizar una acción (crear, editar, eliminar, supervisar). |
| Permiso efectivo | Unión de permisos individuales y de todos los grupos del usuario. |
| Alias | Identificador corto del usuario: inicial nombre + iniciales apellidos. Ejemplo: JCT. |
| Fichaje | Registro de tiempo imputado a una tarea, informe u otra actividad. |
| Log | Histórico de cambios de un elemento: quién, qué, cuándo, antes/después. |
| Explorador de permisos | Herramienta central para consultar y gestionar permisos de usuarios y grupos. |
| Segregación | Separación de información por origen para mantener privacidad y organización. |
| Clonar | Copiar estructura, tareas o documentos de un proyecto a otro para reutilización. |