Saltar al contenido principal

Manual de AGF App: Administración

Alcance

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.

aviso

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.
nota

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:

ÁreaAmbientes típicos
ComercialContacto, Oferta, Propuesta, Seguimiento, Post-venta
IngenieríaIngeniería Básica, Proyecto Técnico, Ingeniería de Detalle, Ingeniería de Ejecución, Puesta en marcha
GPPlanificación, Ejecución, Puesta en operación, Cierre
GEMMontaje en taller, Obra civil, Instalación eléctrica, Montaje en campo, Operación
consejo

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:

  1. Acceder a Base de datos en el menú de administración.
  2. Abrir la categoría correspondiente (Tipos de tarea, Ambientes, Tipos de documento, etc.).
  3. Crear un registro nuevo o editar uno existente.
  4. 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.
  5. Guardar.
  6. 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.

aviso

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:

  1. Permiso sobre el tipo de informe (p. ej., "Informe técnico").
  2. 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.

nota

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:

  1. Acceder a Configuración del sistema.
  2. Localizar la sección de Fichajes o Cierre automático.
  3. Ajustar el horario acordado.
  4. Guardar el cambio.
  5. Comunicar a los usuarios afectados el nuevo horario.
información

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.

aviso

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".
peligro

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:

CampoDescripciónObligatorio
NombreNombre de pila.
Apellido 1Primer apellido.
Apellido 2Segundo apellido (si aplica).
AliasInicial del nombre + iniciales de apellidos, en mayúsculas. Ej: Javier Cuenca Torres → JCT
CorreoCorreo corporativo. Fundamental para recibir credenciales.
TeléfonoTeléfono de contacto.
FotografíaImagen de perfil (opcional pero recomendada).
EstadoActivo / Inactivo. Los usuarios inactivos no pueden acceder.
AdministradorSí / No. Solo asignar cuando sea necesario.
GruposRoles a los que pertenece el usuario.
ContraseñaGenerada por el sistema. Se envía por correo.
consejo

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:

  1. Crear ficha: Acceder a UsuariosNuevo usuario.
  2. Datos básicos:
    • Nombre, apellidos.
    • Calcular alias automáticamente (inicial + iniciales apellidos).
    • Correo corporativo.
    • Teléfono.
  3. Estado: Marcar como Activo.
  4. Fotografía: Subir una foto (recomendado para reconocimiento visual).
  5. 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.

  6. Grupos: Asignar los grupos que correspondan:
    • Ingeniería.
    • Comercial.
    • Control de calidad.
    • Dirección.
    • Etc.
  7. Permisos individuales: Asignar solo si hay excepciones. Preferir usar grupos.
  8. Contraseña: Generar y confirmar.
  9. Guardar.
  10. Verificación: El usuario recibirá un correo con credenciales. Comprobar que accede correctamente.
aviso

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:

  1. Buscar al usuario en Usuarios.
  2. Pulsar Restablecer contraseña (ícono de llave naranja).
  3. Confirmar la operación.
  4. El sistema genera una contraseña temporal y la envía por correo.
aviso

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.
peligro

CRÍTICO: Solo si no hay datos asociados o han sido previamente migrados. Consultar antes.

aviso

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:

GrupoFunciónPermisos típicos
DirecciónAcceso total, supervisión.Todos, eliminar, supervisar.
AdministraciónMantener plataforma, usuarios, datos.Crear usuarios, editar permisos, datos maestros.
IngenieríaDiseño, cálculos, documentos técnicos.Crear/editar tareas ING, ver documentos técnicos.
ComercialOfertas, clientes, negociación.Crear/editar tareas COM, documentos comerciales.
Gestión de ProyectosCoordinación con cliente.Ver todo, comentar, crear tareas GP.
GEMCampo, contratas, inventario.Tareas GEM, entradas de campo, inventario.
Control de CalidadSupervisió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.
consejo

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:

  1. Permisos asignados directamente al usuario.
  2. 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.
aviso

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:

  1. Acceder a Base de datosExplorador de permisos.
  2. Buscar el permiso deseado (p. ej., "Eliminar tareas", "Crear documentos", "Supervisar").
  3. Revisar qué usuarios y grupos lo tienen asignado actualmente.
  4. Añadir: Cliquear en usuario/grupo y marcar el permiso.
  5. Retirar: Desmarcar el permiso en usuario/grupo.
  6. Guardar cambios.
  7. Verificar el resultado volviendo a ver el permiso para confirmar que está como deseado.
información

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:

PermisoDirecciónAdminIngenieríaComercialGPGEMControl 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
nota

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:

  1. Origen del registro: ¿Es COM, GP, ING o GEM?
  2. Permisos del usuario sobre el origen: ¿Tiene permiso para ver información de ese origen?
  3. 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.
consejo

Cuando un usuario no ve información:

  1. Verificar que el origen sea correcto.
  2. Verificar que tiene permisos para ese origen.
  3. Verificar que el tipo de tarea/documento no está restringido.
  4. 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:

  1. Abrir la ficha del elemento (proyecto, tarea, documento, etc.).
  2. Hacer clic derecho dentro de la ficha.
  3. Seleccionar Consultar log.
  4. 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.
aviso

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.

consejo

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

peligro

La eliminación de registros (tareas, documentos, comentarios) es irreversible. Antes de eliminar:

  1. Comprobar que NO debe conservarse como historial.
  2. Revisar si hay elementos dependientes.
  3. Consultar los logs.
  4. Documentar por qué se elimina.
  5. 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érminoSignificado
Dato maestroValor 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.
AmbienteFase o momento del proyecto dentro de un origen. Ejemplo: Ingeniería Básica, Proyecto Técnico.
GrupoConjunto de usuarios con rol y permisos comunes. Simplifica gestión.
PermisoCapacidad para realizar una acción (crear, editar, eliminar, supervisar).
Permiso efectivoUnión de permisos individuales y de todos los grupos del usuario.
AliasIdentificador corto del usuario: inicial nombre + iniciales apellidos. Ejemplo: JCT.
FichajeRegistro de tiempo imputado a una tarea, informe u otra actividad.
LogHistórico de cambios de un elemento: quién, qué, cuándo, antes/después.
Explorador de permisosHerramienta central para consultar y gestionar permisos de usuarios y grupos.
SegregaciónSeparación de información por origen para mantener privacidad y organización.
ClonarCopiar estructura, tareas o documentos de un proyecto a otro para reutilización.