L'administration FiveM dispose de plusieurs systèmes de permissions : les contrôles txAdmin, les permissions FXServer ACE et les permissions utilisées par votre framework ou ressource d'administration. Identifiez celui qui gère l'action dont vous avez besoin avant d'accorder l'accès. L'approbation du propriétaire du serveur est requise.
Définissez le rôle du personnel
Listez les actions dont un assistant, un modérateur et un administrateur ont réellement besoin. Utilisez des comptes individuels et réservez les droits de propriétaire complets aux personnes responsables du serveur. Une personne qui traite les signalements de joueurs n'a généralement pas besoin de modifier la configuration ni d'exécuter des commandes arbitraires.
Choisissez le bon système de permissions
Pour le panneau web, utilisez les permissions documentées de txAdmin. Pour une commande de framework, vérifiez l'enregistrement de la commande et le guide des permissions actuel du framework. L'ouverture réussie d'un menu d'administration ne prouve pas que chaque action qu'il contient est autorisée.
ACE utilise des principals et des objets de permission. Copiez l'identifiant depuis les informations de joueur de votre propre serveur et vérifiez les objets requis par la ressource. Évitez d'accorder l'intégralité de l'espace de noms command simplement pour faire fonctionner une fonctionnalité. Ne collez pas les permissions de propriétaire ou de ressource d'un autre serveur dans votre configuration.
Appliquez une modification ciblée
Sauvegardez la configuration et enregistrez qui reçoit l'accès. Suivez la méthode d'attribution prise en charge par le framework installé. Utilisez les commandes ESX ou QBCore documentées uniquement lorsque votre version les enregistre ; les noms de groupe et la persistance diffèrent entre les frameworks et les forks.
Évitez les modifications directes de la base de données, sauf si la documentation maintenue pour cette intégration exacte les exige et que vous avez un plan de récupération. Un nom de table générique copié d'un ancien guide vRP n'est pas une preuve de votre schéma.
Testez les actions autorisées et refusées
Utilisez un compte de test dédié au personnel. Confirmez que l'action prévue aboutit, qu'une action plus privilégiée est refusée et qu'un joueur ordinaire se voit toujours refuser l'accès. Reconnectez-vous et effectuez le redémarrage habituel du serveur pour vérifier la persistance. Vérifiez les journaux et consignez la modification.
Si l'accès échoue, vérifiez à nouveau la configuration en cours, l'identifiant, l'héritage et l'enregistrement de la commande. Des redémarrages répétés ne corrigent pas un mauvais principal ou une règle de permission dans la mauvaise ressource.
Maintenez l'accès
Supprimez les permissions lorsqu'un membre du personnel quitte l'équipe, examinez périodiquement les accès élevés et conservez une voie de récupération indépendante. Consignez les décisions de modération avec les preuves et un processus de révision.