# Servidor RinoTrack ## Acceso - **IP:** 18.214.40.71 - **Usuario SSH:** bitnami - **Llave:** `rinotrack.pem` (en la raíz del proyecto) - **Stack:** Bitnami (Apache + MariaDB), PHP servido directo por Apache (sin build ni reinicio) Conexión: ```bash ssh -o StrictHostKeyChecking=no -i rinotrack.pem bitnami@18.214.40.71 ``` ## Rutas importantes en el servidor - **App en producción (la que sirve Apache):** `/opt/bitnami/apache/htdocs/desarrollo/rinotrack` - Es un directorio plano, **NO es repositorio git**. Se despliega copiando archivos. - El docroot público es `desarrollo/rinotrack/public`. - Existen varias copias/backups en `htdocs` (desarrollobkabdiel, alfa, etc.) y en `/home/bitnami/deploy/rinotrack`. La única productiva es `desarrollo/rinotrack`. ## Base de datos - **Motor:** MariaDB 11.8 (cliente `mysql`/`mariadb`) - **Host:** localhost (solo accesible desde el propio servidor) - **Usuario:** root - **Password:** `/VFwtcC6Xj18` - **Base:** rinotrack Consulta rápida desde la terminal local (a través de SSH, usando un archivo `.sql`): ```bash # 1) Escribe tu consulta en un archivo local tmp_query.sql # 2) Ejecútala en el servidor: ssh -o StrictHostKeyChecking=no -i rinotrack.pem bitnami@18.214.40.71 \ "mysql -uroot -p'/VFwtcC6Xj18' rinotrack -t" < tmp_query.sql 2>&1 | grep -v Deprecated ``` Notas: - Se usa `-t` para salida en tabla y se filtra la advertencia "Deprecated program name" con `grep -v Deprecated`. - Enviar el SQL por archivo (redirección `<`) evita los problemas de escapado de comillas al usar `-e "..."` a través de SSH. - Los nombres de tabla usan mayúsculas iniciales: `Users`, `Tasks`, `Subtasks`, `Projects`, `Clans`, `Clan_Members`, `User_Active_Clan`, etc. ## Forma de despliegue (deploy) Como producción no es un repo git, el despliegue se hace **copiando el/los archivos modificados por SCP**, siempre respaldando primero. 1. Validar sintaxis del archivo localmente: ```bash php -l app/controllers/ClanLeaderController.php ``` 2. Respaldar el archivo en el servidor (con fecha en el nombre): ```bash ssh -o StrictHostKeyChecking=no -i rinotrack.pem bitnami@18.214.40.71 \ "cp /opt/bitnami/apache/htdocs/desarrollo/rinotrack/app/controllers/ClanLeaderController.php \ /opt/bitnami/apache/htdocs/desarrollo/rinotrack/app/controllers/ClanLeaderController.php.bak_YYYYMMDD" ``` 3. Subir el archivo corregido: ```bash scp -o StrictHostKeyChecking=no -i rinotrack.pem \ app/controllers/ClanLeaderController.php \ bitnami@18.214.40.71:/opt/bitnami/apache/htdocs/desarrollo/rinotrack/app/controllers/ClanLeaderController.php ``` 4. Verificar en el servidor (md5 debe coincidir con el local, sintaxis OK): ```bash # md5 local (macOS): md5 -q app/controllers/ClanLeaderController.php # md5 + lint en el servidor: ssh -o StrictHostKeyChecking=no -i rinotrack.pem bitnami@18.214.40.71 \ "cd /opt/bitnami/apache/htdocs/desarrollo/rinotrack && \ md5sum app/controllers/ClanLeaderController.php && \ php -l app/controllers/ClanLeaderController.php" ``` 5. No hace falta reiniciar Apache: PHP se interpreta en cada request. El cambio queda activo de inmediato. Rollback: restaurar el `.bak_YYYYMMDD` sobre el archivo original con `cp`. ## Sistema de diseño (tema ClickUp) Desde el 2026-08-30 la interfaz usa un sistema de tokens único, sin build step. Hojas nuevas, en este orden de carga (siempre **al final del ``**): 1. `public/assets/css/clickup-tokens.css` — paleta clara y oscura + alias que reapuntan las familias heredadas (`--monday-*`, `--admin-*`, `--cm-*`, `--ticket-*`, `--sidebar-*`). 2. `public/assets/css/clickup-theme.css` — componentes: botones, formularios, tarjetas, tablas, modales, badges, kanban, pestañas, sidebar y scrollbars. 3. `public/assets/css/clickup-screens.css` — ajustes por pantalla. 4. `public/assets/css/clickup-dark-fixes.css` — neutraliza los `style=""` que fijan blanco. Reglas para no romper el tema al editar CSS: - Los alias usan el selector `html[data-theme]`, no `:root`. Es intencional: varias vistas cargan `monday-theme.css` **dentro del ``**, o sea después del ``, y con `:root` ganarían por orden de carga. `html[data-theme]` tiene mayor especificidad y gana siempre, sin `!important`. - En `clickup-screens.css` cada selector va precedido de `html[data-theme]` por el mismo motivo. - Nunca sustituir literales de color que consuma JavaScript (Chart.js y similares): esas librerías no resuelven variables CSS. Modo claro/oscuro: - El tema vive en `data-theme` sobre `` (valores `light` o `dark`). - Se persiste en `localStorage` con la clave `rinotrack-theme`. - El parcial `app/views/components/theme-head.php` incluye el script anti-parpadeo que fija el tema antes del primer pintado; `theme-scripts.php` carga el conmutador. - El botón está en el pie del sidebar. **No** lleva la clase `.sidebar-link` a propósito, porque `sidebar.js` cierra el menú móvil al pulsar cualquier `.sidebar-link`. Para añadir una pantalla nueva con HTML propio, incluir los dos parciales: ```php ``` ## Módulo de Encuestas Desde el 2026-09-01 Polaris tiene un módulo de Encuestas en el menú lateral. **Los datos no viven en `rinotrack`**, sino en la base `notification_system`, que se comparte con RinoMailer (la app de `/notificaciones`). ### Por qué se comparte la base RinoMailer es una aplicación aparte, con su propio router y su propio login (tabla `admins`). Sus encuestas ya estaban en uso —94 encuestas y más de 2,400 respuestas— y los enlaces para responder ya estaban repartidos. Migrar los datos habría roto esos enlaces, así que Polaris se conecta a la misma base: - **Polaris** crea, edita y analiza las encuestas. - **RinoMailer** sigue sirviendo el formulario público en `/notificaciones/survey/{id}`. ``` Polaris ──> notification_system.surveys <── RinoMailer (enlace público) │ │ └── rinotrack.Users ──┘ (JOIN entre esquemas, por owner_user_id) ``` ### Segunda conexión de base de datos `Database::getSurveyConnection()` en `config/database.php` devuelve un PDO apuntando a `SURVEY_DB_NAME` (`notification_system`). Desde esa conexión, las tablas de Polaris se alcanzan con el prefijo `DB_NAME`; ambos esquemas están en el mismo servidor MariaDB, así que el JOIN entre ellos funciona sin más. Si la conexión falla, el método devuelve `null` y el resto de Polaris sigue vivo. `SURVEY_PUBLIC_URL` en `config/app.php` arma la raíz del enlace público. Cuelga del host, no de la ruta de Polaris, porque lo sirve la otra aplicación. ### Quién ve qué | Quién | Alcance | |---|---| | Super administrador y administrador | Todo, incluidas las **históricas** | | Usuario con el módulo activado | Las suyas y las de sus compañeros de clan | | Cualquier otro | Nada; el menú no aparece y las rutas devuelven 403 | Los clanes salen de `User::getUserClans()`, que los lee de `Clan_Members`. Un usuario de Marketing nunca ve la encuesta de comedor de Recursos Humanos. **Encuestas históricas:** las 94 creadas en RinoMailer antes de la integración no tienen propietario (`owner_user_id` nulo, `source = 'rinomailer'`). Solo las ve el super administrador, con una etiqueta que las identifica. Las que se sigan creando desde RinoMailer caerán en la misma categoría. ### Activación por usuario La concede **solo el super administrador**, desde `admin/users`: una casilla en el modal de edición y un botón de encendido rápido en cada fila. Se guarda en `Users.surveys_enabled`. El endpoint `admin/toggle-surveys-access` valida el rol de forma explícita e ignora el campo si lo manda cualquier otro. ### Vigencia programada `surveys.opens_at` y `surveys.closes_at` abren y cierran la encuesta sola. La validación vive en el `SurveyController` de RinoMailer, tanto en `publicView()` como en `submit()`, porque alguien puede dejar el formulario abierto y enviarlo después del cierre. Sin fechas, la encuesta queda siempre abierta, que es como se comportaba antes. ### Archivos | Archivo | Rol | |---|---| | `app/models/Survey.php` | Consultas, alcance por clan, estadísticas | | `app/controllers/SurveyController.php` | Acciones, permisos, exportación | | `app/views/surveys/` | Listado, constructor, resultados, reporte, aviso | | `app/views/components/surveys_menu.php` | Grupo desplegable del sidebar | | `public/assets/css/surveys.css` | Estilos sobre los tokens ClickUp | | `notificaciones/controllers/SurveyController.php` | Copia versionada del archivo de RinoMailer que se modificó | | `migrations/2026_09_01_surveys_module.sql` | Las dos migraciones | | `migrations/2026_09_03_survey_meals.sql` | Encuestas de comedor | Al editar una encuesta que ya tiene respuestas, el constructor se bloquea: guardar el cuestionario borra y reinserta las preguntas, y el borrado en cascada se llevaría las respuestas. Solo se editan los datos generales. ### Encuestas de comedor Un segundo tipo de encuesta (`surveys.survey_kind = 'comedor'`) donde cada respuesta afirmativa se convierte en una deducción de nómina. ``` RH crea la encuesta Empleado responde RH calcula el período (congela la tarifa) --> (con sesión, en Polaris) --> (líneas automáticas) ``` Tres decisiones sostienen el diseño: - **El formulario vive en Polaris** (`?route=surveys/respond&id=`), no en el enlace público de RinoMailer. Ese enlace es anónimo y no puede identificar al empleado, y sin identificarlo no hay a quién cobrarle. Las encuestas marcadas con `requires_login` se rechazan en `publicView()` y `submit()` de RinoMailer, que muestra un botón hacia Polaris. - **Las opciones las escribe el sistema** (`Sí, lo quiero` / `No, gracias`) y el tipo queda fijo en opción única. RH solo redacta el día y el platillo. Si RH pudiera escribir las opciones, no habría manera inequívoca de contar consumos. - **La tarifa se congela al crear la encuesta** en `meal_cost_desayuno` y `meal_cost_comida`. El motor de nómina nunca lee la tarifa vigente, así que subir el precio del comedor no cambia lo que ya se cobró. El período destino es el que contiene `surveys.created_at`, es decir la semana en que se lanzó. Puede no existir todavía: `calculatePeriod()` busca las encuestas por rango de fechas, así que el cobro entra solo cuando RH cree el período. Las líneas `DESC_DESAYUNO` y `DESC_COMIDA` se insertan con `origen = 'automatico'` dentro del motor, no como conceptos manuales: así se regeneran en cada recálculo (si alguien cambia su pedido) y respetan el bloqueo de períodos cerrados. El índice único `(survey_id, respondent_user_id)` hace que el empleado corrija su pedido en lugar de acumular respuestas, que es lo que duplicaría el cobro. Las tarifas se editan en `?route=surveys/meal-settings` pero se guardan en `Payroll_Settings`, porque son política de nómina; la pantalla exige `payroll_enabled` además del acceso a Encuestas. #### Horario de comida Toda encuesta que cobre **comida** lleva al final una pregunta obligatoria de horario que agrega el sistema. Las de desayuno no la llevan: fue una regla explícita del cliente. Se distingue por `survey_questions.meal_service = 'horario'`, que no es un servicio sino una marca de "informativa, no se cobra". Por eso `Survey::servicioDePregunta()` devuelve NULL para ella aunque la encuesta tenga un solo servicio: sin esa salida temprana, el fallback que hace heredar el servicio único la habría contado como un consumo más. Los horarios salen de `Payroll_Settings.horarios_comida` (lista separada por comas) y se copian a las opciones de la pregunta al crear la encuesta, así que quedan congelados igual que el precio. El empleado elige **un horario para toda la semana**, no uno por día, y solo se le exige si pidió al menos un día de comida. ### Menú desplegable del sidebar Es el primer grupo tipo acordeón del sidebar. El disparador es un `