feat: Initialize monorepo structure and comprehensive documentation
This commit establishes the new monorepo architecture for the KROW Workforce platform. Key changes include: - Reorganized project into `frontend-web`, `mobile-apps`, `firebase`, `scripts`, and `secrets` directories. - Updated `Makefile` to support the new monorepo layout and automate Base44 export integration. - Fixed `scripts/prepare-export.js` for ES module compatibility and global component import resolution. - Created and updated `CONTRIBUTING.md` for developer onboarding. - Restructured, renamed, and translated all `docs/` files for clarity and consistency. - Implemented an interactive internal launchpad with diagram viewing capabilities. - Configured base Firebase project files (`firebase.json`, security rules). - Updated `README.md` to reflect the new project structure and documentation overview.
This commit is contained in:
bwnyasse
119
.gitignore
vendored
119
.gitignore
vendored
@@ -1,41 +1,80 @@
|
||||
# Dependencies
|
||||
/node_modules
|
||||
/.pnp
|
||||
.pnp.js
|
||||
|
||||
# Testing
|
||||
/coverage
|
||||
|
||||
# Vite
|
||||
.vite/
|
||||
.temp/
|
||||
|
||||
# Local Secrets
|
||||
.env
|
||||
.env.local
|
||||
.env.*.local
|
||||
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
lerna-debug.log*
|
||||
|
||||
# Build output
|
||||
dist
|
||||
dist-ssr
|
||||
*.local
|
||||
|
||||
# Editor directories and files
|
||||
.vscode/*
|
||||
!.vscode/extensions.json
|
||||
.idea
|
||||
# General
|
||||
# ----------------------------------------------------------------
|
||||
# macOS generated files
|
||||
.DS_Store
|
||||
*.suo
|
||||
*.ntvs*
|
||||
*.njsproj
|
||||
*.sln
|
||||
*.sw?
|
||||
.AppleDouble
|
||||
.LSOverride
|
||||
|
||||
# IDE configuration files
|
||||
.idea/
|
||||
.vscode/
|
||||
*.iml
|
||||
*.iws
|
||||
|
||||
# Log and cache files
|
||||
*.log
|
||||
*.cache
|
||||
*.pyc
|
||||
__pycache__/
|
||||
|
||||
# Secrets (never commit these)
|
||||
# The secrets/ directory is handled by its own .gitignore, but this is an extra layer of safety.
|
||||
secrets/
|
||||
*.env
|
||||
.env.*
|
||||
!.env.example
|
||||
|
||||
# OS-specific files
|
||||
Thumbs.db
|
||||
ehthumbs.db
|
||||
|
||||
|
||||
# Frontend Web (Vite / React)
|
||||
# ----------------------------------------------------------------
|
||||
frontend-web/node_modules/
|
||||
frontend-web/dist/
|
||||
frontend-web/.env.local
|
||||
frontend-web/coverage/
|
||||
frontend-web/.vite/
|
||||
|
||||
|
||||
# Mobile (Flutter)
|
||||
# ----------------------------------------------------------------
|
||||
mobile-apps/*/.dart_tool/
|
||||
mobile-apps/*/.pub-cache/
|
||||
mobile-apps/*/build/
|
||||
mobile-apps/*/.flutter-plugins
|
||||
mobile-apps/*/.flutter-plugins-dependencies
|
||||
|
||||
|
||||
# Firebase / Backend
|
||||
# ----------------------------------------------------------------
|
||||
# Python virtual environments
|
||||
firebase/functions/venv/
|
||||
firebase/dataconnect/venv/
|
||||
|
||||
# Firebase emulator logs
|
||||
*.log
|
||||
firebase-debug.log
|
||||
firebase-debug.*.log
|
||||
firestore-debug.log
|
||||
ui-debug.log
|
||||
|
||||
# Generated SDKs (can be regenerated, so often ignored)
|
||||
# Decide with your team if you want to commit these or not.
|
||||
# For now, we will commit them to simplify setup for new developers.
|
||||
# @dataconnect/
|
||||
|
||||
|
||||
# Temporary files from this project
|
||||
# ----------------------------------------------------------------
|
||||
# The Base44 export directory should not be committed
|
||||
/krow-workforce-export-latest/
|
||||
|
||||
# The legacy Laravel project should not be committed
|
||||
/legacy-web/
|
||||
|
||||
# The temporary mobile app folders should not be committed
|
||||
/flutter-mobile-client-app/
|
||||
/flutter-mobile-staff-app/
|
||||
/inspiration/
|
||||
|
||||
8
.vite/deps/_metadata.json
Normal file
8
.vite/deps/_metadata.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"hash": "a9c6eceb",
|
||||
"configHash": "708dd0df",
|
||||
"lockfileHash": "e3b0c442",
|
||||
"browserHash": "0c8cee9f",
|
||||
"optimized": {},
|
||||
"chunks": {}
|
||||
}
|
||||
3
.vite/deps/package.json
Normal file
3
.vite/deps/package.json
Normal file
@@ -0,0 +1,3 @@
|
||||
{
|
||||
"type": "module"
|
||||
}
|
||||
72
CONTRIBUTING.md
Normal file
72
CONTRIBUTING.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# Contributing to KROW Workforce Platform
|
||||
|
||||
Welcome to the KROW Workforce development team! This guide will help you get set up and understand our development practices.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Getting Started & Setup Checklist
|
||||
|
||||
Follow these steps to set up your development environment and gain access to all necessary resources.
|
||||
|
||||
1. **Access Google Chat Space:**
|
||||
* Ensure you have been invited to and joined our main Google Chat space for daily communication and quick questions.
|
||||
|
||||
2. **GitHub Access & SSH Key:**
|
||||
* Confirm you have read/write access to this GitHub repository.
|
||||
* Configure your SSH key for GitHub. Ensure your commits are verified (GPG signing is recommended).
|
||||
|
||||
3. **Install & Configure Gemini CLI:**
|
||||
* Install the Gemini CLI on your local machine.
|
||||
* Familiarize yourself with its usage, especially for documentation updates (refer to `docs/06-maintenance-guide.md`).
|
||||
|
||||
4. **Install & Configure Enpass:**
|
||||
* Install Enpass (our team's shared password manager).
|
||||
* Ensure you have access to the shared KROW vault for all project credentials (API keys, service accounts, etc.).
|
||||
|
||||
5. **Install Recommended Development Tools:**
|
||||
* **IDE:** We recommend **VS Code** or **Vim/Neovim** for development.
|
||||
* **Diagramming:** Use **MermaidChart.com** for creating and editing diagrams (Mermaid syntax).
|
||||
|
||||
6. **Local Development Environment Setup:**
|
||||
* Clone the monorepo: `git clone git@github.com:Oloodi/krow-workforce.git`
|
||||
* Navigate to the project root: `cd krow-workforce`
|
||||
* Install web frontend dependencies: `make install`
|
||||
* *(Mobile app dependencies will be installed within their respective directories later.)*
|
||||
|
||||
7. **Firebase Project Access Validation (CTO will provide access):**
|
||||
* Confirm you have access to the `dev` Firebase/GCP project.
|
||||
* Verify you can run `firebase login` and `gcloud auth login` successfully.
|
||||
|
||||
8. **Understand the Monorepo Structure:**
|
||||
* Familiarize yourself with the project layout as described in the main `README.md`.
|
||||
|
||||
---
|
||||
|
||||
## 💡 Development Guidelines
|
||||
|
||||
1. **Branching Strategy:**
|
||||
* We adopt a **feature branch workflow**. All code modifications must be done on a new branch, linked to a GitHub Issue.
|
||||
* The `main` and `dev` branches are protected.
|
||||
|
||||
2. **Commit Messages:**
|
||||
* Use **Open Commit** for intelligent and standardized Git commit messages.
|
||||
|
||||
3. **Code Standards:**
|
||||
* Adhere to existing code style, formatting, and architectural patterns found in the codebase.
|
||||
* Run linters and formatters before committing.
|
||||
|
||||
4. **Documentation:**
|
||||
* Refer to the **[Documentation Overview](./README.md#documentation-overview)** in the main `README.md` for all project documentation.
|
||||
* For Base44 integration specifics, see **[06-maintenance-guide.md](./docs/06-maintenance-guide.md)**.
|
||||
|
||||
5. **Diagrams:**
|
||||
* All diagrams should be created using **Mermaid syntax** and stored in Markdown files.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Useful Links
|
||||
|
||||
- **KROW Internal Launchpad:** *(Link will be provided after deployment to Firebase Hosting)*
|
||||
- **Project Vision:** [docs/00-vision.md](./docs/00-vision.md)
|
||||
- **Technical Roadmap:** [docs/04-strategy-technical-roadmap.md](./docs/04-strategy-technical-roadmap.md)
|
||||
- **Project Plan:** [docs/05-project-plan.md](./docs/05-project-plan.md)
|
||||
36
Makefile
36
Makefile
@@ -11,34 +11,34 @@
|
||||
|
||||
# Installs all project dependencies using npm.
|
||||
install:
|
||||
@echo "--> Installing project dependencies..."
|
||||
@npm install
|
||||
@echo "--> Installing web frontend dependencies..."
|
||||
@cd frontend-web && npm install
|
||||
|
||||
# Starts the local development server.
|
||||
dev:
|
||||
@echo "--> Starting development server on http://localhost:5173 ..."
|
||||
@npm run dev
|
||||
@echo "--> Starting web frontend development server on http://localhost:5173 ..."
|
||||
@cd frontend-web && npm run dev
|
||||
|
||||
# Builds the application for production.
|
||||
build:
|
||||
@echo "--> Building application for production..."
|
||||
@npm run build
|
||||
@echo "--> Building web frontend for production..."
|
||||
@cd frontend-web && npm run build
|
||||
|
||||
# Integrates a new Base44 export into the current project.
|
||||
# It replaces the src directory and the index.html file.
|
||||
# Prerequisite: The new export must be in a folder named '../krow-workforce-web-export-latest'.
|
||||
# It replaces the src directory and the index.html file in the frontend-web directory.
|
||||
# Prerequisite: The new export must be in a folder named '../krow-workforce-export-latest'.
|
||||
integrate-export:
|
||||
@echo "--> Integrating new Base44 export..."
|
||||
@if [ ! -d "../krow-workforce-web-export-latest" ]; then \
|
||||
echo "❌ Error: Export directory '../krow-workforce-web-export-latest' not found."; \
|
||||
@echo "--> Integrating new Base44 export into frontend-web/..."
|
||||
@if [ ! -d "../krow-workforce-export-latest" ]; then \
|
||||
echo "❌ Error: Export directory '../krow-workforce-export-latest' not found."; \
|
||||
exit 1; \
|
||||
fi
|
||||
@echo " - Removing old src directory..."
|
||||
@rm -rf src
|
||||
@rm -rf frontend-web/src
|
||||
@echo " - Copying new src directory..."
|
||||
@cp -R ../krow-workforce-web-export-latest/src ./src
|
||||
@cp -R ../krow-workforce-export-latest/src ./frontend-web/src
|
||||
@echo " - Copying new index.html..."
|
||||
@cp ../krow-workforce-web-export-latest/index.html ./index.html
|
||||
@cp ../krow-workforce-export-latest/index.html ./frontend-web/index.html
|
||||
@echo "--> Integration complete. Next step: 'make prepare-export'."
|
||||
|
||||
# Applies all necessary patches to a fresh Base44 export to run it locally.
|
||||
@@ -53,10 +53,10 @@ help:
|
||||
@echo "--------------------------------------------------"
|
||||
@echo " KROW Workforce - Available Makefile Commands"
|
||||
@echo "--------------------------------------------------"
|
||||
@echo " make install - Installs project dependencies."
|
||||
@echo " make dev - Starts the local development server."
|
||||
@echo " make build - Builds the application for production."
|
||||
@echo " make integrate-export - Integrates a new Base44 export from '../krow-workforce-web-export-latest'."
|
||||
@echo " make install - Installs web frontend dependencies."
|
||||
@echo " make dev - Starts the local web frontend server."
|
||||
@echo " make build - Builds the web frontend for production."
|
||||
@echo " make integrate-export - Integrates a new Base44 export from '../krow-workforce-export-latest'."
|
||||
@echo " make prepare-export - Prepares a fresh Base44 export for local use."
|
||||
@echo " make help - Shows this help message."
|
||||
@echo "--------------------------------------------------"
|
||||
|
||||
93
README.md
93
README.md
@@ -1,72 +1,55 @@
|
||||
# KROW Workforce - Frontend
|
||||
# KROW Workforce Platform
|
||||
|
||||
Ce projet contient le code du frontend pour la plateforme KROW Workforce. Il a été initialement prototypé sur la plateforme low-code Base44 et est en cours de migration vers une infrastructure backend personnalisée sur Google Cloud Platform (GCP).
|
||||
This monorepo contains the complete source code for the KROW Workforce platform, including the web frontend, mobile applications, and backend services.
|
||||
|
||||
Ce `README.md` est le guide officiel pour l'équipe de développement. **NE PAS REMPLACER** ce fichier par celui fourni dans les exports de Base44.
|
||||
## 🚀 What's in this Monorepo?
|
||||
|
||||
---
|
||||
- **/firebase/**: Contains the Firebase Data Connect configuration (GraphQL schema, queries, mutations) and Firebase Hosting configuration.
|
||||
- **/frontend-web/**: The React/Vite web application used by administrators and managers.
|
||||
- **/mobile-apps/**: Contains the two Flutter-based mobile applications:
|
||||
- `client-app`: For clients managing events.
|
||||
- `staff-app`: For staff members managing their shifts and profile.
|
||||
- **/docs/**: All project documentation (vision, roadmaps, architecture, guides).
|
||||
- **/scripts/**: Automation scripts used by the `Makefile`.
|
||||
- **/secrets/**: Contains sensitive credentials (ignored by Git).
|
||||
|
||||
## 🚀 Démarrage Rapide
|
||||
## ▶️ Getting Started
|
||||
|
||||
Ce projet utilise un `Makefile` comme point d'entrée principal pour toutes les commandes courantes.
|
||||
This project uses a central `Makefile` to orchestrate all common tasks.
|
||||
|
||||
### Prérequis
|
||||
- Node.js (version LTS recommandée)
|
||||
- npm
|
||||
- `make` (généralement pré-installé sur Linux et macOS)
|
||||
|
||||
### Installation et Lancement
|
||||
1. **Installer les dépendances :**
|
||||
1. **Install Dependencies:**
|
||||
```bash
|
||||
make install
|
||||
```
|
||||
*(This will install dependencies for the web frontend. Mobile dependency installation is handled within their respective directories.)*
|
||||
|
||||
2. **Lancer le serveur de développement :**
|
||||
2. **Run a Service:**
|
||||
- To run the web frontend: `make dev`
|
||||
- *(Additional commands for mobile and backend will be added as development progresses.)*
|
||||
|
||||
3. **See All Commands:**
|
||||
For a full list of available commands, run:
|
||||
```bash
|
||||
make dev
|
||||
bash
|
||||
make help
|
||||
```
|
||||
L'application sera disponible sur `http://localhost:5173`.
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
New to the KROW team? Start here to set up your environment and understand our development practices: **[CONTRIBUTING.md](./CONTRIBUTING.md)**
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Workflow d'Intégration des Mises à Jour de Base44
|
||||
## 📚 Documentation Overview
|
||||
|
||||
Pour intégrer les nouvelles modifications de l'UI faites par la cliente sur la plateforme Base44, suivez ce processus rigoureux :
|
||||
This section provides a quick guide to the most important documentation files in this monorepo, ordered by logical reading flow:
|
||||
|
||||
### 1. Valider les Changements d'API
|
||||
Avant d'intégrer le nouveau code, il est impératif de mettre à jour notre documentation API et notre spécification technique. Suivez rigoureusement la procédure détaillée dans le fichier `docs/MAINTENANCE_GUIDE.md`.
|
||||
|
||||
### 2. Intégrer le Nouveau Frontend
|
||||
1. **Créez une branche dédiée** dans Git :
|
||||
```bash
|
||||
git checkout -b integration/base44-update-YYYY-MM-DD
|
||||
```
|
||||
2. **Placez l'export** de Base44 dans un dossier nommé `krow-workforce-web-export-latest` à côté du dossier de ce projet. La structure attendue est :
|
||||
```
|
||||
- /krow-workforce-web/ (ce projet)
|
||||
- /krow-workforce-web-export-latest/ (le nouvel export)
|
||||
```
|
||||
3. **Exécutez la commande d'intégration** pour copier automatiquement les fichiers `src` et `index.html` :
|
||||
```bash
|
||||
make integrate-export
|
||||
```
|
||||
4. **Exécutez le script de préparation** pour neutraliser le SDK Base44 et appliquer nos patchs :
|
||||
```bash
|
||||
make prepare-export
|
||||
```
|
||||
5. **Analysez les différences** avec `git diff`. Intégrez les nouveaux composants et les modifications de l'UI, mais **rejetez les changements** sur les fichiers que nous avons patchés (`src/api/base44Client.js`, `src/main.jsx`, `src/pages/Layout.jsx`) pour conserver notre environnement local fonctionnel. Vérifiez également `package.json` pour toute nouvelle dépendance à ajouter manuellement.
|
||||
6. **Testez l'application** en local avec `make dev` pour vous assurer que tout fonctionne comme prévu.
|
||||
7. Commitez vos changements.
|
||||
|
||||
---
|
||||
|
||||
## 📂 Structure du Projet
|
||||
|
||||
- `scripts/prepare-export.js`: Script de patching pour le workflow hybride.
|
||||
- `docs/`: Contient la documentation du projet (spécification de l'API, guides...).
|
||||
- `src/`: Code source de l'application.
|
||||
- `src/api/`: Contient la configuration du client API (actuellement mocké).
|
||||
- `src/components/`: Composants React réutilisables.
|
||||
- `src/pages/`: Vues principales de l'application, correspondant aux routes.
|
||||
- `src/lib/`: Utilitaires et bibliothèques partagées.
|
||||
- `Makefile`: Orchestrateur des commandes du projet.
|
||||
- **[00-vision.md](./docs/00-vision.md)**: The "Why" behind the KROW platform, outlining our core objectives and guiding principles.
|
||||
- **[01-product-functional-roadmap.md](./docs/01-product-functional-roadmap.md)**: The "What" we are building, from a user-facing features perspective.
|
||||
- **[02-architecture-overview.md](./docs/02-architecture-overview.md)**: Visual diagrams explaining the technical architecture of our web and mobile applications.
|
||||
- **[03-backend-api-specification.md](./docs/03-backend-api-specification.md)**: The detailed technical specification for our custom backend API.
|
||||
- **[04-strategy-technical-roadmap.md](./docs/04-strategy-technical-roadmap.md)**: Our strategic plan for building the platform, outlining phases and milestones.
|
||||
- **[05-project-plan.md](./docs/05-project-plan.md)**: A detailed breakdown of tasks by milestone, ready for GitHub Issues.
|
||||
- **[06-maintenance-guide.md](./docs/06-maintenance-guide.md)**: The operational manual for integrating updates from the Base44 visual builder.
|
||||
- **[07-reference-base44-api-export.md](./docs/07-reference-base44-api-export.md)**: The raw API documentation exported from Base44, used as a reference.
|
||||
- **[08-reference-base44-prompts.md](./docs/08-reference-base44-prompts.md)**: A collection of standardized prompts for interacting with the Base44 AI.
|
||||
|
||||
16
docs/00-vision.md
Normal file
16
docs/00-vision.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# KROW Platform Vision
|
||||
|
||||
Our vision is to build a fully autonomous, modern, and scalable workforce management platform by leveraging a unified and productive tech stack.
|
||||
|
||||
## Core Objective
|
||||
|
||||
To achieve complete technical independence by consolidating the KROW platform (Web, Mobile Client, Mobile Staff) onto a single, robust, and maintainable ecosystem: **Firebase & Google Cloud**.
|
||||
|
||||
## Guiding Principles
|
||||
|
||||
1. **Velocity & Focus:** We will use tools that maximize the productivity of our small, focused development team. **Firebase Data Connect** and its generated SDKs are central to this principle.
|
||||
2. **Unified Backend:** A single backend (Data Connect) will power all applications (Web, iOS, Android). This ensures data consistency, reduces code duplication, and simplifies maintenance.
|
||||
3. **Scalability & Low Overhead:** We will rely on managed services (Cloud SQL, Firebase Auth, Firebase Hosting) to minimize operational burden and ensure high performance and reliability.
|
||||
4. **Data Ownership & Future-Proofing:** We will have full control over our relational database (PostgreSQL). This is a strategic asset that will enable complex reporting and advanced features in the future.
|
||||
5. **Base44 as a Design Accelerator:** We will treat the Base44 platform not as a system to migrate, but as an advanced visual prototyping tool. It defines the "what" (the UI/UX), and our team builds the "how" (the robust backend).
|
||||
6. **Automation as a Force Multiplier:** We will automate all repetitive tasks (environment setup, deployment, testing) via a `Makefile` and CI/CD pipelines. This is crucial for our small team's efficiency and for reducing errors.
|
||||
84
docs/01-product-functional-roadmap.md
Normal file
84
docs/01-product-functional-roadmap.md
Normal file
@@ -0,0 +1,84 @@
|
||||
# Product Roadmap: KROW Platform Foundation (3-Month Plan)
|
||||
|
||||
**Project Name:** KROW - New Platform Foundation
|
||||
|
||||
**Context:** We are leveraging the validated visual prototype from Base44 to rebuild the KROW platform on a modern, scalable, and proprietary technical infrastructure. This ensures a smooth transition and provides clear visibility on delivered features.
|
||||
|
||||
**3-Month Goal:** To have a functional and autonomous first version of the KROW platform, including a web dashboard for event management and a mobile app for staff, all running on our new Google Cloud infrastructure.
|
||||
|
||||
---
|
||||
|
||||
### **Detailed Product Roadmap (Client/CEO View)**
|
||||
|
||||
#### **Phase 1: From Vision to Technical Foundation**
|
||||
|
||||
**Goal of the Phase (for the client):** "We will transform your prototype into a concrete action plan. By the end of this phase, we will have a first version of the dashboard deployed where you can track our progress, and we will be fully independent to build and deploy future applications."
|
||||
|
||||
**Visible Features Delivered at the End of Phase 1:**
|
||||
|
||||
1. **A Preview Web Dashboard (React):**
|
||||
* **Description:** A first version of the dashboard (based on the Base44 export) will be accessible via a private URL. Initially, the data will be static, but the visual interface will be live.
|
||||
* **What this means for the client:** You will see the design and navigation of your dashboard come to life outside of Base44, on our own infrastructure.
|
||||
|
||||
2. **A Foundation for the New Mobile Apps:**
|
||||
* **Description:** The skeletons of the new Flutter apps (Staff and Client) will be created, with a functional login system.
|
||||
* **What this means for the client:** The foundations for the future apps will be ready, and we will have validated our ability to deploy them automatically to the app stores (TestFlight for Apple, Internal Testing for Google).
|
||||
|
||||
3. **A Documented V1 API Contract:**
|
||||
* **Description:** A clear document that precisely describes how the frontend (web and mobile) will communicate with the backend. This is the "blueprint" of our system.
|
||||
* **What this means for the client:** This guarantees that all parts of the KROW ecosystem (web, mobile, backend) will speak the same language, ensuring consistency and speed for future developments.
|
||||
|
||||
**Technical Work Behind the Scenes (for the team):**
|
||||
* Analysis of the Base44 code.
|
||||
* Setup of the infrastructure on Google Cloud (Cloud SQL, Firebase Auth, Data Connect).
|
||||
* Configuration of CI/CD pipelines for web (e.g., GitHub Actions) and mobile (e.g., CodeMagic).
|
||||
|
||||
---
|
||||
|
||||
#### **Phase 2: The First Features Come to Life**
|
||||
|
||||
**Goal of the Phase (for the client):** "You will start seeing your own data (events, staff) appear in the new dashboard. The staff mobile app will no longer be an empty shell but will display actual shifts. We are establishing a workflow that will allow you to continue prototyping in parallel with our development."
|
||||
|
||||
**Visible Features Delivered at the End of Phase 2:**
|
||||
|
||||
1. **An Event Management Dashboard (Read-only):**
|
||||
* **Description:** The web dashboard will display the list of your events, hubs, and staff, reading the data directly from our new database. Create/edit functionalities will not be active yet.
|
||||
* **What this means for the client:** You will be able to view your real operational data on the new interface, validating that our backend is correctly connected.
|
||||
|
||||
2. **The Staff Mobile App (v2) Displays Real Shifts:**
|
||||
* **Description:** A staff member will be able to log into the new app and see the list of shifts they are assigned to, with basic details (date, location, role).
|
||||
* **What this means for the client:** The synergy between the backend and the mobile app is proven. The foundation is ready to add interactive features.
|
||||
|
||||
3. **An Established Design-to-Development Iteration Workflow:**
|
||||
* **Description:** We will have a clear process to "freeze" a version of the Base44 design for development, while giving you the freedom to work on the next version.
|
||||
* **What this means for the client:** You can continue to innovate and prototype on Base44 without fear of disrupting the development team's work.
|
||||
|
||||
**Technical Work Behind the Scenes:**
|
||||
* Development of Data Connect queries to read data (`listEvents`, `listStaff`, etc.).
|
||||
* Integration of TanStack Query in the dashboard for data management.
|
||||
* Implementation of the service layer in the Flutter app to call the Data Connect SDK.
|
||||
|
||||
---
|
||||
|
||||
#### **Phase 3: The First Complete Business Flow**
|
||||
|
||||
**Goal of the Phase (for the client):** "By the end of this quarter, you will be able to perform a complete business action on the new platform: create a complex event on the web dashboard and instantly see the corresponding shifts appear on the staff mobile app."
|
||||
|
||||
**Visible Features Delivered at the End of Phase 3:**
|
||||
|
||||
1. **A Complete Event Creation and Modification Flow on the Web Dashboard:**
|
||||
* **Description:** The event creation form will be fully functional. You will be able to create an event, add shifts, define positions with roles and rates, and assign contacts.
|
||||
* **What this means for the client:** **You are now autonomous in managing the core of your operations on the new platform.** The Base44 prototype has been transformed into a functional production tool.
|
||||
|
||||
2. **Synchronization Between Web and Mobile:**
|
||||
* **Description:** A shift created or modified on the web dashboard will be immediately (or almost immediately) visible and updated on the mobile app of the concerned staff member.
|
||||
* **What this means for the client:** The vision of a unified and reactive ecosystem is now a tangible reality.
|
||||
|
||||
3. **A Stabilized Platform Ready for Growth:**
|
||||
* **Description:** The technical foundation will have been tested, documented, and secured.
|
||||
* **What this means for the client:** We have a solid foundation on which we can confidently build the more advanced features of your vision (KROW University, predictive AI, etc.).
|
||||
|
||||
**Technical Work Behind the Scenes:**
|
||||
* Development of complex Data Connect mutations for create/edit logic.
|
||||
* Implementation of unit tests and security reviews.
|
||||
* Finalization of the V1 API documentation.
|
||||
95
docs/02-architecture-overview.md
Normal file
95
docs/02-architecture-overview.md
Normal file
@@ -0,0 +1,95 @@
|
||||
# KROW Project Workflows
|
||||
|
||||
This document contains diagrams describing the technical architecture and collaboration processes for the project.
|
||||
|
||||
## 1. Web App Migration Architecture
|
||||
|
||||
This diagram illustrates the migration workflow for the web application. It shows how the UI is exported from the Base44 environment and then connected to our new, unified backend built on Firebase services.
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph Base44 Environment
|
||||
direction TB
|
||||
Client[Client] -- Modifies --> B44_UI[<b>Base44 Visual Builder</b><br><i>Features:</i><br>- Event Management<br>- Staff Directory]
|
||||
B44_UI --> B44_Backend[<b>Base44 Backend</b><br>Provides Schemas & SDK]
|
||||
end
|
||||
|
||||
subgraph Firebase Ecosystem - GCP
|
||||
direction TB
|
||||
KROW_FE[<b>KROW Web Frontend</b><br>Vite/React + TanStack Query]
|
||||
|
||||
subgraph Firebase Services
|
||||
direction TB
|
||||
Auth[Firebase Authentication]
|
||||
DataConnect[<b>Firebase Data Connect</b><br>GraphQL API]
|
||||
SQL_DB[<b>Cloud SQL for PostgreSQL</b>]
|
||||
end
|
||||
|
||||
KROW_FE -- "Uses" --> Auth
|
||||
KROW_FE -- "Calls API via SDK" --> DataConnect
|
||||
DataConnect -- "Manages & Queries" --> SQL_DB
|
||||
end
|
||||
|
||||
B44_UI -- "<b>UI Code Export</b>" --> KROW_FE
|
||||
|
||||
style Client fill:#f9f,stroke:#333,stroke-width:2px
|
||||
style B44_UI fill:#ffe,stroke:#333,stroke-width:2px
|
||||
style KROW_FE fill:#eef,stroke:#333,stroke-width:2px
|
||||
```
|
||||
|
||||
## 2. Mobile App Architecture
|
||||
|
||||
This diagram shows how the native mobile applications (Client and Staff) connect to the centralized Firebase backend. This backend is the same one used by the web application.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph KROW Mobile Applications
|
||||
direction LR
|
||||
Mobile_Client[<b>Mobile Client App</b><br>Flutter]
|
||||
Mobile_Staff[<b>Mobile Staff App</b><br>Flutter]
|
||||
end
|
||||
|
||||
subgraph Firebase Backend Services - GCP
|
||||
direction TB
|
||||
Auth[Firebase Authentication]
|
||||
DataConnect[<b>Firebase Data Connect</b><br>GraphQL API &<br>Generated SDKs]
|
||||
SQL_DB[<b>Cloud SQL for PostgreSQL</b><br><i>Managed by Data Connect</i>]
|
||||
end
|
||||
|
||||
Mobile_Client -- "Authenticates with" --> Auth
|
||||
Mobile_Client -- "Calls API via generated SDK" --> DataConnect
|
||||
|
||||
Mobile_Staff -- "Authenticates with" --> Auth
|
||||
Mobile_Staff -- "Calls API via generated SDK" --> DataConnect
|
||||
|
||||
DataConnect -- "Manages & Queries" --> SQL_DB
|
||||
|
||||
style Mobile_Client fill:#eef,stroke:#333,stroke-width:2px
|
||||
style Mobile_Staff fill:#eef,stroke:#333,stroke-width:2px
|
||||
```
|
||||
|
||||
## 3. Collaboration Workflow for Modifications
|
||||
|
||||
This diagram formalizes the process to follow for any modifications initiated by the client on the Base44 platform. The objective is to control the pace of changes and evaluate their impact on our backend before integration.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Client identifies a need<br>for modification] --> B{Define functionality<br>and scope};
|
||||
|
||||
B --> C{Does the modification impact<br>only the UI or also<br>logic/data?};
|
||||
|
||||
C -- "UI Only" --> D[Client makes modifications<br>on Base44];
|
||||
C -- "Logic/Data" --> E[Team-Client Coordination<br>to assess impact on GCP backend];
|
||||
|
||||
D --> F[Planned export of the<br>new UI version];
|
||||
E --> F;
|
||||
|
||||
F --> G["Developer runs the automation<br>1. `make integrate-export`<br>2. `make prepare-export`"];
|
||||
|
||||
G --> H[Development & Testing<br>- Adapt GCP backend if needed<br>- Validate locally];
|
||||
|
||||
H --> I[✅ Integration complete];
|
||||
|
||||
style A fill:#f9f,stroke:#333,stroke-width:2px
|
||||
style D fill:#f9f,stroke:#333,stroke-width:2px
|
||||
```
|
||||
131
docs/03-backend-api-specification.md
Normal file
131
docs/03-backend-api-specification.md
Normal file
@@ -0,0 +1,131 @@
|
||||
# KROW Workforce API Specification (GCP Migration)
|
||||
|
||||
**Version:** 2.0
|
||||
**Date:** 2025-11-11
|
||||
**Objective:** This document defines the backend API to be built on the Firebase/GCP ecosystem, replacing the Base44 backend. It is based on the comprehensive Base44 API documentation (v2.0) and will guide the development of the new backend using Firebase Data Connect and Cloud Functions.
|
||||
|
||||
---
|
||||
|
||||
## General Conventions
|
||||
|
||||
- **API Layer:** The backend will be composed of two main parts:
|
||||
- **Firebase Data Connect:** A GraphQL API for all data-centric (CRUD) operations.
|
||||
- **Cloud Functions:** A set of RESTful endpoints for all service-centric operations (e.g., sending emails, processing files).
|
||||
- **Authentication:** Every request must include an `Authorization: Bearer <Firebase-Auth-Token>` header, managed and validated by Firebase.
|
||||
- **Data Format:** All requests and responses will be in `application/json` format.
|
||||
- **Error Responses:** Errors will use standard HTTP status codes (400, 401, 403, 404, 500) and include a JSON response body of the form `{ "error": "Problem description" }`.
|
||||
- **Common Fields:** Each entity will have the following fields, automatically managed by the backend:
|
||||
- `id`: `string` (UUID, Primary Key)
|
||||
- `created_date`: `string` (ISO 8601 Timestamp)
|
||||
- `updated_date`: `string` (ISO 8601 Timestamp)
|
||||
- `created_by`: `string` (Email of the creating user)
|
||||
|
||||
---
|
||||
|
||||
## 1. Authentication (Firebase Auth)
|
||||
|
||||
Authentication will be handled entirely by Firebase Authentication. The client applications (web and mobile) are responsible for the sign-up and sign-in flows using the Firebase SDK. The backend will use the provided auth token to identify the user for all subsequent requests.
|
||||
|
||||
### `User` Entity (Managed by Firebase Auth & Data Connect)
|
||||
|
||||
| Field | Type | Description |
|
||||
| ----------- | -------- | ----------------------------------------- |
|
||||
| `id` | `string` | Firebase User ID (UID) |
|
||||
| `email` | `string` | User's email (non-modifiable) |
|
||||
| `full_name` | `string` | Full name |
|
||||
| `user_role` | `string` | Custom application role (`admin`, `procurement`, `client`...) |
|
||||
| `...other` | `any` | Other custom fields can be added. |
|
||||
|
||||
---
|
||||
|
||||
## 2. Data API (Firebase Data Connect)
|
||||
|
||||
All entities below will be managed via a GraphQL API powered by Firebase Data Connect. For each entity, standard `query` (list, get by ID) and `mutation` (create, update, delete) operations will be defined in the `firebase/dataconnect/` directory.
|
||||
|
||||
### 2.1. Event
|
||||
|
||||
**Description:** Manages events and workforce orders.
|
||||
|
||||
| Field | Type | Description |
|
||||
| ----------------------- | --------- | ------------------------------------------------ |
|
||||
| `event_name` | `string` | Name of the event (required) |
|
||||
| `is_recurring` | `boolean` | Indicates if the event is recurring |
|
||||
| `recurrence_type` | `string` | `single`, `date_range`, `scatter` |
|
||||
| `business_id` | `string` | ID of the client (`Business`) |
|
||||
| `vendor_id` | `string` | ID of the provider (`Vendor`) |
|
||||
| `status` | `string` | `Draft`, `Active`, `Pending`, `Assigned`, `Confirmed`, `Completed`, `Canceled` |
|
||||
| `date` | `string` | Event date (ISO 8601) |
|
||||
| `shifts` | `jsonb` | Array of `Shift` objects |
|
||||
| `total` | `number` | Total cost |
|
||||
| `requested` | `number` | Total number of staff requested |
|
||||
| `assigned_staff` | `jsonb` | Array of assigned staff objects |
|
||||
|
||||
### 2.2. Staff
|
||||
|
||||
**Description:** Manages staff members.
|
||||
|
||||
| Field | Type | Description |
|
||||
| ------------------------- | --------- | ----------------------------------------- |
|
||||
| `employee_name` | `string` | Full name (required) |
|
||||
| `vendor_id` | `string` | ID of the provider (`Vendor`) |
|
||||
| `email` | `string` | Email address |
|
||||
| `position` | `string` | Primary job position/skill |
|
||||
| `employment_type` | `string` | `Full Time`, `Part Time`, `On call`, etc. |
|
||||
| `rating` | `number` | Performance rating (0-5) |
|
||||
| `reliability_score` | `number` | Reliability score (0-100) |
|
||||
| `background_check_status` | `string` | `pending`, `cleared`, `failed`, `expired` |
|
||||
| `certifications` | `jsonb` | List of certifications |
|
||||
|
||||
### 2.3. Vendor
|
||||
|
||||
**Description:** Manages providers and their onboarding.
|
||||
|
||||
| Field | Type | Description |
|
||||
| ----------------------- | --------- | ----------------------------------------- |
|
||||
| `vendor_number` | `string` | Vendor number (e.g., `VN-####`) |
|
||||
| `legal_name` | `string` | Legal company name (required) |
|
||||
| `primary_contact_email` | `string` | Primary contact email (required) |
|
||||
| `approval_status` | `string` | `pending`, `approved`, `suspended`, `terminated` |
|
||||
| `is_active` | `boolean` | Active status |
|
||||
| `w9_document` | `string` | URL or URI of the W9 document |
|
||||
| `coi_document` | `string` | URL or URI of the Certificate of Insurance|
|
||||
|
||||
---
|
||||
|
||||
*Note: For brevity, only the most critical entities have been detailed. The same structure (Schema defined in GraphQL) must be applied for all other entities: `VendorRate`, `Invoice`, `Business`, `Certification`, `Team`, `Conversation`, `Message`, `ActivityLog`, `Enterprise`, `Sector`, `Partner`, `Order`, and `Shift`, based on the `07-reference-base44-api-export.md` document.*
|
||||
|
||||
---
|
||||
|
||||
## 3. Services API (Cloud Functions)
|
||||
|
||||
These endpoints are not for CRUD operations but for specific, service-oriented tasks. They will be implemented as individual HTTP-triggered Cloud Functions.
|
||||
|
||||
### `POST /sendEmail`
|
||||
- **Description:** Sends an email.
|
||||
- **Original SDK:** `base44.integrations.Core.SendEmail(params)`
|
||||
- **Body:** `{ "to": "...", "subject": "...", "body": "..." }`
|
||||
- **Response (200 OK):** `{ "status": "sent" }`
|
||||
|
||||
### `POST /invokeLLM`
|
||||
- **Description:** Calls a large language model (Vertex AI).
|
||||
- **Original SDK:** `base44.integrations.Core.InvokeLLM(params)`
|
||||
- **Body:** `{ "prompt": "...", "response_json_schema": {...}, "file_urls": [...] }`
|
||||
- **Response (200 OK):** `{ "result": "..." }`
|
||||
|
||||
### `POST /uploadFile`
|
||||
- **Description:** Handles the upload of public files to Google Cloud Storage and returns a public URL.
|
||||
- **Original SDK:** `base44.integrations.Core.UploadFile({ file })`
|
||||
- **Request:** `multipart/form-data`.
|
||||
- **Response (200 OK):** `{ "file_url": "https://..." }`
|
||||
|
||||
### `POST /uploadPrivateFile`
|
||||
- **Description:** Handles the upload of private files to Google Cloud Storage and returns a secure URI.
|
||||
- **Original SDK:** `base44.integrations.Core.UploadPrivateFile({ file })`
|
||||
- **Request:** `multipart/form-data`.
|
||||
- **Response (200 OK):** `{ "file_uri": "gs://..." }`
|
||||
|
||||
### `POST /createSignedUrl`
|
||||
- **Description:** Creates a temporary access URL for a private file.
|
||||
- **Original SDK:** `base44.integrations.Core.CreateFileSignedUrl(params)`
|
||||
- **Body:** `{ "file_uri": "...", "expires_in": 3600 }`
|
||||
- **Response (200 OK):** `{ "signed_url": "https://..." }`
|
||||
41
docs/04-strategy-technical-roadmap.md
Normal file
41
docs/04-strategy-technical-roadmap.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# KROW Technical Roadmap
|
||||
|
||||
This document outlines the technical strategy for building the new, autonomous KROW platform. It is structured in phases rather than fixed dates to maintain agility.
|
||||
|
||||
```mermaid
|
||||
gantt
|
||||
title KROW Platform Build Roadmap
|
||||
dateFormat W
|
||||
axisFormat Week %W
|
||||
|
||||
section Phase 1: Foundation & Dev Environment Setup
|
||||
Infrastructure Setup : 1, 1w
|
||||
GraphQL Schema Definition : 1, 1w
|
||||
Data Connect Deployment (Dev): 2, 1w
|
||||
SDK Generation & Web/Mobile PoC : 3, 1w
|
||||
|
||||
section Phase 2: Core Feature Implementation
|
||||
Backend Logic (All Entities): 4, 4w
|
||||
Web App Re-wiring : 4, 4w
|
||||
Mobile Apps Re-wiring : 5, 4w
|
||||
|
||||
section Phase 3: Production Readiness & Go-Live
|
||||
CI/CD Pipelines Setup : 9, 2w
|
||||
Staging Env Deployment & E2E Testing : 10, 2w
|
||||
Production Deployment & Data Import : 12, 1w
|
||||
Monitoring & Security : 12, 1w
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Foundation & Dev Environment Setup (~3-4 Weeks)
|
||||
* **Goal:** To have a fully functional, shared `dev` environment in the cloud. All developers can connect to it from their local machines.
|
||||
* **Key Milestone:** The web app and a mobile app screen can successfully authenticate and fetch live data from the `dev` Firebase/GCP project.
|
||||
|
||||
## Phase 2: Core Feature Implementation (~5-6 Weeks)
|
||||
* **Goal:** To achieve functional parity with the Base44 prototype across all three platforms, all powered by our shared `dev` backend.
|
||||
* **Key Milestone:** The full lifecycle of core features (Event, Staff, Vendor management) is functional on all apps.
|
||||
|
||||
## Phase 3: Production Readiness & Go-Live (~4 Weeks)
|
||||
* **Goal:** To automate, secure, and deploy the entire platform to production.
|
||||
* **Key Milestone:** The KROW platform is live on production infrastructure. The team has a repeatable, automated process for future deployments.
|
||||
77
docs/05-project-plan.md
Normal file
77
docs/05-project-plan.md
Normal file
@@ -0,0 +1,77 @@
|
||||
# KROW Project Plan & Task Breakdown
|
||||
|
||||
This document breaks down the technical roadmap into actionable tasks, assigned by role, ready to be converted into GitHub Issues.
|
||||
|
||||
---
|
||||
|
||||
## Milestone 1: Foundation & Dev Environment Setup
|
||||
|
||||
*Goal: Establish a fully functional, shared `dev` environment on GCP/Firebase that all developers can connect to.*
|
||||
|
||||
### Infrastructure & Tooling (Primarily CTO)
|
||||
- **Issue:** `[Infra] Setup Enpass for Team Credential Management`
|
||||
- **Description:** Configure the team's Enpass vault and establish the process for sharing secrets and service account keys.
|
||||
- **Issue:** `[Infra] Create GCP/Firebase Projects (dev, staging, prod)`
|
||||
- **Description:** Set up the three distinct Google Cloud projects and associated Firebase projects. Enable required APIs (Auth, Cloud SQL, Data Connect).
|
||||
- **Issue:** `[Infra] Create Multi-Env Makefile`
|
||||
- **Description:** Create the main `Makefile` inspired by the reference project. It should handle environment switching (`ENV=dev/staging`) and orchestrate all build/deploy tasks.
|
||||
- **Issue:** `[Infra] Setup Shared Dev Database`
|
||||
- **Description:** Provision the initial Cloud SQL for PostgreSQL instance for the `dev` environment.
|
||||
|
||||
### Backend & Web (Dev 1)
|
||||
- **Issue:** `[Backend] Define GraphQL Schema for Core Entities`
|
||||
- **Description:** Translate `Event`, `Staff`, `Vendor`, and `User` schemas from `api_specification.md` into `.gql` files for Data Connect.
|
||||
- **Issue:** `[Backend] Deploy Initial Schema & Operations to Dev Env`
|
||||
- **Description:** Use the `Makefile` to deploy the initial Data Connect schema and basic `list/get` queries to the `dev` project.
|
||||
- **Issue:** `[Web] Generate TypeScript SDK for Dev Env`
|
||||
- **Description:** Configure and run the SDK generation command to create the TypeScript SDK pointing to the `dev` environment.
|
||||
- **Issue:** `[Web] Connect Web App to Dev Backend`
|
||||
- **Description:** Modify the web app to use the generated SDK. The goal is to authenticate and display a list of events from the shared `dev` backend.
|
||||
|
||||
### Mobile (Dev 2)
|
||||
- **Issue:** `[Mobile] Generate Flutter SDK for Dev Env`
|
||||
- **Description:** Configure and run the SDK generation command to create the Flutter SDK pointing to the `dev` environment.
|
||||
- **Issue:** `[Mobile] Implement Firebase Auth Flow`
|
||||
- **Description:** Ensure both mobile apps can sign in and sign up using Firebase Auth against the `dev` project.
|
||||
- **Issue:** `[Mobile] Create Proof-of-Concept Screen`
|
||||
- **Description:** Build a simple screen in the Staff app that authenticates and fetches a list of events from the `dev` backend using the new SDK.
|
||||
|
||||
---
|
||||
|
||||
## Milestone 2: Core Feature Implementation
|
||||
|
||||
*Goal: Achieve functional parity with the Base44 prototype across all platforms, using the shared `dev` backend.*
|
||||
|
||||
### Backend (Dev 1)
|
||||
- **Epic:** `[Backend] Implement Full API Logic`
|
||||
- **Description:** Create all necessary GraphQL queries and mutations in Data Connect for all entities defined in `api_specification.md`. Deploy them continuously to the `dev` environment.
|
||||
|
||||
### Web (Dev 1, with support from Dev 2)
|
||||
- **Epic:** `[Web] Full Application Re-wiring`
|
||||
- **Description:** Systematically replace all data-fetching logic in the web app to use the TanStack Query hooks from the generated Data Connect SDK.
|
||||
|
||||
### Mobile (Dev 2)
|
||||
- **Epic:** `[Mobile] Full Application Re-wiring`
|
||||
- **Description:** Refactor the `repositories` and `api_providers` in both the Client and Staff Flutter apps to use the generated Data Connect SDK for all network calls.
|
||||
|
||||
---
|
||||
|
||||
## Milestone 3: Production Readiness & Go-Live
|
||||
|
||||
*Goal: Automate, secure, and deploy the entire platform to production.*
|
||||
|
||||
### Infrastructure & DevOps (CTO & Team)
|
||||
- **Issue:** `[CI/CD] Configure Web App Deployment Pipeline`
|
||||
- **Description:** Set up a GitHub Actions pipeline that builds and deploys the web app to Firebase Hosting, with separate jobs for `staging` and `prod`.
|
||||
- **Issue:** `[CI/CD] Configure Mobile App Deployment with CodeMagic`
|
||||
- **Description:** Set up CodeMagic pipelines to build and deploy the iOS and Android apps to TestFlight/Play Store Internal Testing.
|
||||
- **Issue:** `[CI/CD] Configure Backend Deployment Pipeline`
|
||||
- **Description:** Automate the deployment of the Data Connect schema and operations (`firebase deploy --only dataconnect`).
|
||||
- **Issue:** `[Data] Create & Test Initial Data Import Scripts`
|
||||
- **Description:** Write scripts to populate the production database with any necessary initial data.
|
||||
- **Issue:** `[QA] Deploy to Staging & Perform E2E Testing`
|
||||
- **Description:** Use the `Makefile` (`make deploy ENV=staging`) to deploy the entire stack to the staging environment for full end-to-end testing.
|
||||
- **Issue:** `[Ops] Final Production Deployment`
|
||||
- **Description:** Run the production deployment (`make deploy ENV=prod`) and execute data import scripts.
|
||||
- **Issue:** `[Ops] Setup Monitoring & Alerting`
|
||||
- **Description:** Configure monitoring dashboards in Google Cloud for the database, API, and application performance.
|
||||
55
docs/06-maintenance-guide.md
Normal file
55
docs/06-maintenance-guide.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# API Documentation Maintenance Guide
|
||||
|
||||
This document describes the procedure for updating the API documentation and our backend's technical specification after major changes are made on the Base44 platform.
|
||||
|
||||
Following this process is **essential** to ensure that our custom backend on GCP remains synchronized with the frontend's features.
|
||||
|
||||
## When to Follow This Procedure
|
||||
|
||||
You should follow this guide after each significant development cycle on the Base44 platform, especially after:
|
||||
- Adding new entities or data fields.
|
||||
- Modifying existing business logic.
|
||||
- Integrating major new features into the user interface.
|
||||
|
||||
---
|
||||
|
||||
## Update Procedure
|
||||
|
||||
### Step 1: Obtain Updated Documentation from Base44
|
||||
|
||||
1. **Open the `docs/08-reference-base44-prompts.md` file**.
|
||||
2. Copy the content of the **"Main Prompt"**.
|
||||
3. Paste this prompt into the Base44 AI chat to request the latest documentation.
|
||||
4. **Verification:** The AI should return the full content of the `base44-api-export.md` file. If it only returns a summary, use the following simple prompt to request the full content:
|
||||
```text
|
||||
Thank you for the summary. Please provide the entire, updated content of the API documentation file now.
|
||||
```
|
||||
|
||||
### Step 2: Update the Local Documentation File (with Gemini CLI)
|
||||
|
||||
To ensure clean and consistent formatting, it is recommended to use the Gemini CLI for this step.
|
||||
|
||||
1. **Copy the raw content** provided by the Base44 AI.
|
||||
2. **Provide this content to the Gemini CLI** with a simple prompt, for example:
|
||||
> "Here is the new Base44 API documentation. Can you reformat this content and update the `docs/07-reference-base44-api-export.md` file?"
|
||||
3. **Let the Gemini CLI** handle the file creation or update. It will ensure that tables, code blocks, and headers are correctly formatted.
|
||||
|
||||
### Step 3: Update the GCP API Specification (with Gemini CLI)
|
||||
|
||||
This is the most critical step. Instead of a tedious manual comparison, we will rely on the AI to synchronize our migration plan.
|
||||
|
||||
1. **Ensure Step 2 is complete** and that `docs/07-reference-base44-api-export.md` is up-to-date.
|
||||
2. **Ask the Gemini CLI** to update the specification for you. Use a clear prompt, for example:
|
||||
> "Now that `docs/07-reference-base44-api-export.md` is updated, can you analyze the changes and comprehensively update the `docs/03-backend-api-specification.md` file to match?"
|
||||
3. **Let the Gemini CLI** perform the comparative analysis and apply the necessary changes (adding fields, entities, integrations, etc.) to the specification file.
|
||||
|
||||
### Step 4: Validate and Commit the Changes
|
||||
|
||||
1. Give the changes in `03-backend-api-specification.md` a final review to ensure they are consistent.
|
||||
2. Commit the updated files to Git with a clear and descriptive message.
|
||||
```bash
|
||||
git add docs/
|
||||
git commit -m "docs: Update API documentation and specification from Base44 export"
|
||||
```
|
||||
|
||||
---
|
||||
@@ -1,10 +1,10 @@
|
||||
# Prompts pour l'IA de Base44
|
||||
# Prompts for the Base44 AI
|
||||
|
||||
Ce fichier contient des prompts standardisés à utiliser avec l'intelligence artificielle de la plateforme Base44. L'objectif est d'obtenir des informations précises et bien structurées sur l'API et les schémas de données du projet "KROW Workforce" afin de faciliter la construction d'intégrations et, si nécessaire, la migration future.
|
||||
This file contains standardized prompts for use with the Base44 platform's artificial intelligence. The goal is to obtain precise and well-structured information about the "KROW Workforce" project's API and data schemas to facilitate the development of integrations and, if necessary, future migration.
|
||||
|
||||
## 1. Prompt Principal : Demande de Documentation Complète (Version Discrète et Itérative)
|
||||
## 1. Main Prompt: Request for Complete Documentation (Discreet and Iterative Version)
|
||||
|
||||
*Utilisez ce prompt après chaque nouvel export du frontend depuis Base44. Il est formulé pour ne pas révéler l'intention de migration en demandant une mise à jour d'un document existant.*
|
||||
*Use this prompt after each new frontend export from Base44. It is phrased to avoid revealing the intention to migrate by requesting an update to an existing document.*
|
||||
|
||||
---
|
||||
|
||||
@@ -36,9 +36,9 @@ Thank you!
|
||||
|
||||
---
|
||||
|
||||
## 2. Prompt Secondaire : Demande de Schéma pour une Entité Spécifique
|
||||
## 2. Secondary Prompt: Request for a Specific Entity Schema
|
||||
|
||||
*Utilisez ce prompt si vous avez besoin de vérifier rapidement la structure d'une seule entité sans demander la documentation complète.*
|
||||
*Use this prompt if you need to quickly verify the structure of a single entity without requesting the full documentation.*
|
||||
|
||||
---
|
||||
|
||||
@@ -52,4 +52,4 @@ Please format the response as a JSON Schema or a Markdown table, including the f
|
||||
For example, for an entity named `Event`.
|
||||
```
|
||||
|
||||
---
|
||||
---
|
||||
@@ -1,55 +0,0 @@
|
||||
# Guide de Maintenance de la Documentation API
|
||||
|
||||
Ce document décrit la procédure à suivre pour mettre à jour la documentation de l'API et la spécification technique de notre backend après des modifications majeures sur la plateforme Base44.
|
||||
|
||||
Suivre ce processus est **essentiel** pour garantir que notre backend personnalisé sur GCP reste synchronisé avec les fonctionnalités du frontend.
|
||||
|
||||
## Quand Lancer cette Procédure ?
|
||||
|
||||
Vous devez suivre ce guide après chaque cycle de développement significatif sur la plateforme Base44, notamment après :
|
||||
- L'ajout de nouvelles entités ou de nouveaux champs de données.
|
||||
- La modification de la logique métier existante.
|
||||
- L'intégration de nouvelles fonctionnalités majeures dans l'interface utilisateur.
|
||||
|
||||
---
|
||||
|
||||
## Procédure de Mise à Jour
|
||||
|
||||
### Étape 1 : Obtenir la Documentation à Jour de Base44
|
||||
|
||||
1. **Ouvrez le fichier `docs/base44_prompts.md`**.
|
||||
2. Copiez le contenu du **"Prompt Principal"**.
|
||||
3. Collez ce prompt dans le chat de l'IA de Base44 pour lui demander de générer la documentation la plus récente.
|
||||
4. **Vérification :** L'IA doit retourner le contenu complet du fichier `API_documentation.md`. Si elle ne retourne qu'un résumé, utilisez le prompt simple suivant pour demander le contenu complet :
|
||||
```text
|
||||
Thank you for the summary. Please provide the entire, updated content of the API_documentation.md file now.
|
||||
```
|
||||
|
||||
### Étape 2 : Mettre à Jour le Fichier de Documentation Local (avec Gemini CLI)
|
||||
|
||||
Pour garantir un formatage propre et cohérent, il est recommandé d'utiliser Gemini CLI pour cette étape.
|
||||
|
||||
1. **Copiez le contenu brut** fourni par l'IA de Base44.
|
||||
2. **Donnez ce contenu à Gemini CLI** avec un prompt simple, par exemple :
|
||||
> "Voici la nouvelle documentation de l'API Base44. Peux-tu reformater ce contenu et mettre à jour le fichier `docs/API_documentation.md` ?"
|
||||
3. **Laissez Gemini CLI** gérer la création ou la mise à jour du fichier. Il s'assurera que les tableaux, les blocs de code et les en-têtes sont correctement formatés.
|
||||
|
||||
### Étape 3 : Mettre à Jour la Spécification de l'API GCP (avec Gemini CLI)
|
||||
|
||||
C'est l'étape la plus critique. Au lieu d'une comparaison manuelle fastidieuse, nous allons nous appuyer sur l'IA pour synchroniser notre plan de migration.
|
||||
|
||||
1. **Assurez-vous que l'Étape 2 est terminée** et que `docs/API_documentation.md` est à jour.
|
||||
2. **Demandez à Gemini CLI** de mettre à jour la spécification pour vous. Utilisez un prompt clair, par exemple :
|
||||
> "Maintenant que `docs/API_documentation.md` est à jour, peux-tu analyser les changements et mettre à jour de manière exhaustive le fichier `docs/api_specification.md` pour qu'il corresponde ?"
|
||||
3. **Laissez Gemini CLI** effectuer l'analyse comparative et appliquer les modifications nécessaires (ajout de champs, d'entités, d'intégrations, etc.) au fichier de spécification.
|
||||
|
||||
### Étape 4 : Valider et Commiter les Changements
|
||||
|
||||
1. Relisez une dernière fois les modifications apportées à `api_specification.md` pour vous assurer qu'elles sont cohérentes.
|
||||
2. Commitez les fichiers mis à jour dans Git avec un message clair et descriptif.
|
||||
```bash
|
||||
git add docs/API_documentation.md docs/api_specification.md docs/MAINTENANCE_GUIDE.md
|
||||
git commit -m "docs: Update API documentation and specification from Base44 export"
|
||||
```
|
||||
|
||||
---
|
||||
@@ -1,238 +0,0 @@
|
||||
# Spécification de l'API KROW Workforce (Migration GCP)
|
||||
|
||||
**Version :** 2.0
|
||||
**Date :** 11/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 exhaustive de l'API Base44 (v2.0) et a pour but de guider le développement du nouveau backend.
|
||||
|
||||
---
|
||||
|
||||
## 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` (Basée sur `base44.auth.me`)
|
||||
|
||||
| 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 personnalisé dans l'application (`admin`, `procurement`, `client`...) |
|
||||
| `...autres` | `any` | D'autres champs personnalisés peuvent être ajoutés. |
|
||||
|
||||
### Endpoints
|
||||
|
||||
#### `GET /auth/me`
|
||||
- **Description :** Récupère les informations du profil de l'utilisateur actuellement authentifié.
|
||||
- **SDK d'origine :** `base44.auth.me()`
|
||||
- **Réponse (200 OK) :** L'objet `User` complet.
|
||||
|
||||
#### `PUT /auth/me`
|
||||
- **Description :** Met à jour le profil de l'utilisateur actuel.
|
||||
- **SDK d'origine :** `base44.auth.updateMe(data)`
|
||||
- **Corps de la requête :** Un objet avec les champs de `User` à mettre à jour.
|
||||
- **Réponse (200 OK) :** L'objet `User` mis à jour.
|
||||
|
||||
---
|
||||
|
||||
## 2. Entités (Endpoints CRUD)
|
||||
|
||||
Pour chaque entité ci-dessous, les endpoints standards suivants sont à implémenter.
|
||||
|
||||
- `POST /{nom-entite}`: Crée une nouvelle entrée.
|
||||
- `GET /{nom-entite}`: Liste les entrées, avec support pour le filtrage et le tri via des query params.
|
||||
- `GET /{nom-entite}/{id}`: Récupère une entrée par son ID.
|
||||
- `PUT /{nom-entite}/{id}`: Met à jour une entrée par son ID.
|
||||
- `DELETE /{nom-entite}/{id}`: Supprime une entrée par son ID.
|
||||
|
||||
### 2.1. Event (`/events`)
|
||||
|
||||
**Description :** Gère les événements et les commandes de main-d'œuvre.
|
||||
|
||||
| Champ | Type | Description |
|
||||
| ----------------------- | --------- | ------------------------------------------------ |
|
||||
| `event_name` | `string` | Nom de l'événement (requis) |
|
||||
| `is_recurring` | `boolean` | Indique si l'événement est récurrent |
|
||||
| `recurrence_type` | `string` | `single`, `date_range`, `scatter` |
|
||||
| `recurrence_start_date` | `string` | Date de début de récurrence (ISO 8601) |
|
||||
| `recurrence_end_date` | `string` | Date de fin de récurrence (ISO 8601) |
|
||||
| `scatter_dates` | `array` | Tableau de dates (ISO 8601) pour `scatter` |
|
||||
| `business_id` | `string` | ID du client (`Business`) |
|
||||
| `business_name` | `string` | Nom du client |
|
||||
| `vendor_id` | `string` | ID du fournisseur (`Vendor`) |
|
||||
| `vendor_name` | `string` | Nom du fournisseur |
|
||||
| `hub` | `string` | Lieu/hub |
|
||||
| `contract_type` | `string` | `W2`, `1099`, `Temp`, `Contract` |
|
||||
| `po_reference` | `string` | Référence de bon de commande |
|
||||
| `status` | `string` | `Draft`, `Active`, `Pending`, `Assigned`, `Confirmed`, `Completed`, `Canceled` |
|
||||
| `date` | `string` | Date de l'événement (ISO 8601) |
|
||||
| `shifts` | `array` | Tableau d'objets `Shift` |
|
||||
| `addons` | `object` | Services additionnels |
|
||||
| `total` | `number` | Coût total |
|
||||
| `client_name` | `string` | Nom du contact client |
|
||||
| `client_email` | `string` | Email du contact client |
|
||||
| `client_phone` | `string` | Téléphone du contact client |
|
||||
| `notes` | `string` | Notes additionnelles |
|
||||
| `requested` | `number` | Nombre total de personnel demandé |
|
||||
| `assigned_staff` | `array` | Tableau d'objets de personnel assigné |
|
||||
|
||||
### 2.2. Staff (`/staff`)
|
||||
|
||||
**Description :** Gère les membres du personnel.
|
||||
|
||||
| Champ | Type | Description |
|
||||
| ------------------------- | --------- | ----------------------------------------- |
|
||||
| `employee_name` | `string` | Nom complet (requis) |
|
||||
| `vendor_id` | `string` | ID du fournisseur (`Vendor`) |
|
||||
| `vendor_name` | `string` | Nom du fournisseur |
|
||||
| `manager` | `string` | Nom du manager |
|
||||
| `contact_number` | `string` | Numéro de contact principal |
|
||||
| `phone` | `string` | Autre téléphone |
|
||||
| `email` | `string` | Adresse email |
|
||||
| `department` | `string` | `Operations`, `Sales`, `HR`, etc. |
|
||||
| `hub_location` | `string` | Lieu/hub de rattachement |
|
||||
| `address` | `string` | Adresse de l'employé |
|
||||
| `city` | `string` | Ville |
|
||||
| `position` | `string` | Poste/compétence principal(e) |
|
||||
| `position_2` | `string` | Poste/compétence secondaire |
|
||||
| `profile_type` | `string` | `Skilled`, `Beginner`, `Cross-Trained` |
|
||||
| `employment_type` | `string` | `Full Time`, `Part Time`, `On call`, etc. |
|
||||
| `english` | `string` | `Fluent`, `Intermediate`, `Basic`, `None` |
|
||||
| `rating` | `number` | Note de performance (0-5) |
|
||||
| `shift_coverage_percentage`| `number` | Pourcentage de shifts couverts (0-100) |
|
||||
| `cancellation_count` | `number` | Nombre d'annulations |
|
||||
| `no_show_count` | `number` | Nombre de non-présentations |
|
||||
| `total_shifts` | `number` | Nombre total de shifts assignés |
|
||||
| `reliability_score` | `number` | Score de fiabilité (0-100) |
|
||||
| `background_check_status` | `string` | `pending`, `cleared`, `failed`, `expired` |
|
||||
| `background_check_date` | `string` | Date du dernier contrôle (ISO 8601) |
|
||||
| `certifications` | `array` | Liste des certifications |
|
||||
|
||||
### 2.3. Vendor (`/vendors`)
|
||||
|
||||
**Description :** Gère les fournisseurs et leur onboarding.
|
||||
|
||||
| Champ | Type | Description |
|
||||
| ----------------------- | --------- | ----------------------------------------- |
|
||||
| `vendor_number` | `string` | Numéro de fournisseur (ex: `VN-####`) |
|
||||
| `legal_name` | `string` | Nom légal de l'entreprise (requis) |
|
||||
| `doing_business_as` | `string` | Nom commercial (DBA) |
|
||||
| `region` | `string` | `National`, `Bay Area`, etc. |
|
||||
| `primary_contact_email` | `string` | Email du contact principal (requis) |
|
||||
| `approval_status` | `string` | `pending`, `approved`, `suspended`, `terminated` |
|
||||
| `is_active` | `boolean` | Statut d'activité |
|
||||
| `tax_id` | `string` | Numéro d'identification fiscale (EIN) |
|
||||
| `business_type` | `string` | `Corporation`, `LLC`, etc. |
|
||||
| `insurance_certificate` | `string` | URL du certificat d'assurance |
|
||||
| `insurance_expiry` | `string` | Date d'expiration de l'assurance (ISO 8601) |
|
||||
| `w9_document` | `string` | URL du document W9 |
|
||||
| `coi_document` | `string` | URL du document COI |
|
||||
|
||||
### 2.4. VendorRate (`/vendor-rates`)
|
||||
|
||||
**Description :** Gère les grilles tarifaires des fournisseurs.
|
||||
|
||||
| Champ | Type | Description |
|
||||
| ----------------- | --------- | ----------------------------------------- |
|
||||
| `vendor_id` | `string` | ID du fournisseur (`Vendor`) |
|
||||
| `vendor_name` | `string` | Nom du fournisseur (requis) |
|
||||
| `category` | `string` | Catégorie de service (`Kitchen`, etc.) |
|
||||
| `role_name` | `string` | Nom du poste (requis) |
|
||||
| `employee_wage` | `number` | Salaire horaire de l'employé (requis) |
|
||||
| `client_rate` | `number` | Tarif horaire facturé au client (requis) |
|
||||
| `pricing_status` | `string` | `optimal`, `underpriced`, `overpriced` |
|
||||
| `is_active` | `boolean` | Statut d'activité |
|
||||
|
||||
### 2.5. Invoice (`/invoices`)
|
||||
|
||||
**Description :** Gère les factures.
|
||||
|
||||
| Champ | Type | Description |
|
||||
| ---------------- | -------- | ----------------------------------------- |
|
||||
| `invoice_number` | `string` | Numéro de facture (requis) |
|
||||
| `event_id` | `string` | ID de l'événement (`Event`) |
|
||||
| `business_name` | `string` | Nom du client (requis) |
|
||||
| `vendor_name` | `string` | Nom du fournisseur |
|
||||
| `amount` | `number` | Montant de la facture (requis) |
|
||||
| `status` | `string` | `Open`, `Paid`, `Overdue`, `Disputed`, etc. |
|
||||
| `issue_date` | `string` | Date d'émission (ISO 8601, requis) |
|
||||
| `due_date` | `string` | Date d'échéance (ISO 8601, requis) |
|
||||
| `paid_date` | `string` | Date de paiement (ISO 8601) |
|
||||
|
||||
### 2.6. Business (`/businesses`)
|
||||
|
||||
**Description :** Gère les entreprises clientes.
|
||||
|
||||
| Champ | Type | Description |
|
||||
| -------------- | -------- | ----------------------------------------- |
|
||||
| `business_name`| `string` | Nom de l'entreprise (requis) |
|
||||
| `contact_name` | `string` | Nom du contact principal (requis) |
|
||||
| `email` | `string` | Email de l'entreprise |
|
||||
| `phone` | `string` | Téléphone de l'entreprise |
|
||||
| `sector` | `string` | `Bon Appétit`, `Eurest`, etc. |
|
||||
| `rate_group` | `string` | `Standard`, `Premium`, etc. (requis) |
|
||||
| `status` | `string` | `Active`, `Inactive`, `Pending` |
|
||||
|
||||
---
|
||||
|
||||
*Note : Pour la concision, seules les entités les plus critiques ont été entièrement détaillées. La même structure (Schéma + Endpoints) doit être appliquée pour : `Certification`, `Team`, `Conversation`, `Message`, `ActivityLog`, `Enterprise`, `Sector`, `Partner`, `Order`, et `Shift` en se basant sur `API_documentation.md`.*
|
||||
|
||||
---
|
||||
|
||||
## 3. Services d'Intégration
|
||||
|
||||
### `POST /integrations/invoke-llm`
|
||||
- **Description :** Fait appel à un modèle de langage (Vertex AI).
|
||||
- **SDK d'origine :** `base44.integrations.Core.InvokeLLM(params)`
|
||||
- **Body :** `{ "prompt": "...", "response_json_schema": {...}, "file_urls": [...] }`
|
||||
- **Réponse (200 OK) :** `{ "result": "..." }`
|
||||
|
||||
### `POST /integrations/send-email`
|
||||
- **Description :** Envoie un email.
|
||||
- **SDK d'origine :** `base44.integrations.Core.SendEmail(params)`
|
||||
- **Body :** `{ "to": "...", "subject": "...", "body": "..." }`
|
||||
- **Réponse (200 OK) :** `{ "status": "sent" }`
|
||||
|
||||
### `POST /integrations/upload-file`
|
||||
- **Description :** Gère le téléversement de fichiers publics vers Google Cloud Storage.
|
||||
- **SDK d'origine :** `base44.integrations.Core.UploadFile({ file })`
|
||||
- **Requête :** `multipart/form-data`.
|
||||
- **Réponse (200 OK) :** `{ "file_url": "https://..." }`
|
||||
|
||||
### `POST /integrations/upload-private-file`
|
||||
- **Description :** Gère le téléversement de fichiers privés vers Google Cloud Storage.
|
||||
- **SDK d'origine :** `base44.integrations.Core.UploadPrivateFile({ file })`
|
||||
- **Requête :** `multipart/form-data`.
|
||||
- **Réponse (200 OK) :** `{ "file_uri": "gs://..." }`
|
||||
|
||||
### `POST /integrations/create-signed-url`
|
||||
- **Description :** Crée une URL d'accès temporaire pour un fichier privé.
|
||||
- **SDK d'origine :** `base44.integrations.Core.CreateFileSignedUrl(params)`
|
||||
- **Body :** `{ "file_uri": "...", "expires_in": 3600 }`
|
||||
- **Réponse (200 OK) :** `{ "signed_url": "https://..." }`
|
||||
|
||||
### `POST /integrations/extract-data`
|
||||
- **Description :** Extrait des données structurées d'un fichier (CSV, PDF...).
|
||||
- **SDK d'origine :** `base44.integrations.Core.ExtractDataFromUploadedFile(params)`
|
||||
- **Body :** `{ "file_url": "...", "json_schema": {...} }`
|
||||
- **Réponse (200 OK) :** `{ "status": "success", "output": [...] }`
|
||||
|
||||
### `POST /integrations/generate-image`
|
||||
- **Description :** Génère une image via une IA.
|
||||
- **SDK d'origine :** `base44.integrations.Core.GenerateImage(params)`
|
||||
- **Body :** `{ "prompt": "..." }`
|
||||
- **Réponse (200 OK) :** `{ "url": "https://..." }`
|
||||
@@ -1,180 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,138 +0,0 @@
|
||||
# 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.
|
||||
58
firebase.json
Normal file
58
firebase.json
Normal file
@@ -0,0 +1,58 @@
|
||||
{
|
||||
"hosting": [
|
||||
{
|
||||
"target": "dev",
|
||||
"public": "frontend-web/dist",
|
||||
"ignore": [
|
||||
"firebase.json",
|
||||
"**/.*",
|
||||
"**/node_modules/**"
|
||||
],
|
||||
"rewrites": [
|
||||
{
|
||||
"source": "**",
|
||||
"destination": "/index.html"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"target": "staging",
|
||||
"public": "frontend-web/dist",
|
||||
"ignore": [
|
||||
"firebase.json",
|
||||
"**/.*",
|
||||
"**/node_modules/**"
|
||||
],
|
||||
"rewrites": [
|
||||
{
|
||||
"source": "**",
|
||||
"destination": "/index.html"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"target": "prod",
|
||||
"public": "frontend-web/dist",
|
||||
"ignore": [
|
||||
"firebase.json",
|
||||
"**/.*",
|
||||
"**/node_modules/**"
|
||||
],
|
||||
"rewrites": [
|
||||
{
|
||||
"source": "**",
|
||||
"destination": "/index.html"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"target": "internal-launchpad",
|
||||
"public": "firebase/internal-launchpad",
|
||||
"ignore": [
|
||||
"firebase.json",
|
||||
"**/.*",
|
||||
"**/node_modules/**"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
0
firebase/dataconnect/schema/.keep
Normal file
0
firebase/dataconnect/schema/.keep
Normal file
12
firebase/firestore.rules
Normal file
12
firebase/firestore.rules
Normal file
@@ -0,0 +1,12 @@
|
||||
rules_version = '2';
|
||||
|
||||
service cloud.firestore {
|
||||
match /databases/{database}/documents {
|
||||
// Base rules: By default, lock down all access.
|
||||
// Data Connect will operate with admin privileges from the backend
|
||||
// and will not be subject to these client-side rules.
|
||||
match /{document=**} {
|
||||
allow read, write: if false;
|
||||
}
|
||||
}
|
||||
}
|
||||
0
firebase/functions/.keep
Normal file
0
firebase/functions/.keep
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 300 KiB |
102
firebase/internal-launchpad/assets/diagrams/invoice-workflow.svg
Normal file
102
firebase/internal-launchpad/assets/diagrams/invoice-workflow.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 164 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.6 MiB |
246
firebase/internal-launchpad/launchpad.html
Normal file
246
firebase/internal-launchpad/launchpad.html
Normal file
@@ -0,0 +1,246 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>KROW Launchpad</title>
|
||||
<!-- Bootstrap CSS -->
|
||||
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/css/bootstrap.min.css" rel="stylesheet">
|
||||
<!-- Bootstrap Icons -->
|
||||
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.8.1/font/bootstrap-icons.css">
|
||||
<!-- Custom CSS -->
|
||||
<style>
|
||||
body {
|
||||
background-color: #f8f9fa;
|
||||
}
|
||||
|
||||
.main-layout {
|
||||
display: grid;
|
||||
grid-template-columns: 280px 1fr;
|
||||
min-height: 100vh;
|
||||
}
|
||||
|
||||
.sidebar {
|
||||
background-color: #ffffff;
|
||||
border-right: 1px solid #dee2e6;
|
||||
padding: 1.5rem;
|
||||
}
|
||||
|
||||
.sidebar .nav-link {
|
||||
color: #495057;
|
||||
font-weight: 500;
|
||||
padding: 0.5rem 1rem;
|
||||
border-radius: 0.5rem;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 0.75rem;
|
||||
transition: color 0.2s, background-color 0.2s;
|
||||
}
|
||||
|
||||
.sidebar .nav-link.active,
|
||||
.sidebar .nav-link:hover {
|
||||
color: #0d6efd;
|
||||
background-color: #e9ecef;
|
||||
}
|
||||
|
||||
.sidebar-heading {
|
||||
font-size: 0.75rem;
|
||||
font-weight: 600;
|
||||
color: #6c757d;
|
||||
text-transform: uppercase;
|
||||
padding: 0 1rem;
|
||||
margin-top: 1.5rem;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
|
||||
.content-area {
|
||||
padding: 2rem;
|
||||
overflow-y: auto;
|
||||
}
|
||||
|
||||
#diagram-viewer {
|
||||
display: none; /* Hidden by default */
|
||||
height: calc(100vh - 4rem); /* Full height minus padding */
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
}
|
||||
|
||||
#diagram-container {
|
||||
cursor: grab;
|
||||
overflow: hidden;
|
||||
flex-grow: 1;
|
||||
position: relative;
|
||||
background-color: #ffffff;
|
||||
border-radius: 0.5rem;
|
||||
border: 1px solid #dee2e6;
|
||||
}
|
||||
#diagram-container:focus { outline: none; }
|
||||
|
||||
</style>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<div class="main-layout">
|
||||
<!-- Sidebar -->
|
||||
<nav class="sidebar">
|
||||
<div class="d-flex justify-content-center align-items-center mb-4">
|
||||
<img src="logo.svg" alt="Krow Logo" style="height: 60px;">
|
||||
</div>
|
||||
<div class="nav flex-column nav-pills">
|
||||
<a class="nav-link active" href="#" id="nav-home" onclick="showView('home', this)">
|
||||
<i class="bi bi-house-door"></i>Home
|
||||
</a>
|
||||
|
||||
<div class="sidebar-heading">Diagrams</div>
|
||||
|
||||
<a class="nav-link" href="#" onclick="showView('diagram', this, './assets/diagrams/high-level-overview.svg', 'Apps High-Level Overview')">
|
||||
<i class="bi bi-diagram-3"></i>High-Level Overview
|
||||
</a>
|
||||
<a class="nav-link" href="#" onclick="showView('diagram', this, './assets/diagrams/shift-lifecycle-workflow.svg', 'Core Workflow - Shift Lifecycle')">
|
||||
<i class="bi bi-arrow-repeat"></i>Shift Lifecycle
|
||||
</a>
|
||||
<a class="nav-link" href="#" onclick="showView('diagram', this, './assets/diagrams/invoice-workflow.svg', 'Invoice Workflow - Complete')">
|
||||
<i class="bi bi-receipt"></i>Invoice Workflow
|
||||
</a>
|
||||
<a class="nav-link" href="#" onclick="showView('diagram', this, './assets/diagrams/complete-workflow.svg', 'Complete Workflow')">
|
||||
<i class="bi bi-infinity"></i>Complete Workflow
|
||||
</a>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
<!-- Main Content Area -->
|
||||
<main class="content-area">
|
||||
<!-- View 1: Home Content -->
|
||||
<div id="home-view">
|
||||
<h2 class="mb-4">Welcome to the Project Launchpad</h2>
|
||||
<div class="row">
|
||||
<div class="col-lg-6">
|
||||
<div class="card shadow-sm mb-4">
|
||||
<div class="card-header"><h3>Applications</h3></div>
|
||||
<div class="card-body">
|
||||
<ul class="list-group list-group-flush">
|
||||
<li class="list-group-item d-flex justify-content-between align-items-center">
|
||||
<a target="_blank" href="#">Control Tower (Dev)</a>
|
||||
<span class="badge bg-primary rounded-pill">Dev</span>
|
||||
</li>
|
||||
<li class="list-group-item d-flex justify-content-between align-items-center">
|
||||
<a target="_blank" href="#">Control Tower (Staging)</a>
|
||||
<span class="badge bg-warning text-dark rounded-pill">Staging</span>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="col-lg-6">
|
||||
<div class="card shadow-sm mb-4">
|
||||
<div class="card-header"><h3>Access & Resources</h3></div>
|
||||
<div class="card-body">
|
||||
<div class="list-group list-group-flush">
|
||||
<a href="https://github.com/Oloodi/krow-workforce" target="_blank" class="list-group-item list-group-item-action">
|
||||
<div class="fw-bold">GitHub Repository</div>
|
||||
</a>
|
||||
<a href="https://chat.google.com/" target="_blank" class="list-group-item list-group-item-action">
|
||||
<div class="fw-bold">Team Communication</div>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- View 2: Diagram Viewer -->
|
||||
<div id="diagram-viewer">
|
||||
<div class="d-flex justify-content-between align-items-center mb-3">
|
||||
<h3 id="diagram-title" class="mb-0"></h3>
|
||||
<div class="btn-group">
|
||||
<button type="button" class="btn btn-outline-secondary" id="zoomInBtn" title="Zoom In"><i class="bi bi-zoom-in"></i></button>
|
||||
<button type="button" class="btn btn-outline-secondary" id="zoomOutBtn" title="Zoom Out"><i class="bi bi-zoom-out"></i></button>
|
||||
<button type="button" class="btn btn-outline-secondary" id="resetBtn" title="Reset View"><i class="bi bi-aspect-ratio"></i></button>
|
||||
</div>
|
||||
</div>
|
||||
<div id="diagram-container" tabindex="-1">
|
||||
<!-- SVG will be loaded here -->
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
</div>
|
||||
|
||||
<!-- JS -->
|
||||
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstrap.bundle.min.js"></script>
|
||||
<script src="https://cdn.jsdelivr.net/npm/@panzoom/panzoom@4.5.1/dist/panzoom.min.js"></script>
|
||||
|
||||
<script>
|
||||
const homeView = document.getElementById('home-view');
|
||||
const diagramViewer = document.getElementById('diagram-viewer');
|
||||
const diagramContainer = document.getElementById('diagram-container');
|
||||
const diagramTitle = document.getElementById('diagram-title');
|
||||
|
||||
const zoomInBtn = document.getElementById('zoomInBtn');
|
||||
const zoomOutBtn = document.getElementById('zoomOutBtn');
|
||||
const resetBtn = document.getElementById('resetBtn');
|
||||
|
||||
let panzoomInstance = null;
|
||||
|
||||
function setActiveNav(activeLink) {
|
||||
document.querySelectorAll('.sidebar .nav-link').forEach(link => {
|
||||
link.classList.remove('active');
|
||||
});
|
||||
activeLink.classList.add('active');
|
||||
}
|
||||
|
||||
async function showView(viewName, navLink, svgPath, title) {
|
||||
setActiveNav(navLink);
|
||||
if (panzoomInstance) panzoomInstance.destroy();
|
||||
diagramContainer.innerHTML = '';
|
||||
|
||||
if (viewName === 'home') {
|
||||
homeView.style.display = 'block';
|
||||
diagramViewer.style.display = 'none';
|
||||
} else if (viewName === 'diagram') {
|
||||
homeView.style.display = 'none';
|
||||
diagramViewer.style.display = 'flex';
|
||||
diagramTitle.textContent = title;
|
||||
diagramContainer.innerHTML = '<div class="d-flex justify-content-center align-items-center h-100"><div class="spinner-border" role="status"><span class="visually-hidden">Loading...</span></div></div>';
|
||||
|
||||
try {
|
||||
const response = await fetch(svgPath);
|
||||
if (!response.ok) throw new Error(`Network error: ${response.status}`);
|
||||
const svgContent = await response.text();
|
||||
|
||||
const parser = new DOMParser();
|
||||
const svgDoc = parser.parseFromString(svgContent, "image/svg+xml");
|
||||
const svgElement = svgDoc.querySelector('svg');
|
||||
|
||||
if (svgElement) {
|
||||
diagramContainer.innerHTML = '';
|
||||
diagramContainer.appendChild(svgElement);
|
||||
panzoomInstance = Panzoom(svgElement, {
|
||||
canvas: true,
|
||||
maxScale: 10,
|
||||
minScale: 0.3,
|
||||
zoomOnDblClick: false
|
||||
});
|
||||
diagramContainer.addEventListener('wheel', panzoomInstance.zoomWithWheel);
|
||||
diagramContainer.focus();
|
||||
} else {
|
||||
throw new Error('No SVG element found.');
|
||||
}
|
||||
} catch (error) {
|
||||
diagramContainer.innerHTML = `<div class="alert alert-danger m-3">Failed to load diagram: ${error.message}</div>`;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
zoomInBtn.addEventListener('click', () => { panzoomInstance?.zoomIn(); diagramContainer.focus(); });
|
||||
zoomOutBtn.addEventListener('click', () => { panzoomInstance?.zoomOut(); diagramContainer.focus(); });
|
||||
resetBtn.addEventListener('click', () => { panzoomInstance?.reset(); diagramContainer.focus(); });
|
||||
|
||||
document.addEventListener('DOMContentLoaded', () => {
|
||||
showView('home', document.getElementById('nav-home'));
|
||||
});
|
||||
</script>
|
||||
</body>
|
||||
|
||||
</html>
|
||||
45
firebase/internal-launchpad/logo.svg
Normal file
45
firebase/internal-launchpad/logo.svg
Normal file
@@ -0,0 +1,45 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Adobe Illustrator 29.2.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
viewBox="0 0 500 500" style="enable-background:new 0 0 500 500;" xml:space="preserve">
|
||||
<style type="text/css">
|
||||
.st0{fill:#24303B;}
|
||||
.st1{fill:#002FE3;}
|
||||
</style>
|
||||
<g>
|
||||
<g>
|
||||
<g>
|
||||
<path class="st1" d="M459.81,202.55c-5.03,0.59-9.08,4.49-10.36,9.38l-15.99,59.71l-16.24-56.3
|
||||
c-1.68-5.92-6.22-10.86-12.19-12.34c-1.58-0.39-3.11-0.54-4.64-0.49h-0.15c-1.53-0.05-3.11,0.1-4.64,0.49
|
||||
c-5.97,1.48-10.51,6.42-12.24,12.34l-3.6,12.53l-11.35,39.38l-7.9-27.54c-10.76-37.5-48.56-62.23-88.38-55.32
|
||||
c-33.26,5.82-57.05,35.68-56.99,69.48v0.79c0,4.34,0.39,8.73,1.13,13.18c0.18,1.02,0.37,2.03,0.6,3.03
|
||||
c1.84,8.31,10.93,12.73,18.49,8.8v0c5.36-2.79,7.84-8.89,6.42-14.77c-0.85-3.54-1.28-7.23-1.23-11.03
|
||||
c0-25.02,20.48-45.5,45.55-45.2c7.6,0.1,15.59,2.07,23.59,6.37c13.52,7.3,23.15,20.18,27.34,34.94l13.32,46.34
|
||||
c1.73,5.97,6.22,11,12.24,12.58c9.62,2.62,19-3.06,21.51-12.04l16.09-56.7l0.2-0.1l16.09,56.85c1.63,5.68,5.87,10.41,11.55,11.99
|
||||
c9.13,2.57,18.11-2.66,20.67-11.2l24.13-79.6C475.35,209.85,468.64,201.56,459.81,202.55z"/>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
<path class="st1" d="M83.32,255.47c-1.7-2.2-1.67-5.29,0.07-7.46l20.19-25.12c5.63-7.01,3.73-16.22-4.64-19.53
|
||||
c-5.29-2.09-10.99-0.39-14.28,3.75l-32.67,41v-32.24c0-6.63-4.77-12.68-11.38-13.34c-7.59-0.76-13.99,5.18-13.99,12.62v80.99
|
||||
c0,6.63,4.77,12.68,11.37,13.34C45.6,310.24,52,304.3,52,296.86v-12.73l11.65-13.22l25.12,33.69c2.33,3.12,5.99,4.95,9.87,4.95
|
||||
h1.4c10.23,0,16-11.75,9.74-19.85L83.32,255.47z"/>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
<path class="st1" d="M306.76,234.3c-5.42,2.52-8.26,8.45-7.01,14.3c0.64,3.01,0.98,6.14,0.98,9.35v0.3c0,0,0,0,0,0.05
|
||||
c0,24.5-19.71,44.44-44.09,45c-22.25-0.13-43.56-9.01-59.31-24.75l-14.06-14.06c0.43-0.17,0.9-0.3,1.33-0.49
|
||||
c5.92-2.62,10.51-6.32,13.77-11.2c1.94-2.91,3.23-6.22,4.02-9.84c0.08-0.37,0.15-0.75,0.22-1.12c0.14-0.79,0.29-1.57,0.38-2.39
|
||||
c0.16-1.38,0.27-2.79,0.27-4.27c0-6.86-1.63-12.73-4.89-17.62c-3.26-4.89-7.85-8.59-13.77-11.2c-5.92-2.62-12.88-3.9-20.82-3.9
|
||||
h-20.73c-12.58,0-22.75,10.21-22.75,22.75v71.65c0,7.01,5.68,12.68,12.73,12.68c3.5,0,6.66-1.43,8.98-3.7
|
||||
c2.27-2.32,3.7-5.48,3.7-8.98V267.9h5.04l28.63,28.63c20.27,20.27,47.65,31.75,76.28,32.13v0.1c0.33,0,0.65-0.05,0.97-0.05
|
||||
c0.16,0,0.32,0.02,0.48,0.02v-0.05c38.16-0.83,69.01-32.05,69.01-70.74c0-5.12-0.54-10.1-1.59-14.91
|
||||
C322.83,235.11,314.11,230.88,306.76,234.3z M173.15,246.68c-3.01,2.07-7.15,3.11-12.43,3.11h-8.98c-3.31,0-6.02-2.71-6.02-6.02
|
||||
v-14.41c0-3.31,2.71-6.02,6.02-6.02h9.53c5.23,0,9.28,1.09,12.09,3.26c2.86,2.17,4.25,5.58,4.25,10.21
|
||||
C177.59,241.3,176.11,244.56,173.15,246.68z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 2.8 KiB |
11
firebase/storage.rules
Normal file
11
firebase/storage.rules
Normal file
@@ -0,0 +1,11 @@
|
||||
rules_version = '2';
|
||||
|
||||
service firebase.storage {
|
||||
match /b/{bucket}/o {
|
||||
// Base rules: By default, lock down all access.
|
||||
// Client-side uploads will be managed via signed URLs generated by the backend if needed.
|
||||
match /{allPaths=**} {
|
||||
allow read, write: if false;
|
||||
}
|
||||
}
|
||||
}
|
||||
41
frontend-web/.gitignore
vendored
Normal file
41
frontend-web/.gitignore
vendored
Normal file
@@ -0,0 +1,41 @@
|
||||
# Dependencies
|
||||
/node_modules
|
||||
/.pnp
|
||||
.pnp.js
|
||||
|
||||
# Testing
|
||||
/coverage
|
||||
|
||||
# Vite
|
||||
.vite/
|
||||
.temp/
|
||||
|
||||
# Local Secrets
|
||||
.env
|
||||
.env.local
|
||||
.env.*.local
|
||||
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
lerna-debug.log*
|
||||
|
||||
# Build output
|
||||
dist
|
||||
dist-ssr
|
||||
*.local
|
||||
|
||||
# Editor directories and files
|
||||
.vscode/*
|
||||
!.vscode/extensions.json
|
||||
.idea
|
||||
.DS_Store
|
||||
*.suo
|
||||
*.ntvs*
|
||||
*.njsproj
|
||||
*.sln
|
||||
*.sw?
|
||||
72
frontend-web/README.md
Normal file
72
frontend-web/README.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# KROW Workforce - Frontend
|
||||
|
||||
Ce projet contient le code du frontend pour la plateforme KROW Workforce. Il a été initialement prototypé sur la plateforme low-code Base44 et est en cours de migration vers une infrastructure backend personnalisée sur Google Cloud Platform (GCP).
|
||||
|
||||
Ce `README.md` est le guide officiel pour l'équipe de développement. **NE PAS REMPLACER** ce fichier par celui fourni dans les exports de Base44.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Démarrage Rapide
|
||||
|
||||
Ce projet utilise un `Makefile` comme point d'entrée principal pour toutes les commandes courantes.
|
||||
|
||||
### Prérequis
|
||||
- Node.js (version LTS recommandée)
|
||||
- npm
|
||||
- `make` (généralement pré-installé sur Linux et macOS)
|
||||
|
||||
### Installation et Lancement
|
||||
1. **Installer les dépendances :**
|
||||
```bash
|
||||
make install
|
||||
```
|
||||
|
||||
2. **Lancer le serveur de développement :**
|
||||
```bash
|
||||
make dev
|
||||
```
|
||||
L'application sera disponible sur `http://localhost:5173`.
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Workflow d'Intégration des Mises à Jour de Base44
|
||||
|
||||
Pour intégrer les nouvelles modifications de l'UI faites par la cliente sur la plateforme Base44, suivez ce processus rigoureux :
|
||||
|
||||
### 1. Valider les Changements d'API
|
||||
Avant d'intégrer le nouveau code, il est impératif de mettre à jour notre documentation API et notre spécification technique. Suivez rigoureusement la procédure détaillée dans le fichier `docs/MAINTENANCE_GUIDE.md`.
|
||||
|
||||
### 2. Intégrer le Nouveau Frontend
|
||||
1. **Créez une branche dédiée** dans Git :
|
||||
```bash
|
||||
git checkout -b integration/base44-update-YYYY-MM-DD
|
||||
```
|
||||
2. **Placez l'export** de Base44 dans un dossier nommé `krow-workforce-web-export-latest` à côté du dossier de ce projet. La structure attendue est :
|
||||
```
|
||||
- /krow-workforce-web/ (ce projet)
|
||||
- /krow-workforce-web-export-latest/ (le nouvel export)
|
||||
```
|
||||
3. **Exécutez la commande d'intégration** pour copier automatiquement les fichiers `src` et `index.html` :
|
||||
```bash
|
||||
make integrate-export
|
||||
```
|
||||
4. **Exécutez le script de préparation** pour neutraliser le SDK Base44 et appliquer nos patchs :
|
||||
```bash
|
||||
make prepare-export
|
||||
```
|
||||
5. **Analysez les différences** avec `git diff`. Intégrez les nouveaux composants et les modifications de l'UI, mais **rejetez les changements** sur les fichiers que nous avons patchés (`src/api/base44Client.js`, `src/main.jsx`, `src/pages/Layout.jsx`) pour conserver notre environnement local fonctionnel. Vérifiez également `package.json` pour toute nouvelle dépendance à ajouter manuellement.
|
||||
6. **Testez l'application** en local avec `make dev` pour vous assurer que tout fonctionne comme prévu.
|
||||
7. Commitez vos changements.
|
||||
|
||||
---
|
||||
|
||||
## 📂 Structure du Projet
|
||||
|
||||
- `scripts/prepare-export.js`: Script de patching pour le workflow hybride.
|
||||
- `docs/`: Contient la documentation du projet (spécification de l'API, guides...).
|
||||
- `src/`: Code source de l'application.
|
||||
- `src/api/`: Contient la configuration du client API (actuellement mocké).
|
||||
- `src/components/`: Composants React réutilisables.
|
||||
- `src/pages/`: Vues principales de l'application, correspondant aux routes.
|
||||
- `src/lib/`: Utilitaires et bibliothèques partagées.
|
||||
- `Makefile`: Orchestrateur des commandes du projet.
|
||||
0
frontend-web/src/App.css
Normal file
0
frontend-web/src/App.css
Normal file
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user