608231f71c
flutter build web vert. Un seul helper, ImageCompressor, appelé par les DEUX chemins d'upload de resources_screen — c'est le motif qui a fait diverger Create et Upload côté serveur deux fois de suite : sur StoragePath en C1, sur le pré-vol de quota en C3. La compression se fait AVANT resourceCreate, pas avant l'upload. Le contrôle de quota livré en C3 porte sur sizeBytes à la création : le faire après aurait fait décider le serveur sur la taille du fichier d'origine, et compté au quota une image qui n'existe pas. Un quota qui compte 12x trop se remplit 12x trop vite. Deux écarts assumés par rapport à l'énoncé « 2560 px / JPEG q82 » : - Un PNG à canal alpha reste un PNG. Le passer en JPEG remplirait la transparence de noir, ce qui abîmerait logos et filigranes. Le redimensionnement s'applique dans les deux cas ; seul l'encodage diffère, et le type MIME suit — sinon Firebase servirait un JPEG étiqueté PNG. - Si le ré-encodage produit un fichier plus gros que l'original — ce qui arrive sur une petite image déjà bien encodée — l'original est conservé. Un échec de décodage renvoie aussi l'original plutôt que de bloquer l'upload. Défaut préexistant corrigé au passage : le second chemin d'upload ne renseignait sizeBytes ni avant ni après. Toutes les ressources créées par ce chemin comptent donc 0 octet au quota sur l'existant — même famille que ce que C1 et C3 ont trouvé côté serveur, et un argument de plus pour le backfill C2. image 4.2.0 déclarée explicitement : elle était déjà présente en transitif, dépendre d'un hasard de résolution pour une fonction utilisateur n'est pas tenable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
manager_app
A new Flutter application.
Getting Started
This project is a starting point for a Flutter application.
A few resources to get you started if this is your first Flutter project:
For help getting started with Flutter, view our online documentation, which offers tutorials, samples, guidance on mobile development, and a full API reference.
Ancienne version de generation = Model generation via command line
java -cp openapi-generator-cli-5.1.0.jar org.openapitools.codegen.OpenAPIGenerator generate -i swagger.yaml --additional-properties pubName=managerapi -g dart --enable-post-process-file
OPENAPI Generation cmd
flutter clean
flutter pub get
dart run build_runner build --delete-conflicting-outputs
Le fichier est dans le projet.
Publication sur docker
Avant de build en docker, il faut build en web => flutter build web
docker build -t manager-web .
Pour tester en local : docker run -d -p 8080:80 –name manager-web manager-web
Image tag: docker image tag manager-web registry.unov.be/myinfomate/manager:version-3.0.0 #registry.unov.be/mymuseum/manager:version-2.0.0
Docker push: docker image push registry.unov.be/myinfomate/manager:version-3.0.0 #registry.unov.be/mymuseum/manager:version-2.0.0