Canal VR
- L'entree VR affiche VrScreen au lieu de « non configuree » : sous-onglet
Configuration (AppConfigurationLinkScreen reutilise) et sous-onglet Casques
(pincode d'appairage, etat, batterie, version, dernier vu).
- Le dialogue de plan SuperAdmin porte aussi les canaux et les add-ons
(assistant, contenu immersif). Activer un canal cree son
ApplicationInstance s'il n'existe pas ; le desactiver ne supprime rien.
Medias immersifs
- Types Image360, Video360, Model3D : icones, libelles, extensions, apercu
dans la Mediatheque et facettes.
- Au depot, la pastille de type bascule Image <-> Image 360 et
Video <-> Video 360 : rien dans un .jpg ne dit qu'il est
equirectangulaire. Un .glb est reconnu seul.
- ImageCompressor ne touche plus aux 360 ni aux GLB, sur les deux chemins
d'upload : ramenee a 2560 px, une equirectangulaire devient illisible dans
un casque.
Scene3D
- Nouveau type de section (famille des lieux) et son ecran de configuration :
modele, mode objet/decor, points d'interet.
- Fond immersif d'une configuration, visible si l'instance a l'add-on : le
type est deduit de la ressource choisie, avec une image de repli.
Client API edite a la main en miroir du backend : SectionScene3DApi,
Scene3DDTO, ImmersiveBackgroundDTO, Position3D, AppType sur les devices,
ResourceType etendu. Libelles FR/EN/NL.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
