Files
pagasis/RESPUESTAS_FAQ.md
T

7.8 KiB

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 - 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:

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:

{
  "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:

# 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:
docker-compose -f docker-compose.dev.yml exec backend python manage.py changepassword Admin
# Nueva contraseña: admin123 (por ejemplo)
  1. Exportar los nuevos fixtures:
python export_fixtures.py
  1. Subir a GitHub:
git add backend/fixtures/
git commit -m "Actualizar contraseña de desarrollo"
git push origin main
  1. 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:

    python export_fixtures.py
    
  3. Sube a GitHub:

    git add backend/fixtures/
    git commit -m "Actualizar datos iniciales"
    git push origin main
    
  4. Los colaboradores actualizan:

    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:

# 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:

# 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

# 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:

# 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