File Browser Quantum
dans votre projet Git.
Déposer, éditer et partager des fichiers avec un compte et des partages protégés.
Vérifié dans la portée indiquéeRelevé des preuves : . Qualification limitée aux versions et opérations décrites.
À quoi ça sert
Déposer, éditer et partager des fichiers avec un compte et des partages protégés.
Cette recette compose des capacités réutilisables. Votre code et vos personnalisations restent dans votre dépôt ; les paramètres publiés décrivent comment construire et exécuter le projet.
Ce qui a été vérifié
Quantum 1.5.5-stable corrigée → 1.5.6-stable ; fichiers, compte et partages conservés sans serveur SQL.
- Quantum ; correctifs officiels dans la version de départ
1.5.5-stable corrigée → 1.5.6-stable
Vérifié dans la portée indiquée
- CréationVérifié dans la portée indiquée
Compte, téléchargement identique, édition et partage protégé vérifiés ; accès anonyme refusé et métadonnées publiques sans contenu privé.
- Mise à jourVérifié dans la portée indiquée
Mêmes compte, fichier, partages et identités de stockage conservés ; modification puis nouveau fichier vérifiés.
- Sauvegarde ou exportPartiel
Document et dépôt Git exportés ; archive froide des données et fichiers sur le même volume, avec empreinte contrôlée.
- RestaurationNon vérifié
Aucune restauration qualifiée.
- Création par configuration N3Vérifié dans la portée indiquée
Création par code Git personnalisé et configuration N3 ; fichier et partage protégé vérifiés, aucun LLM sur le push qualifié.
- Mise à jour par configuration N3Vérifié dans la portée indiquée
Mise à jour par configuration dans le même projet ; compte et protection du partage conservés, fichier modifié, aucun LLM sur le push qualifié.
Le résultat d’une opération n’étend pas automatiquement la qualification à une autre version, un plugin ou une migration. Les scénarios ci-dessous ne constituent pas une certification indépendante ni une offre commerciale générale.
- Version de départ avec six fichiers correctifs officiels ; migration majeure et passage depuis le fournisseur historique non qualifiés.
- linux/amd64, CGO désactivé ; aperçus MuPDF/FFmpeg et intégrations bureautiques non qualifiés.
- Copie froide complète sur le même volume ; export externe de cette archive et restauration non qualifiés.
- Scénarios vérifiés, sans certification indépendante ni disponibilité générale déduite.
Prérequis et composition
Un projet autorisé, le code complet avec ses dépendances verrouillées, et la configuration de la recette compatible avec la version retenue.
Les ressources N0 sont résolues via les capacités ci-dessus. Les services et bindings requis dépendent de la recette ; un fournisseur existant n’implique pas la création d’un nouveau serveur par application.
Les données persistantes et identités initiales se préparent avant le premier déploiement. Les secrets se gèrent dans le projet, sans les écrire dans Git.
Choisir le parcours adapté
Consultez les versions et préparez votre dépôt avec la configuration publiée. La disponibilité et les conditions de votre projet se confirment avant installation.
Cette fiche n’annonce pas de bouton d’installation en un clic pour une recette non mise à disposition dans votre projet.
Livrer depuis Git
- Récupérez la configuration complète publiée pour la recette et sa version ; adaptez uniquement ses paramètres autorisés.
- Versionnez le code complet, les dépendances et
paas.tomldans le dépôt relié à l’application. - Poussez sur la branche de livraison configurée. Le commit exact passe par construction, tests, scan, inventaire logiciel, signature et admission.
- Vérifiez la version servie et un usage métier. Pour une mise à jour, contrôlez aussi l’identité et la conservation des données.
# Depuis le dépôt déjà relié à votre projet, sur sa branche de livraison
git add paas.toml
git commit -m "Configure la recette applicative"
git push paas mainL’exemple suppose que le remote paas et la branche main correspondent à votre projet. Le code client et les verrous de dépendances doivent eux aussi être versionnés.
Personnaliser et aller plus loin
Paramètres, thèmes, plugins et code métier évoluent dans le même projet. Une version ou une option compatible réutilise le module existant ; une responsabilité absente exige une évolution de capacité avec ses propres tests.
Chaque personnalisation repasse les contrôles. Un plugin supplémentaire n’hérite pas de la qualification de cette fiche. Les versions, opérations et paramètres du contrat restent consultables dans le détail du module.
Prochaines étapes
Une configuration connue et compatible suit le parcours déterministe, sans appel de modèle. Une configuration manquante ou un échec réparable ouvre une correction bornée ; les changements restent visibles dans Git.