Questions fréquentes¶

Cette FAQ synthétise les questions récurrentes des tickets d’assistance MRBS, ouverts comme fermés. Les réponses ont été vérifiées avec MRBS 1.12.2 ; une ancienne solution de contournement n’est pas reprise simplement parce qu’elle figurait autrefois dans un ticket.

Sélection des questions¶

L’examen a porté sur les tickets possédant au moins une de ces étiquettes : Help, Help from scratch, LDAP help need, Problems with room's capacity, support, spanish help, support request, help wanted et custom view help.

Au 26 juillet 2026, la seule étiquette support request regroupait 3 076 tickets : 1 590 ouverts et 1 486 fermés. Beaucoup sont des cas historiques importés, des personnalisations ponctuelles, des demandes de fonctionnalité ou des questions sans réponse confirmée. Seules les questions récurrentes dont la réponse reste utile pour la version 1.12.2 figurent ici. Les liens vers les tickets indiquent la provenance ; ils ne remplacent pas la référence de configuration actuelle.

Installation et diagnostic¶

Pourquoi une page blanche ou une erreur HTTP 500 s’affiche-t-elle ?¶

Lire d’abord les journaux d’erreurs du serveur web et de PHP. La page blanche n’est que le symptôme visible ; l’erreur exploitable se trouve généralement dans un journal. Vérifier ensuite :

la version PHP prise en charge et les extensions nécessaires ;
config.inc.php avec php -l config.inc.php ;
la connexion à la base et le pilote PDO correspondant ;
les droits des fichiers et la configuration PHP réellement chargée ; et
que la requête atteint bien l’installation MRBS attendue.

Ne pas afficher publiquement les erreurs PHP en production et ne pas copier d’identifiants dans un ticket. Voir Dépannage. Le ticket d’assistance nº 1007 n’avait pas de correction propre au produit confirmée ; c’est pourquoi la réponse commence par les journaux locaux.

Pourquoi l’accès à la base échoue-t-il avec cPanel ou un hébergement mutualisé ?¶

Utiliser exactement le nom de base et le nom d’utilisateur créés par le panneau d’hébergement. cPanel préfixe souvent les deux avec le nom du compte d’hébergement. Vérifier aussi que cet utilisateur possède les droits sur cette base. SQLSTATE[28000] ou « Access denied for user » signale un problème d’authentification ou de privilèges de la base, et non un défaut des tables MRBS.

Garder $db_database, $db_login et $db_password conformes aux valeurs du panneau. Ne créer le schéma qu’une fois la connexion établie. Voir ticket nº 3801 et Installation.

Pourquoi une modification de configuration reste-t-elle sans effet ?¶

Vérifier que le fichier config.inc.php chargé par ce déploiement et ce site a bien été modifié. Une affectation ultérieure remplace une valeur précédente. Les paramètres des zones existantes sont enregistrés en base ; areadefaults.inc.php ne définit que les valeurs initiales des nouvelles zones. En mode multisite, contrôler le site sélectionné et sa configuration. Enfin, vider ou redémarrer le cache d’opcode PHP si nécessaire.

Voir config.inc.php en détail et Dépannage.

Connexion et LDAP¶

Comment imposer une connexion avant d’afficher le calendrier ?¶

Définir :

$auth['deny_public_access'] = true;

Tester la vue déconnectée dans une fenêtre de navigation privée. Ce paramètre interdit l’accès public au calendrier ; il ne choisit ni ne configure le mécanisme d’authentification. Voir ticket nº 3979 et Utilisateurs et autorisations.

Pourquoi MRBS indique-t-il que l’extension LDAP de PHP manque ?¶

Installer ou activer l’extension LDAP pour l’environnement PHP réellement utilisé par le serveur web, puis redémarrer cet environnement. PHP en ligne de commande et PHP côté serveur peuvent charger des fichiers php.ini différents ; ne pas se fier uniquement à php -m. Le nom du paquet et la commande de redémarrage dépendent du système et de l’installation PHP.

Voir ticket nº 1022 et Authentification LDAP.

Comment déterminer les bons DN de base et DN utilisateur LDAP ?¶

Ne pas déduire l’arborescence d’annuaire du nom de l’organisation. L’interroger avec un client tel que ldapsearch, en utilisant le même serveur, mode TLS, DN de base, compte de recherche et attribut de connexion que MRBS. Active Directory utilise souvent sAMAccountName et OpenLDAP souvent uid, mais le schéma réel de l’annuaire fait foi.

Tester le compte de recherche séparément de la liaison de l’utilisateur et ne jamais publier les mots de passe de liaison. Un DN incorrect était la cause du ticket nº 1083.

Comment limiter l’accès LDAP à un groupe ?¶

Utiliser $ldap_filter pour décider quels utilisateurs de l’annuaire peuvent accéder à MRBS. Avec Active Directory, si l’appartenance figure sur l’objet utilisateur, le filtre peut tester memberof. Avec une structure de type OpenLDAP qui conserve les membres dans les objets groupe, configurer $ldap_filter_base_dn, $ldap_filter_user_attr et un $ldap_filter adapté.

Employer les DN et attributs exacts de l’annuaire, tester un compte autorisé et un compte refusé, puis vérifier les groupes imbriqués. Ces filtres d’accès sont distincts de $ldap_admin_group_dn, qui désigne les administrateurs MRBS. Voir ticket nº 2033 et Authentification LDAP.

La connexion LDAP fonctionne ; pourquoi l’utilisateur n’est-il pas administrateur MRBS ?¶

Lorsque $ldap_admin_group_dn est défini, MRBS utilise ce groupe à la place de $auth['admin']. Vérifier :

le DN complet du groupe ;
$ldap_group_member_attrib — memberof par défaut ;
que le compte de recherche LDAP peut lire les attributs d’appartenance ; et
si l’annuaire renvoie les appartenances directes ou imbriquées.

N’activer les diagnostics LDAP que brièvement dans un environnement de test protégé, puis les retirer. Dans le ticket nº 3943, le compte de recherche ne pouvait initialement pas lire les informations de groupe nécessaires.

Pourquoi LDAP peut-il échouer après une mise à niveau alors que la liaison par mot de passe fonctionne ?¶

La version actuelle de MRBS peut devoir rechercher le DN et des attributs tels que le nom affiché ou l’e-mail. Si la recherche anonyme est interdite, configurer :

$ldap_dn_search_attrib = 'sAMAccountName'; // utiliser l’attribut réel
$ldap_dn_search_dn = 'search-account@example.org';
$ldap_dn_search_password = 'lire-un-secret-protege';

N’accorder au compte de recherche que les droits de lecture nécessaires. Conserver son mot de passe hors de la racine web et l’inclure depuis un fichier de configuration protégé. Voir ticket nº 3895.

MRBS peut-il rechercher dans plusieurs annuaires LDAP ?¶

Oui. De nombreux paramètres LDAP, notamment $ldap_host, $ldap_port, $ldap_base_dn et les attributs de recherche, acceptent des tableaux. Dès qu’un paramètre compatible est un tableau, tous les paramètres compatibles doivent compter le même nombre d’éléments, un par annuaire.

Tester la connexion, la lecture des attributs, les filtres d’accès et l’attribution du rôle administrateur pour chaque annuaire. Voir ticket nº 3981 et la section LDAP de systemdefaults.inc.php.

Réservations, salles et autorisations¶

Pourquoi un champ personnalisé fonctionne-t-il pour une réservation, mais pas pour une série ?¶

Chaque colonne personnalisée de réservation doit exister dans les tables entry et repeat avec les mêmes nom, type, longueur, règle NULL et valeur par défaut. Traiter les deux colonnes comme une seule évolution de schéma.

Voir ticket nº 3986 et Champs personnalisés.

La capacité d’une salle empêche-t-elle une réservation avec trop de participants ?¶

Non. La valeur capacity est une propriété de salle affichée par MRBS ; elle n’est pas comparée automatiquement au nombre de participants d’une réservation. Pour imposer cette règle, ajouter un même champ personnalisé de nombre de participants à entry et repeat, puis développer et maintenir une validation côté serveur. Une validation uniquement dans le navigateur ne suffit pas.

Si l’inscription est activée, la capacité de l’événement limite les inscriptions à cet événement ; elle ne choisit pas automatiquement une salle assez grande. Voir ticket nº 1055, Zones et salles et Champs personnalisés.

Une zone peut-elle proposer des créneaux de 30 minutes le matin puis de 15 minutes ?¶

Pas avec la configuration standard d’une zone. Une zone possède une seule résolution temporelle. Utiliser la plus petite résolution requise pour toute la journée ou créer des zones séparées si les ressources et l’organisation le permettent. Une résolution variant selon l’heure nécessite une personnalisation du code qui devra être maintenue.

Voir ticket nº 4011.

Pourquoi le créateur ne voit-il pas Modifier ou Supprimer ?¶

Contrôler la politique de réservation de la zone existante dans Salles. Les limites de modification future et les règles applicables aux réservations passées peuvent masquer ces actions même pour le créateur. Vérifier aussi l’identité connectée, le propriétaire, le rôle administrateur et s’il s’agit d’une occurrence ou d’une série.

Modifier areadefaults.inc.php ne met pas à jour une zone existante. Voir ticket nº 3994 et Règles de réservation.

Les salles d’une réservation multisalle restent-elles liées ?¶

Non. MRBS crée des réservations distinctes. Si l’une est ensuite modifiée ou supprimée, les autres ne constituent pas un groupe lié durable. Ne recopier la liste générée de toutes les salles dans chaque description que si le site sait aussi maintenir cette liste lors de la création, de la modification et de la suppression.

Voir ticket nº 2223.

Puis-je ajouter des niveaux d’accès ou un rôle réservé aux rapports ?¶

MRBS standard utilise les niveaux 0, 1 et 2. Des rôles numériques supplémentaires et des droits propres à une page exigent une personnalisation locale de l’autorisation, des tests et un contrôle après chaque mise à niveau. Un correctif tiré d’un ancien ticket n’est pas une option de configuration prise en charge.

Préférer, si elles répondent au besoin, la délégation standard par zone/salle ou les rapports publics avec des listes d’autorisation étroites. Voir ticket nº 3999 et Utilisateurs et autorisations.

E-mail, langue et heure¶

Pourquoi le diagnostic e-mail indique-t-il « No recipients » ?¶

Activer au moins un rôle destinataire :

$mail_settings['admin_on_bookings'] = true;
$mail_settings['area_admin_on_bookings'] = true;
$mail_settings['room_admin_on_bookings'] = true;
$mail_settings['booker'] = true;

Pour la première option, définir $mail_settings['recipients']. Pour les administrateurs de zone et de salle, maintenir leurs adresses dans MRBS. Si l’auteur doit recevoir le message, les utilisateurs LDAP ont besoin d’un attribut e-mail lisible et correctement associé. Tester séparément la création, la modification et la suppression.

Voir ticket nº 3795 et Notifications par e-mail.

Quelle valeur faut-il donner à `$override_locale` ?¶

Utiliser une balise linguistique BCP 47 telle que en, en-GB, de, fr ou es, pas une chaîne de locale propre au système. Le serveur doit néanmoins disposer des données de locale nécessaires. Sur un système de type Unix, locale -a affiche les locales installées.

Laisser $override_locale vide pour la sélection automatique de MRBS. Voir ticket nº 3984 et Textes et traductions.

Pourquoi les heures affichées sont-elles décalées exactement d’une heure ?¶

Vérifier, dans cet ordre :

le fuseau de la salle et de la zone ;
le paramètre global $timezone ;
le fuseau PHP et le paquet de données de fuseaux ;
le changement heure d’été/hiver à la date concernée ; et
si l’horodatage enregistré ou seulement son affichage est incorrect.

Utiliser un fuseau IANA comme Europe/Paris, pas un décalage UTC fixe. Les anciens tickets mentionnent des contournements propres à certaines versions ; $force_strftime n’est pas un paramètre de MRBS 1.12.2 et ne doit pas être recopié depuis le ticket nº 3967. Voir Dépannage.

Comment personnaliser ou traduire la page d’aide et les textes de l’interface ?¶

La page d’aide intégrée est chargée depuis web/site_faq/. L’espagnol utilise par exemple site_faq_es.html ; définir $faqfilelang = 'es' si la langue doit être sélectionnée explicitement. Maintenir un fichier traduit complet pour chaque langue prise en charge.

Pour de courtes adaptations de l’interface, utiliser $vocab_override[LANG][TOKEN] dans config.inc.php plutôt que modifier web/lang/lang.*. Les champs de base personnalisés utilisent des jetons comme entry.catering.

Voir ticket nº 2432 et Textes et traductions.

Rapports, multisite et personnalisation¶

Comment une tâche planifiée peut-elle exporter un rapport ou des données iCalendar ?¶

Les rapports GET sans authentification sont désactivés par défaut. Si les informations peuvent être exposées ainsi, les activer explicitement et les restreindre :

$report_unauthenticated_get_enabled = true;
$report_keys_enabled = true;
$report_keys = ['un-long-secret-aleatoire'];
$report_open_areas = [1];
$report_open_rooms = [];

Utiliser une clé imprévisible, une liste de zones/salles très limitée, HTTPS et un planificateur protégé. Tester la sortie exacte en étant déconnecté. Une URL de rapport agit comme un identifiant et peut fuiter par les journaux ou l’historique.

Voir ticket nº 3742 et Recherche et rapports.

Plusieurs sites MRBS peuvent-ils partager le même jeu de tables ?¶

Non, si leurs réservations et paramètres doivent rester séparés. Chaque site requiert ses propres tables MRBS, soit dans une base distincte, soit avec un $db_tbl_prefix unique dans une base partagée. Le code peut être commun, mais les jeux de tables ne doivent pas se chevaucher.

Créer les tables de chaque site avec les scripts de schéma MRBS et appliquer son préfixe partout. Voir ticket nº 3917 et Multisite.

Toute vue ou tout thème demandé est-il configurable ?¶

Non. Ajouter du texte de salle à une vue de calendrier précise, relier des réservations autrement indépendantes, ajouter des niveaux d’accès ou remplacer l’architecture des thèmes peut nécessiter de modifier le code. Avant d’appliquer un correctif provenant d’un ticket d’assistance :

vérifier si la version 1.12.2 offre déjà un paramètre ou un point d’extension ;
garder la modification hors des fichiers générés et des bibliothèques tierces ;
tester création, modification, suppression, confidentialité et droits ; et
documenter la personnalisation pour la prochaine mise à niveau.

Exemples : ticket de vue personnalisée nº 2223 et demande de thème nº 22.