Tests des inventaires¶

Vérifier aussi le badge immobilier système, son transfert physique, sa révocation et la protection contre empty/remove générique selon Tests immobilier et bâtiments.

Ajouter aux non-régressions la protection de vehicle_key contre /giveitem, catalogue, renommage, retrait et vidage, tout en conservant don/drop/stockage et UUID.

INV-KEY-001 — Doubles physiques indépendants¶

Prérequis : un véhicule enregistré, son propriétaire, un second personnage et deux clés actives créées par le serrurier.

Garder les deux clés dans l'inventaire du propriétaire et utiliser successivement U, le moteur et chacune des instances depuis la grille.
Transférer un premier double au second personnage puis rejouer les actions des deux côtés.
Transférer le dernier double et falsifier ensuite l'UUID de l'une des clés pour l'ancien détenteur.

Attendu : deux clés dans un même inventaire restent utilisables sans erreur ; après le premier transfert, les deux personnages possèdent un accès valide ; après le second, seul le destinataire reste autorisé. L'UUID déplacé ou falsifié est refusé pour l'ancien détenteur, sans qu'une autre clé valide ne serve de fallback implicite.

Stockages partagés¶

INV-STO-001 — Création et liaison de props¶

Prérequis : admins possédant séparément les permissions de lecture, édition et suppression.

Depuis F10 puis /placestorage, créer un stockage nommé de 25 slots et 100 kg en plaçant un nouveau prop_box_wood05a.
Créer un second stockage en sélectionnant un prop existant, puis annuler une troisième sélection.
Rejouer sans ADMIN_ALLOW_EDIT_STORAGES, avec nom vide, limites négatives et modèle invalide.

Attendu : les deux stockages valides apparaissent immédiatement chez tous les joueurs, le prop lié n'est jamais dupliqué et l'annulation/les entrées invalides ne persistent rien. Sans permission, aucun placement ne démarre et F9 affiche le refus.

Contrôler également que World Edit ne se rouvre qu'après la confirmation, qu'une erreur API est visible en jeu et dans F9, et qu'une absence de réponse pendant dix secondes affiche un timeout. Simuler enfin une réponse interrompue après commit : la synchronisation suivante doit faire apparaître le stockage une seule fois, sans recréer périodiquement les props inchangés.

INV-STO-002 — Interface, limites et concurrence¶

Prérequis : un stockage contenant plusieurs objets, deux joueurs et des limites finies.

Ouvrir simultanément le stockage ; vérifier l'inventaire personnel à gauche et son nom à droite.
Glisser vers des cases vides et occupées dans les deux sens, puis réorganiser deux cases du stockage.
Dépasser successivement slots et poids, puis déclencher deux transferts avec la même révision.
Tenter d'ouvrir le stockage depuis une position distante avec un événement client forgé.

Attendu : la grille droite conserve cinq colonnes et des cases carrées ; déplacements et échanges valides persistent pour les deux joueurs. Les dépassements et la seconde mutation concurrente sont refusés sans duplication. L'ouverture distante n'atteint jamais le service d'inventaire.

INV-STO-003 — Administration et suppression¶

Prérequis : trois rôles avec respectivement ADMIN_ALLOW_VIEW_STORAGES, ADMIN_ALLOW_EDIT_STORAGES et ADMIN_ALLOW_DELETE_STORAGES.

Vérifier la liste avec /adminstorages, modifier nom/slots/poids et déplacer avec F10 puis /movestorage <id>.
Réduire les limites sous le contenu actuel, puis supprimer avec F10. Avec la commande, exécuter d'abord /delstorage <id> et reprendre ensuite /delstorage <id> confirm.
Rejouer chaque action avec uniquement les deux autres permissions.

Attendu : chaque permission n'autorise que son périmètre, une limite incompatible est refusée, les modifications sont visibles sans redémarrage et la suppression confirmée retire prop, interaction, inventaire et contenu. Chaque mutation apparaît dans l'audit admin.

Dépôts au sol¶

Ouvrir avec TAB et vérifier l'inventaire personnel à gauche et le dépôt à droite, sans carton dans le monde.
Glisser le premier objet vers le dépôt et vérifier que le carton apparaît alors devant le joueur.
Reprendre le dernier objet et vérifier que le carton disparaît immédiatement, même avant la fermeture.
Pendant cette suppression, vérifier dans F8 l'absence d'erreur d'export remove/unregister, puis répéter sur plusieurs dépôts et plusieurs clients.
Glisser un objet dans les deux sens, puis répéter simultanément à deux joueurs sans duplication.
Fermer à vide et vérifier la suppression du prop et de la donnée.
Fermer avec un objet puis rouvrir le carton par son interaction avec un autre joueur.
Après un redémarrage, vérifier l'état inactif et l'absence du prop ; réactiver avec ADMIN_ALLOW_MANAGE_DROPS.
Sans réactivation, effectuer un second redémarrage et vérifier la suppression complète.
Consulter puis supprimer un dépôt dans le web admin et vérifier la disparition en jeu.
Vérifier le refus et l'absence du menu sans la permission dédiée.
Comparer les deux consoles : vérifier la même structure AR, les mêmes cases carrées, cinq colonnes, télémétrie et panneau de scan, sans régression visuelle sur l'inventaire personnel.
Effectuer plusieurs transferts consécutifs avec plusieurs dépôts existants : vérifier que l'interface se met à jour dès la réponse du transfert et que seul le prop concerné apparaît ou disparaît.
Après ces transferts ciblés, attendre la synchronisation périodique et vérifier qu'elle ne change ni le contenu, ni les révisions, ni les props correctement affichés.
Déposer successivement des objets dans des cases vides non contiguës, notamment 17 et 25 ; fermer puis rouvrir et vérifier que chaque position est conservée.
Déposer sur une case déjà occupée : vérifier que les deux objets échangent leurs inventaires et leurs emplacements, puis rouvrir pour confirmer la persistance.
Préparer un échange qui dépasserait la limite de poids de l'inventaire source, puis de l'inventaire cible : vérifier dans les deux sens le refus, le rafraîchissement cohérent et l'absence de duplication.
Tenter un dépôt au-delà de la capacité configurée : vérifier le refus et l'absence de modification.
Modifier drop.slots, créer un nouveau dépôt et vérifier que sa matrice et sa limite API reprennent cette valeur ; remettre ensuite la valeur par défaut à 25.
Dans un même dépôt, déplacer un objet de la case 17 vers la case 22 vide et vérifier la persistance après réouverture.
Déplacer ensuite cet objet sur une case occupée et vérifier l'échange des deux positions, sans changement de quantité ou de poids.
Ouvrir le même dépôt à deux joueurs, le réorganiser depuis l'un et vérifier la mise à jour immédiate chez l'autre.
Envoyer deux déplacements concurrents avec la même révision : vérifier qu'un seul aboutit et que l'autre reçoit un conflit sans duplication.

Catalogue dynamique¶

INV-012 — Création dynamique d'un objet¶

Prérequis : un admin avec ADMIN_ALLOW_ITEM_CREATE, un autre sans cette permission et un personnage de recette.

Dans World Edit > Catalogue d'objets, créer un objet avec un identifiant inédit, une image locale puis répéter avec une image HTTPS.
Depuis Communauté > Inventaires, ajouter immédiatement chaque objet au personnage par le menu contextuel existant.
Rejouer avec un identifiant dupliqué, un identifiant invalide et sans permission.

Attendu : les créations valides apparaissent sans redémarrage et peuvent être attribuées avec leurs métadonnées et images ; doublon, données invalides et absence de permission sont refusés sans écriture.

INV-013 — Suppression d'une définition¶

Prérequis : le même objet dynamique présent dans plusieurs inventaires et un admin avec ADMIN_ALLOW_ITEM_DELETE.

Supprimer la définition depuis le catalogue et confirmer l'avertissement.
Actualiser tous les inventaires concernés puis tenter de redonner l'identifiant supprimé.
Rejouer sans permission et avec un identifiant inconnu.

Attendu : la définition et toutes ses instances disparaissent atomiquement, les révisions des inventaires touchés progressent, l'attribution ultérieure renvoie item_not_found et les appels non autorisés ou inconnus ne modifient rien.

INV-014 — Catégories, filtre et édition en direct¶

Prérequis : plusieurs objets répartis dans au moins trois catégories, un objet déjà présent dans l'inventaire ouvert d'un joueur et un admin avec ADMIN_ALLOW_ITEM_EDIT.

Contrôler le regroupement par catégorie, puis saisir successivement une partie du nom, de l'ID et de la description dans le filtre.
Modifier catégorie, libellé, poids, pile, description et image de l'objet déjà distribué.
Garder l'inventaire joueur ouvert au moins cinq secondes, puis contrôler sa fiche.
Rejouer sans permission, avec une catégorie invalide et tenter de modifier l'identifiant.

Attendu : chaque filtre ne conserve que les correspondances attendues, les groupes se mettent à jour après édition et la nouvelle définition apparaît dans FiveM sans redémarrage. L'ID reste immuable et les appels non autorisés ou invalides sont refusés sans mutation.

INV-015 — Accès depuis la fiche personnage¶

Prérequis : un personnage avec inventaire, un admin lecteur, un admin éditeur et un admin sans ADMIN_ALLOW_VIEW_INVENTORY.

Dans les admins web et en jeu, rechercher puis ouvrir la fiche du même personnage.
Cliquer Voir l'inventaire, contrôler la sous-section active et le personnage chargé.
Rejouer avec le lecteur, l'éditeur et l'admin sans permission.

Attendu : le raccourci ouvre la grille existante sur la bonne cible sans nouvelle recherche ; le lecteur ne voit aucune mutation, l'éditeur conserve toutes les actions existantes et le bouton est absent sans permission. Un appel forgé reste refusé côté API.

Données et interface personnelle¶

INV-001 — Création et configuration personnelle¶

Prérequis : personnage actif sans inventaire.

Ouvrir avec Tab et contrôler la grille.
Modifier en recette slots/poids/colonnes/touche dans config.json, redéployer et rouvrir.

Attendu : l'inventaire est créé une seule fois, les limites synchronisées valent 25/15 par défaut, la grille a cinq colonnes et les cinq premiers slots affichent & é " ' (.

INV-002 — Catalogue et piles¶

Donner chacun des dix items, puis dépasser la taille d'une pile avec un item empilable et avec un item unique.

Attendu : label, description, poids et image correspondent au catalogue ; les piles sont complétées jusqu'à leur maximum et les objets non empilables occupent chacun un slot. Pour vehicle_key, vérifier dans l'inventaire joueur, l'inventaire F10 et la console web la télécommande futuriste à noyau turquoise : fond transparent, objet entièrement visible, contraste suffisant, même rendu sur les trois surfaces et absence de l'ancien visuel de couteau multifonction.

INV-003 — Déplacement et renommage¶

Renommer une instance, la glisser vers un slot vide puis vers un slot occupé, et effectuer la même opération simultanément depuis une interface admin.

Attendu : le label d'instance persiste, le premier déplacement change le slot, le second échange les deux objets et une révision obsolète reçoit 409 puis recharge l'état autoritatif.

INV-004 — Ouverture et accès rapide¶

Ouvrir/fermer avec Tab et Échap, utiliser un objet par bouton, double clic puis par chacune des cinq touches physiques 1 à 5 sur clavier AZERTY.

Attendu : aucun focus NUI ne reste après fermeture ; le bon item déclenche une seule fois medusa:inventory:useItem. Un slot vide affiche une erreur sans mutation.

Contrôler également l'interface devant une scène claire, pendant son ouverture puis après sa fermeture. Le monde doit rester visible autour des trois modules translucides, aucun voile noir ne doit couvrir l'écran et la fermeture doit rendre la NUI entièrement transparente.

Vérifier en 1920×1080, 1280×720 et dans un format ultralarge que toute la console reste dans la moitié gauche. Chaque slot occupé doit montrer image, nom d'instance et quantité ; un nom long doit être tronqué sans déformer la grille, tout en restant complet au survol et pour le libellé accessible. Contrôler enfin les bordures, scanlines, jauges de slots/poids et états lumineux au survol, à la sélection et pendant un glisser-déposer. Mesurer plusieurs slots occupés et vides aux trois résolutions : leur largeur et leur hauteur doivent être identiques à un pixel près. Si les cinq lignes dépassent la hauteur disponible, seule la matrice doit défiler et aucun slot ne doit être aplati.

Administration et sécurité¶

INV-005 — `/giveitem` et dépassement volontaire¶

Avec ADMIN_ALLOW_GIVE_ITEM, exécuter /giveitem COMPTE water 60, puis dépasser 25 slots avec des téléphones. Rejouer avec mauvais compte, item, quantité et sans permission.

Attendu : poids et slots peuvent dépasser 15/25, la cible connectée est rafraîchie, l'audit contient compte/item/quantité et tous les cas invalides sont refusés sans écriture.

INV-006 — Consultation web et en jeu¶

Tester la recherche et l'ouverture avec uniquement ADMIN_ALLOW_VIEW_INVENTORY, puis sans cette permission, dans les deux admins.

Attendu : le lecteur voit slots, poids, révision et instances mais tous les contrôles de mutation sont absents/désactivés ; un appel forgé reste refusé côté API.

INV-007 — Édition et vidage¶

Avec ADMIN_ALLOW_EDIT_INVENTORY, modifier label, quantité et slot, retirer une instance puis vider l'inventaire depuis les deux admins. Annuler une confirmation de vidage et rejouer sans permission.

Attendu : chaque réponse et chaque client convergent vers l'état PostgreSQL, l'annulation ne change rien, le vidage supprime toutes les instances et les actions en jeu sont auditées.

INV-008 — Concurrence anti-duplication¶

Ouvrir le même inventaire depuis le joueur et deux admins. Lancer simultanément déplacements, éditions et grants sur les mêmes slots/piles, puis répéter sous latence artificielle.

Attendu : une seule transaction modifie une révision donnée, aucun item ni quantité n'est créé deux fois, aucune pile ne dépasse sa définition et tous les clients convergent après actualisation.

INV-009 — Persistance et suppression du personnage¶

Remplir et renommer l'inventaire, reconnecter le joueur puis recréer FiveM/API sans supprimer les volumes. Enfin, supprimer le personnage de recette.

Attendu : contenu, slots et labels survivent aux redémarrages ; supprimer le personnage supprime son inventaire et toutes ses instances en cascade.

INV-010 — Grilles admin et menus contextuels¶

Prérequis : un inventaire contenant des piles et des items uniques, un admin éditeur et un admin disposant uniquement du droit de lecture.

Ouvrir le même inventaire dans les admins web et en jeu et contrôler les 25 slots carrés.
Par clic droit, ajouter un item sur un slot vide, modifier une pile, en retirer une partie, retirer la pile entière, renommer puis supprimer une instance.
Rejouer un ajout inconnu, une quantité invalide et deux mutations avec la même révision.
Rejouer tous les clics droits avec l'admin en lecture seule et forger une requête de mutation.

Attendu : les deux grilles restent synchronisées ; les opérations valides produisent les quantités attendues, un retrait total supprime l'instance, les entrées invalides sont refusées, la seconde mutation concurrente reçoit un conflit et aucun menu/action d'édition n'est disponible en lecture seule.

INV-011 — Glisser-déposer entre slots¶

Saisir successivement l'image, le libellé et le fond d'un slot, puis déposer l'objet sur le slot vide adjacent, sur un slot vide séparé par plusieurs emplacements et sur un slot occupé.

Attendu : tout le slot constitue la source du geste, le déplacement vers un emplacement vide réussit, la cible occupée échange atomiquement les deux items, les états lumineux source/cible sont visibles, le fantôme suit le curseur et aucun clic parasite n'utilise l'objet ni ne bloque le dépôt.

INV-012 — Réconciliation de drops résiliente¶

Démarrer la ressource avec l'API temporairement coupée, capturer chaque requête de réconciliation, puis restaurer l'API. Redémarrer ensuite la ressource et comparer les tokens.

Attendu : les tentatives d'un même démarrage partagent exactement le même boot_token, la réconciliation ne s'exécute logiquement qu'une fois et le redémarrage suivant produit un nouveau token. Aucun drop n'est dupliqué et aucun log ne contient undefined.

INV-013 — Résolveurs Cfx et arbitrage TAB véhicule¶

Exécuter node --test tests/inventory-context-resolvers.test.mjs tests/vehicle-compartment-runtime.test.mjs depuis fivem/ et vérifier les fonctions locales, références Cfx, entrées invalides, exception protégée, priorité, cycle start/stop/restart, ordre garage et réparation bornée des state bags.
En jeu, démarrer Inventaire avant Véhicules, puis l'ordre inverse. Redémarrer successivement les deux ressources et appuyer sur TAB après chaque séquence.
Tester conducteur et passager avant, siège arrière, coffre enregistré, coffre PNJ, véhicule verrouillé, deux coffres à distance équivalente puis une zone sans véhicule.
Sur un véhicule enregistré, refaire conducteur/passager/coffre avant rangement, après sortie de garage, après restauration, puis après restart isolé d'Inventaire et de Véhicules dans les deux ordres. Retirer temporairement le state bag de capacités en recette contrôlée et appuyer plusieurs fois sur TAB pendant cinq secondes.
Ouvrir/fermer vingt fois rapidement, fermer pendant les 250 ms de surveillance, puis ouvrir immédiatement un autre compartiment. Refaire ensuite distance, vitesse, verrouillage et sortie du siège avant sur un cycle normal.

Attendu : une seule entrée medusa-vehicles est active ; les sièges avant ouvrent la boîte à gants, l'arrière suit le parcours personnel, une cible coffre unique ouvre le bon stockage et les refus/ambiguïtés affichent un message sans ouvrir le personnel. Sans cible, le parcours historique fonctionne. Une capacité absente produit une seule resynchronisation bornée et un message visible, puis le bon compartiment à l'essai suivant. F8 ne contient ni double dispatch ni spam après restart. Une itération obsolète ne lit jamais un activeCompartment fermé et ne ferme pas le compartiment ouvert entre-temps ; la boucle reste active pour les sécurités du cycle suivant.

Contenants énergie¶

Vérifier les quatre produits thermiques dans le bidon universel : remplissage, changement seulement à vide, livraison partielle, transfert, drop, coffre, boîte à gants, restart, poids 2/8/14 kg et metadata falsifiée. Vérifier le pack EV à 0/20/21 %, sur thermique, en double clic et API coupée : l'instance disparaît uniquement après un succès complet. Depuis une base 0039, 0040 doit réactiver les deux définitions sans recréer les anciennes instances supprimées. Voir Tests du système énergie.