# Tablero CDC Aplicación interna para la gestión visual de aprobaciones de proyectos creativos del equipo CDC de **GomezLee Marketing**. El objetivo de esta app es simplificar el flujo de trabajo del equipo creativo mediante un tablero tipo Trello, donde cada tarjeta representa un proyecto y centraliza sus datos principales, enlaces y estado de aprobación. --- ## Estado actual Esta versión incluye: - Proyecto React + Vite limpio. - Limpieza del ecosistema Lovable. - Corrección de `County Manager` a `Country Manager`. - Configuración de `base: "/tablero-cdc/"` en `vite.config.ts`. - Favicon personalizado para la pestaña del navegador. - Login corporativo con Supabase Auth y Google Sign-In. - Restricción de acceso a correos `@gomezleemarketing.com`. - Usuario autenticado real en el encabezado. - Botón de cerrar sesión. - Rol `isGerardo` para Gerardo Marrero. - Permisos visuales iniciales: solo Gerardo Marrero puede ver/editar monto interno y editar estatus. - Paginación local en las vistas de Todos, Activos y Cerrados con 12 proyectos por página. - Persistencia de proyectos en Supabase. - Sincronización multiusuario con Supabase Realtime. - Desplegables dinámicos desde Supabase `app_lists`, con fallback local mientras se termina la sincronización del Sheet. --- ## Funcionalidades principales - Tablero visual de proyectos. - Tarjetas por proyecto. - Filtros por estado: Todos, Activos y Cerrados. - Buscador por datos del proyecto. - Modal de creación y edición de proyecto. - Campos para cliente, marca, país, solicitante y `Country Manager`. - Link de brief. - Links múltiples de propuestas. - Links múltiples de artes finales. - Etiquetas de color por proyecto. - Estatus visible para todos los usuarios. - Monto interno visible solo para Gerardo Marrero. - Paginación local para manejar tableros con muchos proyectos. --- ## Funcionalidades pendientes Las siguientes funcionalidades se implementarán en próximas fases: 1. Sincronización automática de la hoja `listas` del Google Sheet original hacia Supabase `app_lists`. 2. Escritura automática de datos en el Sheet original mediante n8n u otra integración definida. 3. Agregar una nueva columna final para enlace de brief en el Sheet original. 4. Reglas de seguridad definitivas con Supabase RLS. 5. Optimización futura de carga con RPC si el volumen de datos lo requiere. --- ## Arquitectura prevista ```text Frontend React/Vite ↓ Supabase Auth ↓ Supabase Database/Postgres + Realtime + RLS ↓ n8n como capa de integración ↓ Google Sheets original ↓ Power BI ``` La app no debe modificar la estructura existente del Sheet original, ya que ese archivo alimenta un dashboard de Power BI. Cualquier columna nueva debe agregarse al final y validarse previamente. --- ## Instalación local Instalar dependencias: ```bash npm install ``` Ejecutar en modo desarrollo: ```bash npm run dev ``` Generar build de producción: ```bash npm run build ``` Vista previa del build: ```bash npm run preview ``` --- ## Variables de entorno Crear un archivo `.env` local basado en `.env.example`. Estructura esperada: ```env VITE_SUPABASE_URL="" VITE_SUPABASE_ANON_KEY="" VITE_WEBHOOK_URL="" ``` El campo `VITE_WEBHOOK_URL` puede permanecer vacío hasta que se defina la integración con n8n. La `anon key` de Supabase es pública para el frontend; nunca subir claves privadas como `service_role`, secretos OAuth o contraseñas de base de datos. --- ## Seguridad No se deben subir al repositorio: - `.env` - `.env.local` - `.env.production` - `.env.development` - `node_modules` - `dist` - tokens - credenciales - archivos con secretos - logs innecesarios El archivo `.env.example` sí puede subirse, siempre que no contenga valores reales. --- ## Despliegue El proyecto está preparado para publicarse bajo la ruta: ```ts base: "/tablero-cdc/"; ``` Si la ruta final cambia, debe actualizarse `vite.config.ts` y el `basename` del router si aplica. --- ## Notas importantes - Este repositorio representa la base inicial del proyecto. - El diseño base fue aprobado antes de iniciar las integraciones técnicas. - Las próximas fases deben implementarse en commits separados. - No se debe alterar la estructura del Google Sheet original sin validación previa. - La integración con Power BI depende de mantener estable la estructura del Sheet. --- ## Equipo Proyecto interno de **GomezLee Marketing**. Desarrollo y soporte técnico: **Isaac Aracena**. ## Persistencia en Supabase Esta versión ya no depende de `localStorage` para los proyectos. El tablero lee y guarda la información en Supabase usando las tablas: - `projects` - `project_links` - `profiles` - `app_lists` Notas importantes: - Los proyectos abiertos se guardan en base de datos con `status = 'Activo'`, pero en la interfaz se muestran como proyectos sin estatus para mantener el comportamiento visual original. - Los usuarios normales no ven ni actualizan el monto interno desde la app. - Solo Gerardo Marrero puede modificar estatus, monto interno y eliminar proyectos desde la interfaz. - Los links de propuestas y artes finales se guardan en `project_links`. - Los desplegables se leen desde `app_lists`. Si una categoría todavía no existe en Supabase, la app usa una lista local de respaldo para no bloquear el formulario. ## Supabase Realtime Para que la sincronización multiusuario funcione, habilita Realtime para las tablas `projects`, `project_links` y `app_lists` ejecutando en Supabase SQL Editor el archivo: ```text supabase_realtime_projects.sql ``` Luego abre la app en dos pestañas o dos navegadores: al crear, editar o eliminar un proyecto en una ventana, la otra debe actualizarse automáticamente. ## Desplegables dinámicos La app intenta cargar estos desplegables desde `public.app_lists`: - `client` / `cliente` / `clientes` - `brand` / `marca` / `marcas` - `country` / `pais` / `bu` - `status` / `estatus` - `country_manager` / `cm` / `bu_cm` para mapear BU → Country Manager Si una categoría aún no existe en Supabase, se usa el respaldo local del frontend. Más adelante n8n sincronizará la hoja `listas` del Sheet original hacia `app_lists`.