Rôles et autorisations : configuration et usage quotidien

Les rôles système livrés et ce qu’ils ouvrent déjà

À la première ouverture de l’onglet, Home Builder Software inscrit pour cette entreprise les rôles fournis : Administrator, Bauleitung, Büro und Rechnungswesen, Einkauf und Vergabe, Lohnbuchhaltung et Baustelle, chacun avec sa couleur. Ils existent pour que personne n’ait à dessiner un modèle d’accès avant d’inviter le deuxième collaborateur. La conduite de travaux gère les projets et achète, le bureau facture, les achats attribuent et commandent et lisent les chiffres financiers, factures clients comprises, sans pouvoir en écrire une, la paie valide les heures, le chantier saisit sur place.

Un rôle système se renomme, se recolore et se retaille, mais ne se supprime pas, et le rôle administrateur conserve la liste complète quelles que soient les cases envoyées par le formulaire. C’est voulu : une entreprise qui viderait son propre rôle administrateur se fermerait l’espace paramètres sans retour possible. Chaque carte affiche le nom du rôle, sa clé technique et le nombre d’autorisations actuellement portées, si bien qu’une découpe fautive se repère avant toute attribution.

Composer un rôle avec nom, couleur et clés d’autorisation

Créer un rôle demande un nom d’au plus 120 caractères, une couleur en hexadécimal à six chiffres et les cases des autorisations. La clé technique est dérivée du nom et rendue unique automatiquement, de sorte que deux rôles appelés Chef de chantier n’entrent pas en conflit. Seules les 17 clés connues sont acceptées, le reste étant écarté par la validation. Une modification agit dès la même réponse, le cache d’autorisations de la requête étant vidé à l’enregistrement.

Les paires méritent d’être connues au moment de cocher. Un droit de gestion emporte toujours sa consultation : records.write couvre records.view, finance.manage couvre finance.view, workforce.manage couvre workforce.view, et projects.manage comme site.write couvrent projects.view. Cocher la moitié écriture suffit donc. Achats et paie forment des clés distinctes parce que commander du matériel n’est pas écrire une facture client, et payer les salaires n’est pas décider qui travaille où.

Attribuer un rôle et limiter une personne à certains chantiers

L’attribution est un dialogue par personne, ouvert depuis la grille de cet onglet ou depuis Changer le rôle dans la liste des utilisateurs. Le quotidien se résume à cela : un collaborateur, un rôle, un enregistrement. Personne ne modifie son propre rôle, et seul un administrateur accorde ou retire le rôle administrateur, afin que le droit de gérer les paramètres ne devienne pas discrètement la propriété du mandant. Déplacer le dernier administrateur est refusé.

Au-dessus du rôle se place la restriction par chantier, gérée sur la fiche de contact via Modifier l’accès aux chantiers. Activée et garnie, elle limite le compte à ces projets exactement ; activée et laissée vide, elle prive la personne de tout enregistrement rattaché à un chantier, état utile pour une comptabilité externe et déroutant pour un chef de chantier. Les enregistrements sans projet restent visibles dans la limite du rôle.

Le contrôle serveur derrière les boutons masqués

Trois couches font le travail. Les routes de module et l’API JSON portent chacune l’autorisation requise ; une couche centrale rattache ensuite chaque route d’écriture nommée de l’application authentifiée à la clé nécessaire ; et les contrôleurs vérifient encore propriété, entreprise, transitions de statut et, si le cas l’exige, un droit plus strict. L’interface réduit par-dessus navigation, messages et actions selon le rôle, ce qui relève du confort et non de la frontière de sécurité.

L’accès aux chantiers est appliqué par une portée de requête globale sur les projets et tout ce qui en dépend : un chantier non autorisé répond comme inexistant dans les listes, les adresses de détail, la recherche, les relations et l’API. Ce choix prime sur un refus explicite, car un refus confirmerait l’existence du projet et livrerait son numéro. Les changements de rôle sont tracés en role.created, role.updated, role.deleted et user.role.updated.

Quel droit ouvre quel module en chantier, achats, finances et paie

La saisie de chantier dépend de site.write : rapports journaliers, réserves, RFI, dépôts de documents et constats de contrôle. Le commercial et les données de base dépendent de records.write : prospects, clients, chiffrages, offres, choix de matériaux, demandes de service, matériel, modèles, protocoles, envoi et affectation d’e-mails, import de contacts. Le travail projet dépend de projects.manage : projets, modèles, planning, calendrier de travail, sous-traitants et avenants.

L’argent se sépare en deux sens. Factures, relances, encaissements, cautions, écritures financières et séquences de numérotation réclament finance.manage ; attribution, commandes, réception et factures fournisseurs réclament purchasing.manage. Le droit de consultation du personnel permet déjà de saisir, corriger et supprimer ses propres heures et de déclarer sa propre maladie, tandis que valider et exporter les heures des autres exige workforce.payroll. L’assistant demande ai.use et l’onglet IA demande ai.manage.

Exemple : créer un rôle de chef d’équipe et restreindre son accès aux chantiers

Cedar Ridge Homes veut que Travis Nguyen mène ses équipes sans feuilleter le dossier commercial. Un administrateur crée le rôle Field lead, couleur #B45309, et coche uniquement site.write et workforce.view ; la clé technique field-lead se dérive toute seule, et comme site.write emporte déjà projects.view, aucune case de consultation supplémentaire n’est requise. Le dialogue d’attribution bascule Travis sur ce rôle en un seul enregistrement. Lui confier le rôle administrateur n’aurait été possible qu’à un administrateur, et Travis ne peut de toute façon pas toucher à son propre rôle, quelle que soit l’allure de son écran.

Sous Modifier l’accès aux chantiers, le bureau lui ouvre Willow Creek Lot 27 et Harper Station Townhomes. Le lendemain, sa liste de projets compte deux lignes dont les contrats s’additionnent à 4 636 500,00 dollars, quand la liste complète de l’entreprise garde vingt-six affaires et 29 304 500,00 dollars ; chercher Oakmont Ridge Phase II ne renvoie rien du tout, plutôt que de trahir l’existence du chantier. Sur sa paire de sites, il rédige rapports journaliers et réserves et saisit ses propres heures, mais valider celles de son équipe reste fermé faute de workforce.payroll. Le journal d’audit consigne role.created puis user.role.updated avec la personne agissante.

Rôles et autorisations : à vérifier avant d’enregistrer

• Un droit de gestion emporte son droit de consultation : cocher records.write, finance.manage, projects.manage ou workforce.manage suffit déjà.

• Un rôle maison ne se supprime qu’une fois qu’aucun utilisateur ne le porte, et les rôles système ne se suppriment jamais.

• Le rôle administrateur conserve les 17 autorisations quelles que soient les cases transmises par son formulaire de modification.

• Une personne restreinte avec une liste de chantiers vide ne voit aucun enregistrement rattaché à un projet, API JSON comprise.

• Personne ne modifie son propre rôle, et attribuer ou retirer le rôle administrateur reste réservé aux administrateurs.

Rôles et autorisations : erreurs fréquentes

• Donner records.write à un chef de chantier pour qu’il rédige un rapport journalier : la saisie terrain tient à site.write, alors que records.write ouvre le dossier commercial. Accordez site.write et laissez les données de base fermées.

• Retirer un droit en attendant un effet instantané : la modification vaut à partir de la requête suivante de la personne, pas dans la page déjà ouverte. Demandez un rechargement avant de conclure.

• Supprimer un rôle encore porté est refusé. Basculez d’abord chaque porteur vers un autre rôle depuis la liste des utilisateurs, puis retirez le rôle devenu vide.