Files

José Salazar 5136b1d6b5 other modifications days ago

2025-12-26 15:14:51 -05:00

12 KiB

Raw Blame History

Análisis Exhaustivo de Mocks de Staff App vs. Schema de Data Connect (V2)

Este documento realiza una comparación detallada y completa entre todas las estructuras de datos (mocks) utilizadas en la aplicación de Staff y las entidades definidas en el schema de GraphQL de Firebase Data Connect. El objetivo es asegurar la consistencia total y planificar la evolución del schema.

1. Perfil de Leaderboard (`_profiles`)

Archivo Mock: lib/screens/worker/worker_profile/level_up/leaderboard_screen.dart
Entidad Data Connect: Staff (dataconnect/schema/staff.gql)
Análisis: Existe una correspondencia directa pero incompleta.

Recomendaciones:

App: Renombrar name a employeeName.

Schema staff.gql: Agregar campos para gamificación y perfil.

type Staff @table(name: "staffs") {
  # ... campos existentes
  profilePictureUrl: String
  experiencePoints: Int @default(expr: "0")
  level: String
}

2. Conversaciones (`_conversations`)

Archivo Mock: lib/screens/worker/worker_profile/support/messages_screen.dart
Entidades Data Connect: Conversation (conversation.gql) y Message (message.gql).
Análisis: El mock es una vista aplanada de ambas entidades. El schema es más robusto pero requiere que la app orqueste las llamadas.
Recomendaciones:
- App:
  - Adaptar la lógica para manejar el campo participants (JSON array) en lugar de un sender_id simple.
  - Obtener sender_name y lastMessage a través de consultas adicionales (al perfil del participante y al último mensaje).
  - El campo unread es el más complejo. Debe calcularse en el cliente revisando la lista de readBy en cada mensaje.
- Schema: Para optimizar el conteo de no leídos a futuro, se podría crear una tabla ConversationReadStatus (userId, conversationId, lastReadTimestamp).

3. Hojas de Tiempo (`_timesheets`)

Archivo Mock: lib/screens/worker/worker_profile/finances/time_card_screen.dart
Entidades Data Connect: Shift (shift.gql) y Event (event.gql).
Análisis: El mock combina información del turno y del evento. Faltan campos cruciales en el schema Shift para el registro de horas y pagos.

Recomendaciones:

App: Realizar una consulta que una datos de Shift y su Event relacionado para construir la vista.

Schema shift.gql: Agregar los siguientes campos es prioritario.

# En dataconnect/schema/shift.gql
enum ShiftPaymentStatus {
  PENDING
  APPROVED
  PAID
  DISPUTED
}

type Shift @table(name: "shifts") {
  # ... campos existentes
  actualStartTime: Timestamp
  actualEndTime: Timestamp
  rate: Float # Tarifa específica del turno
  paymentStatus: ShiftPaymentStatus
}

4. Certificados (`_certificates`)

Archivo Mock: lib/screens/worker/worker_profile/compliance/certificates_screen.dart
Entidad Data Connect: Certification (certification.gql).
Análisis: Coincidencia conceptual fuerte.
Recomendaciones:
- App: Renombrar name a certificationName y expiry a expiryDate.
- Schema certification.gql: Añadir un campo opcional description: String.

5. Contactos de Emergencia (`_contacts`)

Archivo Mock: lib/screens/worker/worker_profile/onboarding/emergency_contact_screen.dart
Entidad Data Connect: Ninguna.
Análisis: No existe una entidad para esta información vital.

Recomendaciones:

Schema: Crear una nueva entidad EmergencyContact vinculada al Staff. Almacenarla en una tabla separada es preferible a un campo JSON en Staff por escalabilidad.

# En dataconnect/schema/emergencyContact.gql
type EmergencyContact @table(name: "emergency_contacts") {
  id: UUID! @default(expr: "uuidV4()")
  staffId: UUID!          # FK a la tabla Staff
  name: String!
  phone: String!
  relationship: String    # Ejemplo: "Spouse", "Parent"
  createdDate: Timestamp @default(expr: "request.time")
}

6. Opciones de Vestimenta (`_attireOptions`)

Archivo Mock: lib/screens/worker/worker_profile/onboarding/attire_screen.dart
Entidad Data Connect: Ninguna.
Análisis: Representa el inventario de vestimenta de un trabajador, que puede ser requisito para un turno.

Recomendaciones:

Schema: Crear dos nuevas entidades: una para definir la vestimenta estándar y otra para asociarla a cada trabajador.

# En dataconnect/schema/attire.gql
type Attire @table(name: "attire") {
  id: UUID! @default(expr: "uuidV4()")
  label: String!
  imageUrl: String
}

# En dataconnect/schema/staffAttire.gql
type StaffAttire @table(name: "staff_attire") {
  id: UUID! @default(expr: "uuidV4()")
  staffId: UUID!
  attireId: UUID!
}

7. Cursos de Capacitación (`_courses`)

Archivo Mock: lib/screens/worker/worker_profile/level_up/trainings_screen.dart
Entidad Data Connect: Ninguna.
Análisis: Distinto de Certification, se enfoca en capacitación interna y gamificación.

Recomendaciones:

Schema: Crear entidades para los cursos y el progreso de cada trabajador.

# En dataconnect/schema/trainingCourse.gql
type TrainingCourse @table(name: "training_courses") {
  id: UUID! @default(expr: "uuidV4()")
  title: String!
  description: String
  durationMinutes: Int
  xpReward: Int
}

# En dataconnect/schema/staffTraining.gql
type StaffTraining @table(name: "staff_trainings") {
  id: UUID! @default(expr: "uuidV4()")
  staffId: UUID!
  courseId: UUID!
  progressPercent: Int @default(expr: "0")
  completed: Boolean @default(expr: "false")
}

8. Documentos Requeridos (`_requiredDocs` y `_forms`)

Archivos Mock: documents_screen.dart y tax_forms_screen.dart.
Entidad Data Connect: Ninguna.
Análisis: Ambos mocks se refieren a documentos de cumplimiento. Se pueden unificar.

Recomendaciones:

Schema: Crear una única entidad StaffDocument para manejar todos los documentos.

# En dataconnect/schema/staffDocument.gql
enum DocumentType {
  GOVERNMENT_ID
  SSN
  FORM_I9
  FORM_W4
  OTHER
}
enum DocumentStatus {
  MISSING
  PENDING_UPLOAD
  PENDING_VERIFICATION
  VERIFIED
  REJECTED
}
type StaffDocument @table(name: "staff_documents") {
  id: UUID! @default(expr: "uuidV4()")
  staffId: UUID!
  documentType: DocumentType!
  status: DocumentStatus!
  fileUrl: String # URL al archivo en Cloud Storage
  notes: String # Para motivos de rechazo, etc.
}

9. Cuentas Bancarias (`_accounts`)

Archivo Mock: lib/screens/worker/worker_profile/finances/bank_account_screen.dart
Entidad Data Connect: Ninguna.
Análisis: Esta es información altamente sensible. No debe almacenarse directamente en la base de datos. Debe ser manejada por un proveedor de pagos (ej. Stripe, Adyen).
Recomendaciones:
- Schema staff.gql: Agregar un campo para almacenar el ID de cliente del proveedor de pagos, no los detalles de la cuenta.
```
type Staff @table(name: "staffs") {
  # ... campos existentes
  paymentProviderCustomerId: String # ID del cliente en Stripe/Adyen
}
```
- App: Integrar el SDK del proveedor de pagos para registrar y mostrar la información bancaria de forma segura (tokenizada).

10. Pagos Recientes (`_recentPayments` - detallado y resumido)

Archivos Mock: payments_screen.dart y earnings_screen.dart.
Entidad Data Connect: Ninguna (es una vista derivada).
Análisis: Estos mocks no representan una entidad, sino una vista de consulta sobre los Shift que han sido pagados.
Recomendaciones:
- Sin cambios en el schema, asumiendo que las recomendaciones para Shift (punto 3) se implementen.
- App: La lógica para estas pantallas debe:
  1. Consultar todos los Shift para el staffId con paymentStatus: 'PAID'.
  2. Unir la información del Event relacionado para obtener la ubicación y nombre del cliente.
  3. Para la vista de "Earnings", agrupar estos turnos por período de pago (ej. semanal) y sumar los montos.

11. Franjas Horarias (`_timeSlots` - Disponibilidad)

Archivo Mock: lib/screens/worker/availability_screen.dart
Entidad Data Connect: Ninguna.
Análisis: Define la disponibilidad preferida del trabajador.

Recomendaciones:

Schema: Crear una nueva entidad StaffAvailability. Un campo JSON por día ofrece flexibilidad.

# En dataconnect/schema/staffAvailability.gql
type StaffAvailability @table(name: "staff_availability") {
  id: UUID! @default(expr: "uuidV4()")
  staffId: UUID!
  # Usar Any (jsonb) para guardar un array de strings: ["morning", "afternoon"]
  monday: Any
  tuesday: Any
  wednesday: Any
  thursday: Any
  friday: Any
  saturday: Any
  sunday: Any
}

12. Datos de Beneficios (`_benefitsData`)

Archivo Mock: lib/screens/worker/benefits_screen.dart
Entidad Data Connect: Ninguna.
Análisis: Gestiona los beneficios acumulados como días de vacaciones o enfermedad.

Recomendaciones:

Schema: Crear entidades para definir los tipos de beneficio y el balance de cada trabajador.

# En dataconnect/schema/benefit.gql
enum BenefitType {
  SICK_DAYS
  VACATION
  OTHER
}
type StaffBenefit @table(name: "staff_benefits") {
  id: UUID! @default(expr: "uuidV4()")
  staffId: UUID!
  benefitType: BenefitType!
  currentBalance: Float! # En horas o días
  totalAllowance: Float! # Total anual/periodo
}
# Opcional: una tabla para el historial de uso
type BenefitHistory @table(name: "benefit_history") {
  id: UUID! @default(expr: "uuidV4()")
  staffBenefitId: UUID!
  amount: Float! # Horas/días usados
  date: Timestamp!
  status: String # PENDING, APPROVED
}

13. Actividad Reciente (`ActivityLog`)

Mock: No hay un mock específico, pero el concepto es universal.
Entidad Data Connect: ActivityLog (activityLog.gql)
Análisis: El schema activityLog.gql ya existe y es perfecto para registrar eventos importantes (ej. "Turno aceptado", "Perfil actualizado", "Certificado validado").
Recomendaciones:
- Backend: Implementar la lógica para que las mutaciones importantes (actualizar staff, aceptar un turno, etc.) generen una entrada en la tabla ActivityLog.
- App: Crear una pantalla de "Actividad Reciente" que consulte esta tabla para el staffId logueado, mostrando un historial de eventos.

14. Pasos de Setup y FAQs (`_steps` y `_faqData`)

Archivos Mock: profile_setup_screen.dart y faqs_screen.dart.
Análisis: Estas estructuras son puramente para la UI (navegación de un wizard) o contienen contenido estático (FAQs).
Recomendaciones:
- Sin cambios en el schema. Esta información no necesita ser gestionada a través de Data Connect. Puede permanecer como contenido estático dentro de la aplicación o, si requiere ser dinámico, ser gestionado por un CMS externo.

12 KiB Raw Blame History

Análisis Exhaustivo de Mocks de Staff App vs. Schema de Data Connect (V2)

1. Perfil de Leaderboard (_profiles)

2. Conversaciones (_conversations)

3. Hojas de Tiempo (_timesheets)

4. Certificados (_certificates)

5. Contactos de Emergencia (_contacts)

6. Opciones de Vestimenta (_attireOptions)

7. Cursos de Capacitación (_courses)

8. Documentos Requeridos (_requiredDocs y _forms)

9. Cuentas Bancarias (_accounts)

10. Pagos Recientes (_recentPayments - detallado y resumido)

11. Franjas Horarias (_timeSlots - Disponibilidad)

12. Datos de Beneficios (_benefitsData)

13. Actividad Reciente (ActivityLog)

14. Pasos de Setup y FAQs (_steps y _faqData)

12 KiB

Raw Blame History

1. Perfil de Leaderboard (`_profiles`)

2. Conversaciones (`_conversations`)

3. Hojas de Tiempo (`_timesheets`)

4. Certificados (`_certificates`)

5. Contactos de Emergencia (`_contacts`)

6. Opciones de Vestimenta (`_attireOptions`)

7. Cursos de Capacitación (`_courses`)

8. Documentos Requeridos (`_requiredDocs` y `_forms`)

9. Cuentas Bancarias (`_accounts`)

10. Pagos Recientes (`_recentPayments` - detallado y resumido)

11. Franjas Horarias (`_timeSlots` - Disponibilidad)

12. Datos de Beneficios (`_benefitsData`)

13. Actividad Reciente (`ActivityLog`)

14. Pasos de Setup y FAQs (`_steps` y `_faqData`)