# Novedades Humming — Octubre 2026

- Parámetros operativos compartidos con Motor V3 (SCRUM-92): V2 ahora lee estas claves de `fly.config` vía `AL_CONFIG()`, con el valor anterior como respaldo mientras la fila no exista. No se cargaron filas: las va a cargar el panel de V3, y hasta entonces V2 se comporta igual que antes.

  | Clave en `fly.config` | Dónde se usa en V2 | Respaldo |
  |---|---|---|
  | `reserve_expire_minutes` | `reserveTimeExprie` (airlines.php) | 10 |
  | `default_tax_percent` | `AIRLINE_DEFAULT_TAX_PERCENT` (airlines.php) | 10.5 |
  | `uala_max_approval_hours` | `UALA_MAX_APPROVAL_HOURS` (airlines.php) | 24 |
  | `adult_age` | `HUMMING.policies.adult_age` (cfg/humming.php) | 16 |
  | `max_booking_advance_months_intranet` | `HUMMING.policies.max_booking_advance_months` con usuario de intranet | 5 |
  | `max_booking_advance_months_public` | `HUMMING.policies.max_booking_advance_months` sin usuario logueado | 3 |

- `AL_CONFIG()` ahora devuelve el respaldo sin error si no hay conexión o falla la consulta a `fly.config`.
- Fix en la anticipación máxima de búsqueda: la constante `max_booking_advance_months` se calculaba antes de cargar `cfg/humming.php` y siempre valía 6 meses. Ahora se define en config.php después de esa carga y respeta la regla de negocio: 5 meses con usuario de intranet, 3 sin usuario (web pública vía motor.php). **Cambio de comportamiento:** la web pública pasa de mostrar 6 meses de vuelos a 3.
- Las 6 claves se cargan en `fly.config` de V2 producción con los valores actuales, porque esa base es la fuente que se copia a V3 (V2 PRD → local → V3 DEV → V3 PRD).
- Identidad y roles, fase 1 (spec en `api_humming_php/docs/identidad-y-roles/04_cambios_xgestion.md`), **solo local**:
  - **Base:** se crearon en `fly` local las tablas `operators`, `roles`, `permissions`, `role_permissions`, `operator_roles` y `auth_audit`, la vista `v_operators` y el procedimiento `sp_sync_operators`. Catálogo: 33 roles (los 32 bits cubiertos sin repetir), 100 permisos y 288 asignaciones rol-permiso.
  - **`ROLES()` y `EXTRA_ROLES()`:** las 32 entradas y `usrIsTravelAgency` llevan `flyRole`, con la constante nueva en `constants.php` (commit 5b80b01f).
  - **`SETUP_ROLES()`:** llama a `SETUP_FLY_ROLES()`, que verifica la regla (todas las entradas tienen `flyRole`, sin repetidos, y todos existen en `fly.roles`) y escribe `legacy_bits` / `legacy_extra_id` con prepared statements. Si algo falla, avisa en `pay.log` y no escribe. Nunca corta la pantalla (ccdc8edc).
  - **Ganchos:** `FLY_SYNC_QUEUE()` deja la sincronización para el final del request (una sola corrida aunque se disparen varios ganchos). `FLY_SYNC_OPERATORS()` la corre en una conexión propia y consume los 6 resultados. `FLY_SYNC_DAILY()` es la tarea diaria de respaldo. Puntos con gancho: `CREATE_RUS`, `ACC_CLEAR_ALL`, `SETUP_USER` (solo usuarios con acceso al 139, no cada persona nueva), `UPDATE_USER_SESSION` (solo si cambian los `permissions`), `rusUpdateForm`, `rusDeleteUser` y `Update_Rol`. Todo depende de `FLY_SYNC_ENABLED`, apagada por defecto (de858c24, ebea5db7).
  - **Diseño ajustado a producción (MariaDB 10.1.48):** sin funciones `JSON_*`, vista sin subconsultas, `email VARCHAR(191)`, y la sincronización excluye al usuario de sistema `id = 0` (Admin). En local se borraron los objetos del plan y se volvieron a crear con los SQL nuevos. El código PHP no cambió.
  - **Prueba local (diseño final):** el modo prueba y la aplicación dieron 157 operadores (9 staff + 148 externos), ninguno con `id = 0`, 258 roles y 3 cuentas huérfanas (1175, 1176 y 1179). Las 9 cuentas que faltaban en `fly.accounts` ya se habían agregado en la primera carga, así que esta vez dio 0; en producción deberían ser 9. Los roles de staff coinciden con `equivalencias-roles.md`, y una segunda corrida da 0 cambios. Desde el camino de la pantalla (`SysUpdateUser` → `SETUP_USER`, simulado por línea de comandos porque no había navegador): el alta EXTRANET crea el operador con `external_user`, la baja lo deja `disabled`.

## Bloqueos o pendientes relevantes para Humming
- Identidad y roles, para subir a producción (requiere el consentimiento de Claudio):
  - correr los 3 SQL **con el cliente de MariaDB**: el `mysql.exe` de MySQL 8.2 de WAMP se conecta en latin1 aunque se le pase utf8mb4, y deja los acentos doble codificados;
  - `SETUP_ROLES()`, después `CALL fly.sp_sync_operators(1, 1)` y comparar con local;
  - aplicar, encender `FLY_SYNC_ENABLED` y registrar `FLY_SYNC_DAILY` en `system.cron` (expire 86400).
- Falta probar el alta y la baja de acceso haciendo clic en la pantalla real (en local se probó el mismo código por línea de comandos).
- `UPDATE_USER_SESSION()` graba la `session` que el usuario cargó al hacer login. Si un administrador cambia la marca de agencia mientras ese usuario tiene la sesión abierta, el próximo guardado del usuario repone la marca vieja (y ahora eso llega a `fly`). Es un problema anterior: conviene corregirlo aparte.
- Sin gancho, quedan para la tarea diaria: el teléfono y el `wa_id` que actualiza el bot de WhatsApp (`wsp.php`), la fecha de último login y el alta de un sistema nuevo (`syschange.php`).
- `al_mdp_config` (kill-switch del checkout) sigue leyéndose de la sesión (`config.airline`), no de `fly.config`. En la copia local las dos fuentes no coinciden (`fly.config` = 1373 `mdpUnavailble`). No se cambia hasta comparar los valores en producción y confirmarlo con Claudio, porque si no se bloquea el cobro.