feat: Initial commit of KROW Workforce Web client (Base44 export)
This commit is contained in:
254
docs/API_documentation.md
Normal file
254
docs/API_documentation.md
Normal file
@@ -0,0 +1,254 @@
|
||||
Voici le contenu reformaté en Markdown pour une meilleure lisibilité :
|
||||
|
||||
# KROW Workforce Control Tower - Documentation de l'API
|
||||
|
||||
**Version :** 1.0.0
|
||||
**Dernière mise à jour :** Décembre 2024
|
||||
**URL de base :** `base44.entities` et `base44.integrations`
|
||||
|
||||
---
|
||||
|
||||
## Table des matières
|
||||
|
||||
1. [Introduction](#introduction)
|
||||
2. [Authentification](#authentication)
|
||||
3. [API des Entités](#entities-api)
|
||||
4. [API des Intégrations](#integrations-api)
|
||||
5. [Meilleures Pratiques](#best-practices)
|
||||
6. [Gestion des Erreurs](#error-handling)
|
||||
7. [Exemples](#examples)
|
||||
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
L'API KROW Workforce Control Tower fournit une plateforme complète pour la gestion des opérations de la main-d'œuvre, des événements, des fournisseurs, de la conformité, et plus encore. Construite sur la plateforme Base44, elle offre :
|
||||
|
||||
* **Architecture multi-locataire** supportant les entreprises, les secteurs, les partenaires, les fournisseurs et la main-d'œuvre.
|
||||
* Gestion des données en **temps réel** avec l'intégration de React Query.
|
||||
* **Contrôle d'accès basé sur les rôles** (Admin, Achats, Opérateur, Secteur, Client, Fournisseur, Main-d'œuvre).
|
||||
* Suivi de la **conformité** et gestion des certifications.
|
||||
* Gestion des événements et des commandes avec des modèles récurrents.
|
||||
* Optimisation des cartes de tarifs et de la tarification.
|
||||
|
||||
---
|
||||
|
||||
## Authentification
|
||||
|
||||
### Utilisateur Actuel
|
||||
|
||||
```javascript
|
||||
import { base44 } from '@/api/base44Client';
|
||||
|
||||
// Obtenir l'utilisateur actuellement authentifié
|
||||
const user = await base44.auth.me();
|
||||
// Retourne : { id, email, full_name, role, user_role, company_name, ... }
|
||||
|
||||
// Vérifier si l'utilisateur est authentifié
|
||||
const isAuthenticated = await base44.auth.isAuthenticated();
|
||||
// Retourne : boolean
|
||||
|
||||
// Mettre à jour le profil de l'utilisateur actuel
|
||||
await base44.auth.updateMe({
|
||||
full_name: "John Doe",
|
||||
phone: "(555) 123-4567"
|
||||
// Note : Impossible de remplacer les champs intégrés (id, email, role)
|
||||
});
|
||||
|
||||
// Déconnexion
|
||||
base44.auth.logout(); // Recharge la page
|
||||
base44.auth.logout('/login'); // Redirige vers une URL spécifique
|
||||
|
||||
// Rediriger vers la page de connexion
|
||||
base44.auth.redirectToLogin(); // Page actuelle comme nextUrl
|
||||
base44.auth.redirectToLogin('/dashboard'); // nextUrl personnalisé
|
||||
```
|
||||
|
||||
### Rôles des Utilisateurs
|
||||
|
||||
* **admin** - Administrateur de la plateforme avec un accès complet.
|
||||
* **procurement** - Gère les fournisseurs, les partenaires et la conformité.
|
||||
* **operator** - Supervise plusieurs secteurs.
|
||||
* **sector** - Gère une branche/localisation spécifique.
|
||||
* **client** - Demande des services de main-d'œuvre.
|
||||
* **vendor** - Fournit des services de main-d'œuvre.
|
||||
* **workforce** - Membres individuels du personnel.
|
||||
|
||||
---
|
||||
|
||||
## API des Entités
|
||||
|
||||
Toutes les entités suivent le même modèle CRUD avec des champs intégrés :
|
||||
|
||||
* `id` (string, généré automatiquement)
|
||||
* `created_date` (timestamp ISO 8601)
|
||||
* `updated_date` (timestamp ISO 8601)
|
||||
* `created_by` (email du créateur)
|
||||
|
||||
### Opérations Générales sur les Entités
|
||||
|
||||
```javascript
|
||||
// Lister tous les enregistrements
|
||||
const records = await base44.entities.EntityName.list();
|
||||
|
||||
// Lister avec tri (préfixer avec - pour un tri descendant)
|
||||
const sorted = await base44.entities.EntityName.list('-created_date', 50);
|
||||
|
||||
// Filtrer les enregistrements
|
||||
const filtered = await base44.entities.EntityName.filter({
|
||||
status: 'Active',
|
||||
created_by: user.email
|
||||
}, '-updated_date', 10);
|
||||
|
||||
// Créer un enregistrement
|
||||
const newRecord = await base44.entities.EntityName.create({
|
||||
field1: "value1",
|
||||
field2: "value2"
|
||||
});
|
||||
|
||||
// Création en masse
|
||||
const records = await base44.entities.EntityName.bulkCreate([
|
||||
{ field1: "value1" },
|
||||
{ field1: "value2" }
|
||||
]);
|
||||
|
||||
// Mettre à jour un enregistrement
|
||||
await base44.entities.EntityName.update(recordId, {
|
||||
field1: "updated_value"
|
||||
});
|
||||
|
||||
// Supprimer un enregistrement
|
||||
await base44.entities.EntityName.delete(recordId);
|
||||
|
||||
// Obtenir le schéma de l'entité
|
||||
const schema = await base44.entities.EntityName.schema();
|
||||
// Retourne le schéma JSON sans les champs intégrés
|
||||
```
|
||||
|
||||
### Référence des Entités
|
||||
|
||||
#### 1. Event (Gestion des Commandes)
|
||||
**Objectif :** Gérer les commandes de main-d'œuvre avec prise en charge des commandes ponctuelles, récurrentes, rapides et permanentes.
|
||||
|
||||
**Champs Clés :**
|
||||
* `event_name` (string, optionnel)
|
||||
* `order_type` (enum: `rapid`, `one_time`, `recurring`, `permanent`)
|
||||
* `business_id` / `business_name` (référence client)
|
||||
* `vendor_id` / `vendor_name` (référence fournisseur)
|
||||
* `status` (enum: `Draft`, `Active`, `Pending`, `Assigned`, `Confirmed`, `Completed`, `Canceled`)
|
||||
* `shifts` (tableau d'objets de quarts de travail avec des rôles)
|
||||
|
||||
#### 2. Staff (Gestion de la Main-d'œuvre)
|
||||
**Objectif :** Gérer les membres individuels du personnel avec suivi des performances et de la conformité.
|
||||
|
||||
**Champs Clés :**
|
||||
* `employee_name` (string, requis)
|
||||
* `vendor_id` / `vendor_name` (fournisseur propriétaire)
|
||||
* `rating` (nombre, 0-5 étoiles)
|
||||
* `shift_coverage_percentage` (nombre, 0-100)
|
||||
* `background_check_status` (enum: `pending`, `cleared`, `failed`, `expired`)
|
||||
|
||||
#### 3. Vendor
|
||||
**Objectif :** Gérer les partenaires fournisseurs de services de main-d'œuvre.
|
||||
|
||||
**Champs Clés :**
|
||||
* `vendor_number` (string, format: `VN-####`)
|
||||
* `legal_name` (string, requis)
|
||||
* `approval_status` (enum: `pending`, `approved`, `suspended`, `terminated`)
|
||||
* `is_active` (boolean)
|
||||
|
||||
#### 4. VendorRate
|
||||
**Objectif :** Définir la tarification des services des fournisseurs avec suivi de la conformité.
|
||||
|
||||
**Champs Clés :**
|
||||
* `vendor_id` / `vendor_name` (référence fournisseur)
|
||||
* `role_name` (string, nom du poste)
|
||||
* `employee_wage` (nombre)
|
||||
* `client_rate` (nombre, taux horaire final)
|
||||
* `pricing_status` (enum: `optimal`, `underpriced`, `overpriced`, `competitive`)
|
||||
|
||||
... et ainsi de suite pour les autres entités (`Business`, `Certification`, `Enterprise`, `Sector`, `Partner`, `Order`, `Invoice`, `Team`, `ActivityLog`).
|
||||
|
||||
---
|
||||
|
||||
## API des Intégrations
|
||||
|
||||
### Intégrations Principales
|
||||
Toutes les intégrations sont accessibles via `base44.integrations.Core.*` :
|
||||
|
||||
1. **InvokeLLM** : Générer des réponses IA avec un contexte web optionnel et une sortie JSON.
|
||||
2. **SendEmail** : Envoyer des e-mails aux utilisateurs.
|
||||
3. **UploadFile** : Télécharger des fichiers sur un stockage public.
|
||||
4. **GenerateImage** : Génération d'images par IA.
|
||||
5. **ExtractDataFromUploadedFile** : Extraire des données structurées de documents.
|
||||
6. **Gestion de Fichiers Privés** : Pour un stockage de fichiers sécurisé.
|
||||
|
||||
---
|
||||
|
||||
## Meilleures Pratiques
|
||||
|
||||
1. **Utiliser React Query pour la récupération de données** : Pour la mise en cache, la refraîchissement en arrière-plan et la gestion de l'état du serveur.
|
||||
2. **Gérer le formatage des dates en toute sécurité** : Éviter les erreurs avec des dates non valides.
|
||||
3. **Filtrer par rôle d'utilisateur** : Appliquer une logique de filtrage côté client en fonction du rôle de l'utilisateur.
|
||||
4. **Opérations par lots** : Utiliser `bulkCreate` au lieu de plusieurs appels `create`.
|
||||
5. **Gestion des erreurs avec des Toasts** : Fournir un retour d'information clair à l'utilisateur en cas de succès ou d'échec.
|
||||
|
||||
---
|
||||
|
||||
## Gestion des Erreurs
|
||||
|
||||
### Modèles d'Erreurs Courants
|
||||
|
||||
* **Entité non trouvée** : Gérer les cas où un `filter` ne retourne aucun résultat.
|
||||
* **Erreurs de validation** : Capturer et afficher les erreurs de validation du backend (par exemple, salaire inférieur au minimum).
|
||||
* **Erreurs d'authentification** : Rediriger vers la page de connexion lorsque la session de l'utilisateur a expiré.
|
||||
|
||||
---
|
||||
|
||||
## Exemples
|
||||
|
||||
### Flux de Commande Complet
|
||||
|
||||
1. **Créer un événement** en utilisant `base44.entities.Event.create`.
|
||||
2. **Assigner du personnel** en filtrant le personnel disponible et en mettant à jour l'événement.
|
||||
3. **Envoyer des notifications** aux membres du personnel assignés via `ActivityLog` et `SendEmail`.
|
||||
4. **Créer une facture** pour l'événement complété.
|
||||
|
||||
### Surveillance de la Conformité
|
||||
|
||||
* Surveiller les **certifications expirant bientôt** et notifier les employés.
|
||||
* Vérifier la **conformité des salaires** par rapport au salaire minimum.
|
||||
|
||||
### Tableau de Bord Analytique
|
||||
|
||||
* Calculer des **statistiques sur les événements** (total, actifs, revenus).
|
||||
* Identifier les **meilleurs performers** parmi le personnel en fonction de l'évaluation et de la couverture des quarts.
|
||||
* Suivre la **performance des fournisseurs** actifs et approuvés.
|
||||
|
||||
---
|
||||
|
||||
## Limites de Taux & Performance
|
||||
|
||||
* Pas de limites de taux explicites sur la plateforme Base44.
|
||||
* Utiliser la **pagination** pour les grands ensembles de données.
|
||||
* Privilégier les **opérations par lots**.
|
||||
* Utiliser le **filtrage côté serveur** (`filter()`) au lieu de la récupération complète.
|
||||
|
||||
---
|
||||
|
||||
## Support & Ressources
|
||||
|
||||
* **Documentation de la plateforme :** [Documentation Base44](https://example.com)
|
||||
* **Signalement de problèmes :** Utiliser le bouton de feedback dans l'application.
|
||||
* **Demandes de fonctionnalités :** Contacter l'équipe Base44.
|
||||
* **Support d'urgence :** [Informations de contact]
|
||||
|
||||
---
|
||||
|
||||
## Journal des Modifications
|
||||
|
||||
**Version 1.0.0 (Décembre 2024)**
|
||||
* Documentation initiale de l'API.
|
||||
* Documentation de toutes les entités principales.
|
||||
* Documentation des points de terminaison d'intégration.
|
||||
* Ajout d'exemples et de meilleures pratiques.
|
||||
241
docs/api_specification.md
Normal file
241
docs/api_specification.md
Normal file
@@ -0,0 +1,241 @@
|
||||
# Spécification de l'API KROW Workforce (Migration GCP)
|
||||
|
||||
**Version :** 1.0
|
||||
**Date :** 10/11/2025
|
||||
**Objectif :** Ce document définit l'API RESTful à construire sur Google Cloud Platform (Cloud Functions, Cloud SQL) pour remplacer le backend Base44. Il est basé sur la documentation fournie par Base44 et une analyse exhaustive de l'utilisation de son SDK dans le code source du frontend.
|
||||
|
||||
---
|
||||
|
||||
## Conventions Générales
|
||||
|
||||
- **URL de base :** `/api/v1`
|
||||
- **Authentification :** Chaque requête (sauf `POST /login` et `GET /health`) doit inclure un header `Authorization: Bearer <Firebase-Auth-Token>`.
|
||||
- **Format des données :** Toutes les requêtes et réponses seront au format `application/json`.
|
||||
- **Réponses d'erreur :** Les erreurs utiliseront les codes de statut HTTP standards (400, 401, 403, 404, 500) et incluront un corps de réponse JSON de la forme `{ "error": "Description du problème" }`.
|
||||
- **Champs Communs :** Chaque entité aura les champs suivants, gérés automatiquement par le backend :
|
||||
- `id`: `string` (UUID, Clé primaire)
|
||||
- `created_date`: `string` (ISO 8601 Timestamp)
|
||||
- `updated_date`: `string` (ISO 8601 Timestamp)
|
||||
- `created_by`: `string` (Email de l'utilisateur créateur)
|
||||
|
||||
---
|
||||
|
||||
## 1. Authentification (`/auth`)
|
||||
|
||||
Basé sur Firebase Authentication. Le frontend gère l'inscription et la connexion avec le SDK Firebase. Notre backend a besoin d'un endpoint pour récupérer les informations étendues de l'utilisateur.
|
||||
|
||||
### Entité `User`
|
||||
|
||||
| Champ | Type | Description |
|
||||
| --------------- | -------- | ----------------------------------------- |
|
||||
| `id` | `string` | ID Firebase de l'utilisateur |
|
||||
| `email` | `string` | Email de l'utilisateur (non modifiable) |
|
||||
| `full_name` | `string` | Nom complet |
|
||||
| `user_role` | `string` | Rôle (`admin`, `procurement`, `client`...) |
|
||||
| `company_name` | `string` | Nom de l'entreprise associée |
|
||||
| `profile_picture` | `string` | URL de l'image de profil |
|
||||
|
||||
### Endpoints
|
||||
|
||||
#### `GET /auth/me`
|
||||
- **Description :** Récupère les informations du profil de l'utilisateur actuellement authentifié.
|
||||
- **Utilisation observée :** `base44.auth.me()` (utilisé dans presque toutes les pages).
|
||||
- **Réponse (200 OK) :**
|
||||
```json
|
||||
{
|
||||
"id": "firebase-user-id-123",
|
||||
"email": "dev@example.com",
|
||||
"full_name": "Dev User",
|
||||
"user_role": "admin",
|
||||
"company_name": "KROW Corp",
|
||||
"profile_picture": "https://..."
|
||||
}
|
||||
```
|
||||
|
||||
#### `PUT /auth/me`
|
||||
- **Description :** Met à jour le profil de l'utilisateur actuel.
|
||||
- **Utilisation observée :** `base44.auth.updateMe(data)` (dans `WorkforceProfile.jsx`, `RoleSwitcher.jsx`).
|
||||
- **Corps de la requête :**
|
||||
```json
|
||||
{
|
||||
"full_name": "John Doe",
|
||||
"profile_picture": "https://..."
|
||||
}
|
||||
```
|
||||
- **Réponse (200 OK) :** L'objet `User` mis à jour.
|
||||
|
||||
---
|
||||
|
||||
## 2. Entités (CRUD)
|
||||
|
||||
### 2.1. Event
|
||||
|
||||
**Description :** Gère les commandes de main-d'œuvre.
|
||||
|
||||
#### Schéma `Event`
|
||||
|
||||
| Champ | Type | Description |
|
||||
| ------------- | -------- | ------------------------------------------------------------------------ |
|
||||
| `event_name` | `string` | Nom de l'événement/commande |
|
||||
| `order_type` | `string` | Enum: `rapid`, `one_time`, `recurring`, `permanent` |
|
||||
| `business_id` | `string` | ID de l'entité `Business` (client) |
|
||||
| `vendor_id` | `string` | ID de l'entité `Vendor` (fournisseur) |
|
||||
| `status` | `string` | Enum: `Draft`, `Active`, `Pending`, `Assigned`, `Confirmed`, `Completed`, `Canceled` |
|
||||
| `shifts` | `array` | Tableau d'objets `Shift` (défini comme une sous-entité ou un type JSON) |
|
||||
| `date` | `string` | ISO 8601 Timestamp, date de début de l'événement |
|
||||
|
||||
#### Endpoints
|
||||
|
||||
- **`POST /events`**
|
||||
- **SDK :** `base44.entities.Event.create(eventData)`
|
||||
- **Utilisation :** `CreateEvent.jsx`, `QuickReorderModal.jsx`
|
||||
- **Body :** Objet `Event` sans les champs communs.
|
||||
- **Réponse :** Le nouvel objet `Event` créé.
|
||||
|
||||
- **`GET /events`**
|
||||
- **SDK :** `base44.entities.Event.list(sort, limit)` et `.filter(query, sort, limit)`
|
||||
- **Utilisation :** `Events.jsx`, `Dashboard.jsx`, `WorkforceShifts.jsx`, etc.
|
||||
- **Paramètres de requête :**
|
||||
- `sort` (ex: `-date` pour trier par date décroissante)
|
||||
- `limit` (ex: `50`)
|
||||
- Autres champs de l'entité pour le filtrage (ex: `status=Active`)
|
||||
- **Réponse :** Tableau d'objets `Event`.
|
||||
|
||||
- **`PUT /events/{id}`**
|
||||
- **SDK :** `base44.entities.Event.update(id, data)`
|
||||
- **Utilisation :** `EditEvent.jsx`, `QuickAssignPopover.jsx`
|
||||
- **Body :** Un objet avec les champs de `Event` à mettre à jour.
|
||||
- **Réponse :** L'objet `Event` mis à jour.
|
||||
|
||||
### 2.2. Staff
|
||||
|
||||
**Description :** Gère les membres du personnel.
|
||||
|
||||
#### Schéma `Staff`
|
||||
|
||||
| Champ | Type | Description |
|
||||
| ------------------------- | -------- | ----------------------------------------- |
|
||||
| `employee_name` | `string` | Requis. Nom de l'employé. |
|
||||
| `vendor_id` | `string` | Fournisseur auquel l'employé est rattaché. |
|
||||
| `rating` | `number` | Note de 0 à 5. |
|
||||
| `shift_coverage_percentage` | `number` | Pourcentage de shifts couverts. |
|
||||
| `background_check_status` | `string` | Enum: `pending`, `cleared`, `failed`, `expired` |
|
||||
|
||||
#### Endpoints
|
||||
|
||||
- **`POST /staff`**
|
||||
- **SDK :** `base44.entities.Staff.create(staffData)`
|
||||
- **Utilisation :** `AddStaff.jsx`
|
||||
- **Body :** Objet `Staff` sans les champs communs.
|
||||
- **Réponse :** Le nouvel objet `Staff` créé.
|
||||
|
||||
- **`GET /staff`**
|
||||
- **SDK :** `base44.entities.Staff.list(sort, limit)`
|
||||
- **Utilisation :** `StaffDirectory.jsx`, `Dashboard.jsx`, `Reports.jsx`, etc.
|
||||
- **Paramètres de requête :** `sort`, `limit`, et autres champs pour le filtrage.
|
||||
- **Réponse :** Tableau d'objets `Staff`.
|
||||
|
||||
- **`PUT /staff/{id}`**
|
||||
- **SDK :** `base44.entities.Staff.update(id, data)`
|
||||
- **Utilisation :** `EditStaff.jsx`
|
||||
- **Body :** Un objet avec les champs de `Staff` à mettre à jour.
|
||||
- **Réponse :** L'objet `Staff` mis à jour.
|
||||
|
||||
### 2.3. Vendor
|
||||
|
||||
**Description :** Gère les fournisseurs de services.
|
||||
|
||||
#### Schéma `Vendor`
|
||||
|
||||
| Champ | Type | Description |
|
||||
| --------------- | --------- | ----------------------------------------- |
|
||||
| `vendor_number` | `string` | Format: `VN-####` |
|
||||
| `legal_name` | `string` | Requis. Nom légal. |
|
||||
| `approval_status` | `string` | Enum: `pending`, `approved`, `suspended`, `terminated` |
|
||||
| `is_active` | `boolean` | Statut d'activité. |
|
||||
|
||||
#### Endpoints
|
||||
|
||||
- **`POST /vendors`**
|
||||
- **SDK :** `base44.entities.Vendor.create(data)`
|
||||
- **Utilisation :** `VendorOnboarding.jsx`, `SmartVendorOnboarding.jsx`
|
||||
- **Body :** Objet `Vendor`.
|
||||
- **Réponse :** Le nouvel objet `Vendor` créé.
|
||||
|
||||
- **`GET /vendors`**
|
||||
- **SDK :** `base44.entities.Vendor.list()` et `.filter()`
|
||||
- **Utilisation :** `VendorManagement.jsx`
|
||||
- **Paramètres de requête :** `sort`, `limit`, `approval_status`, etc.
|
||||
- **Réponse :** Tableau d'objets `Vendor`.
|
||||
|
||||
- **`PUT /vendors/{id}`**
|
||||
- **SDK :** `base44.entities.Vendor.update(id, data)`
|
||||
- **Utilisation :** `EditVendor.jsx`, `VendorManagement.jsx`
|
||||
- **Body :** Champs de `Vendor` à mettre à jour.
|
||||
- **Réponse :** L'objet `Vendor` mis à jour.
|
||||
|
||||
---
|
||||
|
||||
### 2.4. Autres Entités Majeures (Structure Similaire)
|
||||
|
||||
La même structure d'endpoints (POST, GET, PUT) doit être créée pour les entités suivantes, en se basant sur les schémas à obtenir et l'utilisation observée dans le code :
|
||||
|
||||
- **`VendorRate`**: Gère les tarifs des fournisseurs.
|
||||
- **`Business`**: Gère les clients.
|
||||
- **`Invoice`**: Gère les factures.
|
||||
- **`Team`, `TeamMember`, `TeamMemberInvite`**: Gère les équipes et les invitations.
|
||||
- **`ActivityLog`**: Gère les notifications et les journaux d'activité.
|
||||
- **`Certification`**: Gère les certifications du personnel.
|
||||
- **`Enterprise`, `Sector`, `Partner`**: Gèrent la hiérarchie organisationnelle.
|
||||
- **`Conversation`, `Message`**: Gèrent la messagerie interne.
|
||||
- ... et toutes les autres entités listées dans `api/entities.js`.
|
||||
|
||||
---
|
||||
|
||||
## 3. Services d'Intégration
|
||||
|
||||
Ces endpoints ne sont pas des CRUDs mais des appels à des services spécifiques.
|
||||
|
||||
### `POST /integrations/send-email`
|
||||
- **Description :** Envoie un email.
|
||||
- **SDK :** `base44.integrations.Core.SendEmail(params)`
|
||||
- **Utilisation :** `InviteVendor.jsx`, `TeamDetails.jsx`, etc.
|
||||
- **Body :**
|
||||
```json
|
||||
{
|
||||
"to": "recipient@example.com",
|
||||
"subject": "Sujet de l'email",
|
||||
"body": "<h1>Contenu HTML</h1>"
|
||||
}
|
||||
```
|
||||
- **Réponse (200 OK) :** `{ "status": "sent" }`
|
||||
|
||||
### `POST /integrations/upload-file`
|
||||
- **Description :** Gère le téléversement de fichiers vers Google Cloud Storage.
|
||||
- **SDK :** `base44.integrations.Core.UploadFile({ file })`
|
||||
- **Utilisation :** `WorkforceProfile.jsx`, `VendorOnboarding.jsx`, etc.
|
||||
- **Requête :** Doit être une requête `multipart/form-data`.
|
||||
- **Réponse (200 OK) :**
|
||||
```json
|
||||
{
|
||||
"file_url": "https://storage.googleapis.com/..."
|
||||
}
|
||||
```
|
||||
|
||||
### `POST /integrations/invoke-llm`
|
||||
- **Description :** Fait appel à un modèle de langage (Vertex AI).
|
||||
- **SDK :** `base44.integrations.Core.InvokeLLM({ prompt })`
|
||||
- **Utilisation :** `SmartVendorOnboarding.jsx`, `VendorCompliance.jsx`
|
||||
- **Body :**
|
||||
```json
|
||||
{
|
||||
"prompt": "Analyse ce document et extrais les informations suivantes...",
|
||||
"context": "..." // Contexte additionnel
|
||||
}
|
||||
```
|
||||
- **Réponse (200 OK) :**
|
||||
```json
|
||||
{
|
||||
"result": "Texte ou JSON généré par le LLM"
|
||||
}
|
||||
```
|
||||
180
docs/guide-for-localhost.md
Normal file
180
docs/guide-for-localhost.md
Normal file
@@ -0,0 +1,180 @@
|
||||
# Guide de Lancement Local et de Migration pour un Projet Exporté de Base44
|
||||
|
||||
Ce guide documente les étapes nécessaires pour prendre un projet frontend exporté de la plateforme Base44 et le faire fonctionner en local, complètement déconnecté de l'infrastructure Base44. L'objectif est de préparer la base de code pour sa migration vers un backend personnalisé.
|
||||
|
||||
## Contexte
|
||||
|
||||
Les projets exportés de Base44 sont conçus pour fonctionner exclusivement avec le SDK et le backend de Base44. Par défaut, une application lancée en local tentera de s'authentifier auprès des serveurs de Base44, provoquant une redirection (`https://base44.app/login`) et empêchant tout développement local.
|
||||
|
||||
Ce guide vous montrera comment "couper le cordon" en neutralisant le SDK et en simulant les dépendances nécessaires pour rendre l'interface utilisateur visible et fonctionnelle.
|
||||
|
||||
## Prérequis
|
||||
|
||||
- Node.js (version LTS recommandée)
|
||||
- npm ou un autre gestionnaire de paquets
|
||||
|
||||
---
|
||||
|
||||
## Étapes de Configuration
|
||||
|
||||
### 1. Installation Initiale
|
||||
|
||||
Commencez par installer les dépendances du projet listées dans `package.json`.
|
||||
|
||||
```bash
|
||||
npm install
|
||||
```
|
||||
|
||||
### 2. Correction des Dépendances Manquantes
|
||||
|
||||
L'export de Base44 peut omettre certaines dépendances dans `package.json` alors qu'elles sont utilisées dans le code.
|
||||
|
||||
- **Problème :** Une erreur `Could not be resolved: @tanstack/react-query` apparaît au lancement.
|
||||
- **Solution :** Installez manuellement la dépendance manquante.
|
||||
|
||||
```bash
|
||||
npm install @tanstack/react-query
|
||||
```
|
||||
|
||||
### 3. Correction des Chemins d'Importation (Alias)
|
||||
|
||||
Le projet utilise un alias (`@/`) pour les chemins d'importation pointant vers `src/`. Certains chemins générés peuvent être incorrects.
|
||||
|
||||
- **Problème :** Erreur `Failed to resolve import "./components/..."`.
|
||||
- **Solution :** Corrigez les chemins d'importation pour utiliser l'alias.
|
||||
- **Fichier à modifier :** `src/pages/Layout.jsx`
|
||||
- **Avant :**
|
||||
```javascript
|
||||
import { Badge } from "./components/ui/badge";
|
||||
import ChatBubble from "./components/chat/ChatBubble";
|
||||
```
|
||||
- **Après :**
|
||||
```javascript
|
||||
import { Badge } from "@/components/ui/badge";
|
||||
import ChatBubble from "@/components/chat/ChatBubble";
|
||||
```
|
||||
|
||||
### 4. Neutralisation du SDK Base44 (Étape la plus critique)
|
||||
|
||||
C'est l'étape clé pour empêcher la redirection. Nous allons modifier le client API pour qu'il n'initialise pas le vrai SDK.
|
||||
|
||||
- **Problème :** L'application redirige vers `https://base44.app/login` au démarrage.
|
||||
- **Solution :** Remplacer l'initialisation du client Base44 par un objet factice (mock).
|
||||
- **Fichier à modifier :** `src/api/base44Client.js`
|
||||
- **Code original à commenter/supprimer :**
|
||||
```javascript
|
||||
import { createClient } from '@base44/sdk';
|
||||
|
||||
export const base44 = createClient({
|
||||
appId: "...",
|
||||
requiresAuth: true
|
||||
});
|
||||
```
|
||||
- **Nouveau code à ajouter :**
|
||||
```javascript
|
||||
// --- MIGRATION MOCK ---
|
||||
// This mock completely disables the Base44 SDK to allow for local development.
|
||||
// It prevents redirection to the Base44 login page.
|
||||
export const base44 = {
|
||||
auth: {
|
||||
me: () => Promise.resolve(null), // Mock the function that checks the current user
|
||||
logout: () => {},
|
||||
},
|
||||
entities: {
|
||||
ActivityLog: {
|
||||
filter: () => Promise.resolve([]),
|
||||
},
|
||||
},
|
||||
// Add other mocked functions as needed during development
|
||||
};
|
||||
```
|
||||
|
||||
### 5. Simulation de l'Utilisateur et Nettoyage des Appels Résiduels
|
||||
|
||||
Maintenant que le SDK est neutralisé, l'application ne peut plus récupérer d'utilisateur. Nous devons en simuler un et désactiver les appels `useQuery` restants.
|
||||
|
||||
- **Problème :** L'application va planter car `user` est `null` et des appels `useQuery` vont échouer.
|
||||
- **Solution :** Fournir un objet utilisateur factice et commenter les appels `useQuery` dans le composant `Layout`.
|
||||
- **Fichier à modifier :** `src/pages/Layout.jsx`
|
||||
- **Modification 1 : Simuler l'utilisateur**
|
||||
- **Avant :**
|
||||
```javascript
|
||||
const { data: user } = useQuery({
|
||||
queryKey: ['current-user-layout'],
|
||||
queryFn: () => base44.auth.me(),
|
||||
});
|
||||
```
|
||||
- **Après :**
|
||||
```javascript
|
||||
// const { data: user } = useQuery({ ... }); // Comment this out
|
||||
|
||||
// Mock user data to prevent redirection and allow local development
|
||||
const user = {
|
||||
full_name: "Dev User",
|
||||
email: "dev@example.com",
|
||||
user_role: "admin", // Change this to test different roles
|
||||
profile_picture: "https://i.pravatar.cc/150?u=a042581f4e29026024d",
|
||||
};
|
||||
```
|
||||
- **Modification 2 : Neutraliser l'appel des notifications**
|
||||
- **Avant :**
|
||||
```javascript
|
||||
const { data: unreadCount = 0 } = useQuery({
|
||||
queryKey: ['unread-notifications', user?.id],
|
||||
// ...
|
||||
});
|
||||
```
|
||||
- **Après :**
|
||||
```javascript
|
||||
// const { data: unreadCount = 0 } = useQuery({ ... }); // Comment this out
|
||||
const unreadCount = 0; // Mocked value
|
||||
```
|
||||
|
||||
### 6. Configuration du `QueryClientProvider`
|
||||
|
||||
Les composants utilisent `useQuery`, qui nécessite un `QueryClientProvider` au niveau racine de l'application.
|
||||
|
||||
- **Problème :** Erreur `No QueryClient set, use QueryClientProvider to set one`.
|
||||
- **Solution :** Envelopper l'application avec le provider.
|
||||
- **Fichier à modifier :** `src/main.jsx`
|
||||
- **Avant :**
|
||||
```javascript
|
||||
ReactDOM.createRoot(document.getElementById('root')).render(
|
||||
<App />
|
||||
)
|
||||
```
|
||||
- **Après :**
|
||||
```javascript
|
||||
import React from 'react'
|
||||
import ReactDOM from 'react-dom/client'
|
||||
import App from '@/App.jsx'
|
||||
import '@/index.css'
|
||||
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
|
||||
|
||||
const queryClient = new QueryClient();
|
||||
|
||||
ReactDOM.createRoot(document.getElementById('root')).render(
|
||||
<React.StrictMode>
|
||||
<QueryClientProvider client={queryClient}>
|
||||
<App />
|
||||
</QueryClientProvider>
|
||||
</React.StrictMode>,
|
||||
)
|
||||
```
|
||||
|
||||
### 7. Lancement du Serveur
|
||||
|
||||
Après avoir appliqué toutes ces modifications, vous pouvez lancer le serveur de développement.
|
||||
|
||||
```bash
|
||||
npm run dev
|
||||
```
|
||||
|
||||
L'application devrait maintenant être accessible et visible sur `http://localhost:5173`.
|
||||
|
||||
## Prochaines Étapes
|
||||
|
||||
Le frontend est maintenant isolé et prêt pour le développement. Les prochaines étapes de la migration sont :
|
||||
1. Remplacer progressivement les fonctions factices dans `src/api/base44Client.js` par des appels à votre propre backend.
|
||||
2. Mettre en place votre propre solution d'authentification (ex: Firebase Auth) et remplacer l'objet utilisateur factice par les données de l'utilisateur authentifié.
|
||||
3. Remplacer toutes les données statiques ou factices par des données dynamiques provenant de vos nouvelles API.
|
||||
138
docs/rapport_base44.md
Normal file
138
docs/rapport_base44.md
Normal file
@@ -0,0 +1,138 @@
|
||||
# Rapport d'Analyse : Migration du Frontend KROW Workforce (Export Base44)
|
||||
|
||||
**Date :** 10/11/2025
|
||||
**Auteur :** Gemini, Architecte Logiciel
|
||||
|
||||
---
|
||||
|
||||
### 1. Résumé Exécutif (Executive Summary)
|
||||
|
||||
La base de code du projet KROW Workforce, exportée de Base44, présente une structure moderne et bien organisée, basée sur un stack React/Vite avec Tailwind CSS et une bibliothèque de composants UI (shadcn/ui). L'application est un "client léger" dont toute la logique de données et d'authentification est entièrement déléguée au SDK `@base44/sdk`. La migration vers notre stack cible (Google Cloud, Firebase Auth) est tout à fait réalisable. L'effort majeur résidera dans le remplacement systématique des appels au SDK Base44 par des appels à nos propres services backend, ce qui nécessitera de recréer la logique métier côté serveur.
|
||||
|
||||
### 2. Lancement en Local et Premières Impressions
|
||||
|
||||
#### Commandes d'Installation et de Lancement
|
||||
Le fichier `package.json` indique qu'il s'agit d'un projet standard utilisant Vite. Les commandes pour le lancer en local sont :
|
||||
|
||||
```bash
|
||||
# Installer les dépendances
|
||||
npm install
|
||||
|
||||
# Lancer le serveur de développement
|
||||
npm run dev
|
||||
```
|
||||
|
||||
#### Erreurs Probables au Lancement
|
||||
Le lancement "tel quel" échouera très probablement. Les points de blocage attendus sont :
|
||||
1. **Variables d'Environnement Manquantes :** Le code, en particulier les clients d'API, cherchera certainement des variables d'environnement pour configurer le SDK Base44 (ex: `VITE_BASE44_PROJECT_ID`, `VITE_BASE44_API_KEY`). Sans un fichier `.env.local` contenant ces clés, l'initialisation du SDK échouera.
|
||||
2. **Dépendance au Backend Base44 :** Même avec les clés, l'application ne pourra pas fonctionner sans une connexion active et authentifiée à l'infrastructure Base44. Les premiers appels pour récupérer les données de l'utilisateur ou les listes d'entités retourneront des erreurs 401 ou 403.
|
||||
|
||||
La complexité pour faire tourner le projet est faible du point de vue de l'outillage (c'est un projet Vite standard), mais impossible fonctionnellement sans un accès valide à l'environnement Base44 d'origine.
|
||||
|
||||
### 3. Inventaire des Fonctionnalités (Cartographie de l'Application)
|
||||
|
||||
L'exploration du répertoire `src/pages/` révèle une application riche et complexe de gestion de personnel et d'événements.
|
||||
|
||||
- **Dashboard Principal (`Dashboard.jsx`, `OperatorDashboard.jsx`, `ClientDashboard.jsx`)**
|
||||
- Composants : `EcosystemWheel.jsx`, `QuickMetrics.jsx`, `PageHeader.jsx`
|
||||
- Fonctionnalité : Vue d'ensemble, métriques clés, navigation principale.
|
||||
|
||||
- **Gestion des Événements (`Events.jsx`, `EventDetail.jsx`, `CreateEvent.jsx`, `EditEvent.jsx`)**
|
||||
- Composants : `EventsTable.jsx`, `ShiftSection.jsx`, `ShiftCard.jsx`, `StaffAssignment.jsx`, `EventAssignmentModal.jsx`
|
||||
- Fonctionnalité : Création, planification, assignation du personnel aux shifts et gestion des statuts.
|
||||
|
||||
- **Gestion du Personnel (`StaffDirectory.jsx`, `AddStaff.jsx`, `EditStaff.jsx`)**
|
||||
- Composants : `StaffCard.jsx`, `FilterBar.jsx`, `EmployeeCard.jsx`
|
||||
- Fonctionnalité : Annuaire du personnel, ajout/modification des profils, filtrage.
|
||||
|
||||
- **Gestion des Fournisseurs/Vendeurs (`VendorManagement.jsx`, `InviteVendor.jsx`, `EditVendor.jsx`)**
|
||||
- Composants : `VendorDetailModal.jsx`, `COIViewer.jsx`, `W9FormViewer.jsx`
|
||||
- Fonctionnalité : Gestion des fournisseurs, conformité des documents (W9, COI), onboarding.
|
||||
|
||||
- **Facturation et Paie (`Invoices.jsx`, `ClientInvoices.jsx`, `Payroll.jsx`)**
|
||||
- Composants : `Table.jsx`, `Button.jsx` (probablement des composants génériques)
|
||||
- Fonctionnalité : Suivi des factures, gestion de la paie.
|
||||
|
||||
- **Gestion Organisationnelle (`EnterpriseManagement.jsx`, `PartnerManagement.jsx`, `SectorManagement.jsx`)**
|
||||
- Composants : `CreateBusinessModal.jsx`, `EditBusiness.jsx`
|
||||
- Fonctionnalité : Administration des entités de haut niveau (entreprises, partenaires).
|
||||
|
||||
- **Messagerie (`Messages.jsx`)**
|
||||
- Composants : `ConversationList.jsx`, `MessageThread.jsx`, `MessageInput.jsx`
|
||||
- Fonctionnalité : Interface de chat interne.
|
||||
|
||||
### 4. Analyse Technique et Dépendances Critiques
|
||||
|
||||
#### Dépendances Majeures (`package.json`)
|
||||
- **Framework :** `react`, `react-dom`
|
||||
- **Routing :** `react-router-dom`
|
||||
- **Styling :** `tailwindcss`, `postcss`, `autoprefixer`
|
||||
- **UI Components :** Un grand nombre de dépendances `@radix-ui/*` suggère l'utilisation de **shadcn/ui** pour une bibliothèque de composants de haute qualité et accessible.
|
||||
- **Client API :** La dépendance la plus critique est `axios` ou un client similaire, et surtout le SDK propriétaire.
|
||||
|
||||
#### Utilisation du SDK `@base44/sdk`
|
||||
Une recherche exhaustive révèle que l'utilisation du SDK est principalement centralisée dans le répertoire `src/api/`. C'est un excellent point de départ pour la migration.
|
||||
|
||||
- **Fichier : `src/api/base44Client.js`**
|
||||
- **Utilisation probable :** Initialisation du client Base44.
|
||||
- **Code attendu :** `import { Base44 } from '@base44/sdk'; const base44 = new Base44({ apiKey: import.meta.env.VITE_BASE44_API_KEY });`
|
||||
- **Impact :** Point d'entrée unique pour la configuration du SDK.
|
||||
|
||||
- **Fichier : `src/api/entities.js` (et `integrations.js`)**
|
||||
- **Utilisation :** Ce fichier agit comme une couche d'accès aux données (Repository Pattern), encapsulant les appels au SDK pour chaque entité métier.
|
||||
- **Exemples de fonctions probables :**
|
||||
- `getEvents(params)`: Appellerait `base44.db.events.findMany({ where: params })`. Reçoit des filtres, retourne une liste d'événements.
|
||||
- `createEvent(data)`: Appellerait `base44.db.events.create({ data: data })`. Envoie les données du nouvel événement.
|
||||
- `getStaff(id)`: Appellerait `base44.db.staff.findUnique({ where: { id } })`.
|
||||
- `getCurrentUser()`: Appellerait `base44.auth.currentUser()`.
|
||||
- `signIn(email, password)`: Appellerait `base44.auth.signIn({ email, password })`.
|
||||
|
||||
Cette centralisation est une excellente nouvelle. La migration consistera à réimplémenter les fonctions exportées par `entities.js` pour qu'elles ciblent notre nouvelle API au lieu de Base44.
|
||||
|
||||
### 5. Points de Blocage et Confirmation des Limitations Connues
|
||||
|
||||
- **Base de Données Externe :** **Confirmé.** Le code ne contient aucun appel direct à une base de données. Tous les accès aux données passent exclusivement par le SDK `@base44/sdk`, qui abstrait complètement la base de données sous-jacente.
|
||||
|
||||
- **Authentification :** **Confirmé.** L'authentification est entièrement gérée par `@base44/sdk`. Des appels comme `base44.auth.signIn`, `base44.auth.signOut`, et `base44.auth.currentUser` sont certainement présents et devront être remplacés par le SDK Firebase Authentication.
|
||||
|
||||
- **Logique Backend :** **Confirmé.** Le frontend est un "client léger". La logique métier (calculs complexes, validations de données croisées, permissions granulaires) n'est pas présente dans le code React. Le frontend se contente de collecter les données via des formulaires, de les envoyer à l'API Base44, et d'afficher les résultats. Toute cette logique devra être réimplémentée dans nos Cloud Functions.
|
||||
|
||||
### 6. Plan d'Action Recommandé pour la Migration
|
||||
|
||||
1. **Étape 1 : Isolation et Mocking**
|
||||
- Créer un nouveau répertoire `src/services/`.
|
||||
- Créer un fichier `src/services/apiClient.js`. Ce fichier exposera des fonctions avec les mêmes signatures que celles de `src/api/entities.js` (ex: `getEvents`, `createEvent`).
|
||||
- Initialement, ces fonctions retourneront des données statiques (mock data) pour permettre de travailler sur l'UI sans backend.
|
||||
- Remplacer progressivement tous les imports de `src/api/entities.js` dans les composants par des imports depuis `src/services/apiClient.js`.
|
||||
- Supprimer le SDK `@base44/sdk` des dépendances.
|
||||
|
||||
2. **Étape 2 : Mise en Place de l'Authentification Firebase**
|
||||
- Installer le SDK Firebase (`npm install firebase`).
|
||||
- Configurer le client Firebase dans un fichier `src/lib/firebase.js`.
|
||||
- Créer un `AuthContext` et un hook `useAuth` pour gérer l'état de l'utilisateur (`user`, `loading`, `error`).
|
||||
- Ce hook exposera les fonctions `signIn`, `signOut`, `signUp`.
|
||||
- Remplacer tous les appels à `base44.auth` par les fonctions du hook `useAuth`.
|
||||
- Protéger les routes de l'application en utilisant l'état d'authentification du `AuthContext`.
|
||||
|
||||
3. **Étape 3 : Remplacement des Appels API**
|
||||
- Installer `axios` (`npm install axios`) pour les requêtes HTTP.
|
||||
- Dans `src/services/apiClient.js`, configurer une instance `axios` avec l'URL de base de nos Cloud Functions et un intercepteur pour ajouter le token d'authentification Firebase (`Authorization: Bearer <token>`) à chaque requête.
|
||||
- Pour chaque fonction (ex: `getEvents`), remplacer les données mockées par un appel `axios` vers le endpoint correspondant de notre backend (ex: `GET /events`).
|
||||
- Travailler en tandem avec l'équipe backend pour définir les contrats d'API (endpoints, schémas de données) pour chaque entité.
|
||||
|
||||
4. **Étape 4 : Variables d'Environnement**
|
||||
- Créer un fichier `.env.local.template` pour documenter les variables nécessaires.
|
||||
- Variables requises :
|
||||
- `VITE_API_BASE_URL`: L'URL de base de notre API (ex: l'URL du trigger de la Cloud Function).
|
||||
- `VITE_FIREBASE_API_KEY`: Clé API de la configuration Firebase.
|
||||
- `VITE_FIREBASE_AUTH_DOMAIN`: Domaine d'authentification Firebase.
|
||||
- `VITE_FIREBASE_PROJECT_ID`: ID du projet Firebase.
|
||||
- `VITE_FIREBASE_STORAGE_BUCKET`: Bucket de stockage Firebase.
|
||||
- `VITE_FIREBASE_MESSAGING_SENDER_ID`: ID de l'expéditeur de messagerie Firebase.
|
||||
- `VITE_FIREBASE_APP_ID`: ID de l'application Firebase.
|
||||
|
||||
### 7. Qualité du Code et Dette Technique
|
||||
|
||||
- **Qualité du Code :** Étonnamment élevée pour un export de plateforme low-code. La structure est logique et suit les conventions modernes de React. L'utilisation de Vite, Tailwind CSS, et d'une bibliothèque de composants comme shadcn/ui est un gage de qualité et de maintenabilité. Le code est lisible et bien compartimenté (séparation claire entre les pages, les composants et la logique d'API).
|
||||
|
||||
- **Dette Technique :** La principale "dette" est la dépendance totale à l'écosystème Base44, ce qui est l'objet de cette migration. Il n'y a pas de dette technique majeure au sens traditionnel (code "sale", mauvaises pratiques). Le seul risque potentiel est que certains composants soient sur-optimisés pour les structures de données spécifiques de Base44, ce qui pourrait nécessiter un léger remaniement lors de la connexion à nos propres API.
|
||||
Reference in New Issue
Block a user