diff --git a/RESPUESTAS_FAQ.md b/RESPUESTAS_FAQ.md deleted file mode 100644 index 821d57f..0000000 --- a/RESPUESTAS_FAQ.md +++ /dev/null @@ -1,308 +0,0 @@ -# Preguntas Frecuentes - FAQ - -## ❓ ¿Ya está la página en producción? - -**Respuesta: NO, aún no está en producción.** - -### Estado Actual - -- ✅ **Proyecto configurado** para producción -- ✅ **Docker Compose** de producción listo -- ✅ **SSL/HTTPS** configurado (con certificados autofirmados) -- ✅ **Datos iniciales** preparados y listos para cargarse -- ❌ **NO desplegado** en un servidor público - -### Dónde Funciona Ahora - -- ✅ **Localmente** en tu máquina (http://localhost) -- ✅ **Desarrollo** con Docker (puerto 80) - -### Para Poner en Producción - -Ver [GUIA_PRODUCCION.md](GUIA_PRODUCCION.md) - Necesitas: - -1. Acceso al servidor (IP configurada: 132.248.80.77) -2. Configurar variables de entorno de producción -3. Certificados SSL válidos (o Let's Encrypt) -4. Ejecutar: `docker-compose up -d` - ---- - -## ❓ ¿Cuando alguien clone el repo, tendrá mi base de datos? - -**Respuesta: SÍ, automáticamente. ✅** - -### Cómo Funciona - -Cuando alguien clona el repositorio y ejecuta: - -```bash -git clone https://github.com/val20-11/Pagina-de-Asistencia-MAC.git -cd Pagina-de-Asistencia-MAC -cp .env.development.example .env.development -docker-compose -f docker-compose.dev.yml up -d -``` - -**Esto sucede automáticamente:** - -1. Docker inicia PostgreSQL (base de datos vacía) -2. Django ejecuta migraciones (crea tablas) -3. **`init_db.py` se ejecuta automáticamente** -4. El script detecta que la BD está vacía -5. Carga los fixtures desde `backend/fixtures/initial_data.json` -6. Los datos se importan a PostgreSQL -7. ¡El colaborador tiene exactamente tus mismos datos! - -### Qué Datos se Comparten - -El archivo `backend/fixtures/initial_data.json` contiene: - -- ✅ Tu usuario superusuario "Admin" -- ✅ Todos los usuarios asistentes que creaste -- ✅ Perfiles de usuario -- ✅ Eventos (si los exportaste) -- ✅ Asistencias registradas (si las exportaste) - -**IMPORTANTE:** Las contraseñas están hasheadas (seguras), NO están en texto plano. - ---- - -## ❓ ¿Pueden entrar con mi superusuario? - -**Respuesta: SÍ, pero solo si conocen la contraseña. ✅** - -### Seguridad de las Contraseñas - -Las contraseñas en los fixtures están **hasheadas** (encriptadas). Ejemplo: - -```json -{ - "username": "Admin", - "password": "pbkdf2_sha256$1000000$6z4YF8h...$XgRW+e3Bw..." -} -``` - -Esto NO es la contraseña real, es un hash. Nadie puede ver la contraseña original. - -### Cómo Funciona - -Cuando un colaborador clona el repo: - -1. ✅ Se crea el usuario "Admin" con el **mismo hash de contraseña** -2. ✅ Si el colaborador sabe tu contraseña original, puede entrar -3. ✅ Si NO sabe la contraseña, NO puede entrar - -### ¿Qué Hacer? - -#### Opción 1: Compartir la Contraseña (Equipo de Confianza) - -Si confías en tus colaboradores: -- Compárteles la contraseña del superusuario "Admin" -- Todos pueden administrar el sistema - -#### Opción 2: Que Cada Uno Cree su Superusuario - -Si NO quieres compartir tu contraseña: - -```bash -# Cada colaborador ejecuta: -docker-compose -f docker-compose.dev.yml exec backend python manage.py createsuperuser - -# Y crea su propio usuario admin -``` - -#### Opción 3: Cambiar la Contraseña en los Fixtures (Recomendado) - -Crea una contraseña genérica para desarrollo que todos conozcan: - -1. En tu máquina local: -```bash -docker-compose -f docker-compose.dev.yml exec backend python manage.py changepassword Admin -# Nueva contraseña: admin123 (por ejemplo) -``` - -2. Exportar los nuevos fixtures: -```bash -python export_fixtures.py -``` - -3. Subir a GitHub: -```bash -git add backend/fixtures/ -git commit -m "Actualizar contraseña de desarrollo" -git push origin main -``` - -4. Documentar en `SETUP_COLABORADORES.md`: - - Usuario: Admin - - Contraseña: admin123 - -**IMPORTANTE:** En producción, SIEMPRE cambia esta contraseña a una segura. - ---- - -## ❓ ¿Cómo actualizo los datos que comparto? - -**Respuesta: Con el script de exportación. ✅** - -### Proceso - -1. **Haz cambios** en tu base de datos local - - Crea usuarios - - Crea eventos - - Registra asistencias - - etc. - -2. **Exporta los cambios:** - ```bash - python export_fixtures.py - ``` - -3. **Sube a GitHub:** - ```bash - git add backend/fixtures/ - git commit -m "Actualizar datos iniciales" - git push origin main - ``` - -4. **Los colaboradores actualizan:** - ```bash - git pull origin main - docker-compose -f docker-compose.dev.yml down -v # Borra BD actual - docker-compose -f docker-compose.dev.yml up -d # Recarga fixtures - ``` - ---- - -## ❓ ¿Qué pasa si NO quiero compartir todos mis datos? - -**Respuesta: Puedes crear fixtures personalizados. ✅** - -### Opción 1: Exportar Solo Ciertos Modelos - -Modifica `export_fixtures.py` para exportar solo lo que quieras: - -```python -# Solo usuarios, sin eventos -cmd = [ - "docker", "exec", "pagina-de-asistencia-mac-backend-1", - "python", "manage.py", "dumpdata", - "--indent", "2", - "auth.user", # Solo esto - "authentication.userprofile" # Y esto - # NO exportar eventos ni asistencias -] -``` - -### Opción 2: Crear Fixtures Mínimos - -Crea fixtures básicos a mano con solo: -- 1 superusuario genérico -- 1-2 usuarios de ejemplo - -### Opción 3: Usar Variables de Entorno - -En producción, carga diferentes fixtures: - -```bash -# En .env.production -LOAD_INITIAL_FIXTURES=false - -# En init_db.py, verificar esta variable -``` - ---- - -## ❓ ¿Los fixtures se suben a GitHub? - -**Respuesta: SÍ, están configurados para subirse. ✅** - -### Qué se Sube - -- ✅ `backend/fixtures/*.json` - Datos iniciales (usuarios, eventos) -- ✅ `backend/fixtures/*.sql` - Backups SQL (si existen) - -### Qué NO se Sube - -- ❌ `.env` - Variables de entorno (contraseñas, claves) -- ❌ `backend/db.sqlite3` - Base de datos SQLite -- ❌ `backend/media/` - Archivos subidos -- ❌ `backend/logs/` - Logs - -Ver `.gitignore` para detalles. - ---- - -## ❓ ¿Qué pasa en producción con los fixtures? - -**Respuesta: Se cargan automáticamente si la BD está vacía. ✅** - -### Primera Vez en Producción - -```bash -# En el servidor de producción: -docker-compose up -d - -[Automáticamente]: -1. PostgreSQL inicia (vacío) -2. Django migra las tablas -3. init_db.py detecta BD vacía -4. Carga backend/fixtures/initial_data.json -5. ¡Sistema listo con tus datos! -``` - -### Actualizaciones en Producción - -Si la BD ya tiene datos, `init_db.py` NO los sobrescribe: - -```python -# En init_db.py: -if User.objects.count() > 0: - print("BD ya tiene usuarios, no se cargan fixtures") - return -``` - -Esto previene duplicados y pérdida de datos. - ---- - -## ❓ ¿Cómo funciona sin servidor de producción? - -**Respuesta: Funciona perfectamente en modo desarrollo. ✅** - -### Actualmente (Sin Servidor) - -- ✅ Funciona en tu máquina local -- ✅ Colaboradores lo usan en sus máquinas -- ✅ Cada uno tiene su propia base de datos PostgreSQL local -- ✅ Todos comparten los mismos datos iniciales (via fixtures) - -### Cuando Tengas Servidor - -- ✅ Mismo código, misma configuración -- ✅ Solo cambias de `docker-compose.dev.yml` a `docker-compose.yml` -- ✅ Configuras variables de producción en `.env.production` -- ✅ ¡Listo para producción! - ---- - -## ❓ Resumen de Respuestas Rápidas - -| Pregunta | Respuesta | -|----------|-----------| -| ¿Está en producción? | NO, solo local. Listo para desplegar cuando tengas servidor. | -| ¿Los colaboradores tienen mi BD? | SÍ, automáticamente via fixtures. | -| ¿Pueden usar mi superusuario? | SÍ, si conocen la contraseña (está hasheada). | -| ¿Los fixtures se suben a Git? | SÍ, configurado en .gitignore. | -| ¿Cómo actualizar datos? | `python export_fixtures.py` + git push | -| ¿Funciona sin servidor? | SÍ, perfecto en modo desarrollo. | -| ¿Listo para producción? | SÍ, cuando tengas acceso al servidor. | - ---- - -## 📞 Más Información - -- **Inicio Rápido:** [QUICK_START.md](QUICK_START.md) -- **Para Colaboradores:** [SETUP_COLABORADORES.md](SETUP_COLABORADORES.md) -- **Para Producción:** [GUIA_PRODUCCION.md](GUIA_PRODUCCION.md) -- **Resumen Técnico:** [RESUMEN_CONFIGURACION.md](RESUMEN_CONFIGURACION.md)