ORM_CreateUser
Crée un utilisateur SQL avec mot de passe et lui accorde les droits SELECT, INSERT, UPDATE, DELETE sur une base de données existante. Adapte automatiquement les instructions selon le provider courant (MySQL · MariaDB · PostgreSQL). Idempotente : un appel sur un utilisateur existant ne provoque pas d'erreur.
📋 Description
ORM_CreateUser provisionne un compte utilisateur SQL côté moteur de base de données et lui attribue les droits nécessaires pour qu'une application accède aux données en lecture et écriture. La procédure encapsule les différences syntaxiques entre les providers : le code applicatif décrit le compte voulu, le framework émet les instructions SQL appropriées (CREATE USER, GRANT) selon le moteur cible.
L'opération est idempotente : un appel sur un compte qui existe déjà ne provoque pas d'erreur. Les droits sont (ré)appliqués à chaque appel, ce qui permet aussi d'utiliser la procédure pour aligner les permissions d'un compte existant sur le standard du framework.
1. Provisionner un utilisateur applicatif au déploiement initial — typiquement en sortie de ORM_CreateDataBase et ORM_InitDatabase (script d'installation, assistant de déploiement).
2. Ajouter un compte de service pour un module externe : reporting, API tierce, job planifié. Chaque module avec son propre login facilite la traçabilité et la révocation indépendantes.
3. Déléguer la création d'utilisateurs depuis l'application plutôt que de demander à un DBA — par exemple via un assistant administrateur intégré qui crée les comptes à la volée.
Les comptes créés par ORM_CreateUser reçoivent uniquement les droits DML (SELECT, INSERT, UPDATE, DELETE). Ils ne peuvent ni créer, ni modifier, ni supprimer des tables, vues, index ou autres objets de schéma. C'est volontaire — principe du moindre privilège pour les comptes applicatifs : la création et l'évolution du schéma restent réservées à un compte d'administration distinct.
IF NOT EXISTSL'instruction CREATE USER IF NOT EXISTS garantit qu'un appel sur un login déjà existant n'échoue pas. Les étapes de GRANT sont également ré-exécutées à chaque appel, ce qui aligne le compte sur les permissions standard. Cela rend la procédure utilisable indifféremment au premier déploiement ou en mise à jour.
🔑 Signature
LOCAL sLogin est une chaîne,
LOCAL sPassword est une chaîne,
LOCAL sDBName est une chaîne,
LOCAL sSchema est une chaîne = "public"
) : (booléen, entier, chaîne)
| Élément | Valeur |
|---|---|
| Visibilité | PUBLIQUE |
Paramètres
| Paramètre | Type | Défaut | Rôle |
|---|---|---|---|
sLogin | chaîne | — | Login du nouvel utilisateur SQL. |
sPassword | chaîne | — | Mot de passe du nouvel utilisateur SQL. |
sDBName | chaîne | — | Nom de la base de données cible sur laquelle le compte recevra les droits DML. |
sSchema | chaîne | "public" | PostgreSQL uniquement : nom du schéma cible. Ignoré pour MySQL et MariaDB qui ne disposent pas de la notion de schéma au sein d'une base. |
Valeur de retour
| Élément | Type | Description |
|---|---|---|
bProcessing | booléen | Vrai si l'opération a réussi (toutes les étapes), Faux en cas d'échec à n'importe quelle étape. |
nErrorCode | entier | Code d'erreur négatif en cas d'échec, 0 sinon. Voir §05 pour la liste complète. |
sErrorMessage | chaîne | Message d'erreur lisible en cas d'échec, vide sinon. |
🛡️ Droits accordés selon le provider
Les instructions SQL exécutées diffèrent selon le moteur cible. Le détail ci-dessous documente l'ensemble des étapes pour permettre au développeur de tracer le comportement et de comprendre les droits réellement accordés.
MySQL / MariaDB — 3 étapes
| Étape | Instruction SQL | Effet |
|---|---|---|
| 1. Création du compte | CREATE USER IF NOT EXISTS '<login>'@'%' IDENTIFIED BY '<password>' | Crée le compte s'il n'existe pas. '@%' = autorisation depuis n'importe quel hôte. |
| 2. Droits DML sur la base | GRANT SELECT, INSERT, UPDATE, DELETE ON <base>.* TO '<login>'@'%' | Accorde les 4 opérations DML sur toutes les tables actuelles et futures de la base ciblée. |
| 3. Application immédiate | FLUSH PRIVILEGES | Recharge les tables d'accréditation en mémoire pour activation immédiate. |
'%' sous MySQL/MariaDBLe compte est créé avec une autorisation d'accès depuis n'importe quel hôte ('login'@'%'). La restriction réseau n'est donc pas portée par le compte SQL lui-même mais doit être assurée par d'autres moyens (firewall, configuration bind-address, etc.) selon la politique d'infrastructure.
PostgreSQL — 5 étapes
| Étape | Instruction SQL | Effet |
|---|---|---|
| 1. Création du compte | CREATE USER IF NOT EXISTS "<login>" WITH PASSWORD '<password>' | Crée le compte s'il n'existe pas. PostgreSQL ne porte pas l'hôte sur le compte — la restriction réseau passe par pg_hba.conf. |
| 2. Connexion à la base | GRANT CONNECT ON DATABASE "<base>" TO "<login>" | Autorise l'utilisateur à ouvrir une connexion sur la base ciblée. |
| 3. Accès au schéma | GRANT USAGE ON SCHEMA "<schema>" TO "<login>" | Autorise l'utilisateur à accéder au schéma (obligatoire en PostgreSQL pour traverser le schéma jusqu'aux tables). |
| 4. Droits DML — tables existantes | GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA "<schema>" TO "<login>" | Accorde les 4 opérations DML sur toutes les tables actuellement présentes dans le schéma. |
| 5. Droits DML — tables futures | ALTER DEFAULT PRIVILEGES IN SCHEMA "<schema>" GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO "<login>" | Étend automatiquement les droits aux tables qui seront créées ultérieurement dans le schéma. |
La connexion ORM courante doit pointer sur la base de données cible (sDBName) au moment de l'appel. Contrairement à MySQL/MariaDB où une seule connexion permet de gérer plusieurs bases, PostgreSQL est strictement cloisonné par base : les instructions GRANT ne peuvent porter que sur la base à laquelle la session est connectée.
De même, l'instruction ALTER DEFAULT PRIVILEGES ne couvre que les tables créées par le rôle courant de la session (celui qui exécute la procédure). Si d'autres rôles créent des tables ultérieurement dans le schéma, ces tables ne seront pas couvertes par les permissions par défaut accordées ici — il faudra ré-appliquer ALTER DEFAULT PRIVILEGES sous chaque rôle propriétaire.
🧭 Validation des paramètres
Avant toute exécution, la procédure vérifie la cohérence des paramètres reçus. Une validation qui échoue interrompt l'exécution et retourne un code d'erreur dédié.
| Contrôle | Code d'erreur |
|---|---|
sLogin non vide (après SansEspace) | ERR_DB_USER_LOGIN_VIDE |
sPassword non vide (après SansEspace) | ERR_DB_USER_PASSWORD_VIDE |
sDBName non vide (après SansEspace) | ERR_DB_USER_BASE_VIDE |
| Provider supporté (MySQL, MariaDB, PostgreSQL) | ERR_DB_USER_PROVIDER |
Sur PostgreSQL : sSchema non vide | ERR_DB_USER_SCHEMA_VIDE |
Les contrôles sont enchaînés : le premier qui échoue interrompt le pipeline. Aucune instruction SQL n'est émise si la validation préalable n'est pas complètement satisfaite.
⚠️ Gestion des erreurs
La procédure peut échouer à plusieurs étapes — validation préalable, création du compte, attribution des droits. Chaque erreur dispose de sa propre constante pour permettre un traitement applicatif précis.
Erreurs de validation
| Constante | Condition |
|---|---|
ERR_DB_USER_LOGIN_VIDE | Paramètre sLogin vide. |
ERR_DB_USER_PASSWORD_VIDE | Paramètre sPassword vide. |
ERR_DB_USER_BASE_VIDE | Paramètre sDBName vide. |
ERR_DB_USER_SCHEMA_VIDE | Paramètre sSchema vide alors que le provider est PostgreSQL. |
ERR_DB_USER_PROVIDER | Provider de la connexion ORM non supporté par cette procédure. |
Erreurs d'exécution SQL
| Constante | Étape concernée |
|---|---|
ERR_DB_USER_CREATE_SQL | Échec du CREATE USER (problème de syntaxe, droits insuffisants du compte exécutant…). |
ERR_DB_USER_GRANT_DML | Échec du GRANT DML sur la base (MySQL / MariaDB). |
ERR_DB_USER_FLUSH | Échec du FLUSH PRIVILEGES (MySQL / MariaDB). |
ERR_DB_USER_GRANT_CONNECT | Échec du GRANT CONNECT (PostgreSQL). |
ERR_DB_USER_GRANT_SCHEMA | Échec du GRANT USAGE ON SCHEMA (PostgreSQL). |
ERR_DB_USER_GRANT_TABLES | Échec du GRANT DML sur les tables existantes (PostgreSQL). |
ERR_DB_USER_DEFAULT_PRIVS | Échec du ALTER DEFAULT PRIVILEGES (PostgreSQL — droits sur les tables futures). |
-99999 | Exception non prévue (consulter sErrorMessage pour le détail). |
Si une étape échoue après que les précédentes ont réussi, les opérations déjà commises restent en place côté moteur SQL. Par exemple : sur PostgreSQL, si l'étape 4 (GRANT sur les tables existantes) échoue, le compte aura déjà été créé (étape 1) et autorisé à se connecter (étape 2-3). Il faudra alors soit relancer ORM_CreateUser (idempotent, donc sans risque), soit nettoyer manuellement.
💡 Exemples
Mode 1 — provisionnement nominal au déploiement
Cas d'usage : script d'installation qui crée la base puis le compte applicatif.
"app_cashx2", // login applicatif "M0tDePassEFort!2026", // mot de passe "cashx2_prod" // base de données cible ) SI bProcessing ALORS Info("Compte applicatif provisionné avec succès") SINON Erreur(sErrorMessage) FIN
Mode 2 — PostgreSQL avec schéma personnalisé
Cas d'usage : provisionner un compte sur un schéma dédié plutôt que sur public.
"reporting_user", "R3p0rt_2026!", "cashx2_prod", "reporting" // schéma dédié au reporting ) SI bProcessing ALORS Info("Compte de reporting créé sur schéma 'reporting'") FIN
Mode 3 — gestion fine des erreurs par étape
Cas d'usage : assistant administrateur qui doit guider l'utilisateur en cas de problème.
Mode 4 — alignement des permissions d'un compte existant
Cas d'usage : script de mise à jour qui s'assure qu'un compte historique a bien les permissions attendues par la version courante du framework.
"app_cashx2", sNouveauPassword, // idéalement : régénérer aussi le mot de passe "cashx2_prod" ) SI bProcessing ALORS Trace("Permissions du compte 'app_cashx2' alignées sur le standard courant") FIN