Întrebări frecvente¶

Acest FAQ sintetizează întrebările recurente din issue-urile de asistență MRBS, atât deschise, cât și închise. Răspunsurile au fost verificate pentru MRBS 1.12.2; o soluție veche nu este inclusă doar pentru că a apărut într-un issue.

Cum au fost selectate întrebările¶

Examinarea a acoperit probleme care poartă cel puțin una dintre aceste etichete: Help, Help from scratch, LDAP help need, Problems with room's capacity, support, spanish help, support request, help wanted, și custom view help.

La 26 iulie 2026, doar eticheta support request conținea 3.076 de issue-uri: 1.590 deschise și 1.486 închise. Multe sunt cazuri istorice importate, personalizări unice, solicitări de funcții sau întrebări fără un răspuns confirmat. Doar întrebările recurente cu un răspuns care este încă util pentru 1.12.2 sunt incluse mai jos. Legăturile pentru probleme oferă proveniența, nu un înlocuitor pentru referința de configurare curentă.

Instalare si diagnosticare¶

De ce văd o pagină goală sau HTTP 500?¶

Citiți mai întâi jurnalele de eroare ale serverului web și PHP. O pagină goală este doar simptomul vizibil; eroarea utilă este în mod normal într-un jurnal. Apoi verificați:

versiunea acceptată PHP și extensiile necesare;
config.inc.php cu php -l config.inc.php;
conectivitate la baza de date și driverul PDO potrivit;
permisiunile pentru fișiere și configurația activă PHP; şi
dacă solicitarea eșuată ajunge la instalarea dorită MRBS.

Nu activați afișarea publică a erorilor PHP pe un sistem de producție și nu inserați acreditările într-o problemă. Vezi Depanare. caz de sprijin #1007 inițial nu a avut nicio remediere confirmată specifică produsului, motiv pentru care acest răspuns începe cu dovezi din jurnalele locale.

De ce eșuează autentificarea bazei de date pe cPanel sau pe găzduire partajată?¶

Utilizați baza de date exactă și numele de utilizator create de panoul de control al găzduirii. cPanel prefixează adesea ambele nume de cont de găzduire. De asemenea, verificați dacă utilizatorul are privilegii pe acea bază de date. SQLSTATE[28000] sau „Acces refuzat utilizatorului” este o eroare de autentificare sau acordare a bazei de date, nu o eroare de tabel MRBS.

Păstrați $db_database, $db_login și $db_password în concordanță cu valorile panoului de control. Creați schema numai după ce conexiunea reușește. Vezi issue-ul #3801 și Instalare.

De ce o modificare de configurare nu are efect?¶

Verificați dacă ați editat config.inc.php încărcat de această implementare și site. Valorile atribuite ulterior le înlocuiesc pe cele anterioare. Setările salvate pentru zonele existente trăiesc în baza de date; modificarea areadefaults.inc.php modifică valorile implicite numai pentru zone noi. În modul multisite, confirmați site-ul selectat și configurația acestuia. În cele din urmă, ștergeți sau reporniți PHP opcode cache acolo unde este cazul.

Vezi config.inc.php în profunzime și Depanare.

Conectați-vă și LDAP¶

Cum pot solicita utilizatorilor să se conecteze înainte de a vedea calendarul?¶

Set:

$auth['deny_public_access'] = true;

Testați vizualizarea deconectată într-o fereastră de browser privată. Această setare blochează accesul la calendarul public; nu alege sau configurează metoda de autentificare. Vezi issue-ul #3979 și Utilizatori și permisiuni.

De ce MRBS spune că extensia PHP LDAP lipsește?¶

Instalați sau activați extensia LDAP pentru mediul PHP utilizat de serverul web, apoi reporniți acel mediu. Versiunea PHP din linia de comandă și instanța PHP folosită de serverul web pot încărca fișiere php.ini diferite; verificați, așadar, mediul serverului web, nu doar rezultatul comenzii php -m. Numele exact al pachetului și comanda de repornire depind de sistemul de operare și de instalarea PHP.

Vezi issue-ul #1022 și Autentificare LDAP.

Cum găsesc DN-ul de bază și DN-ul utilizatorului corect LDAP?¶

Nu deduceți arborele de director din numele unei organizații. Interogați-l cu un client LDAP, cum ar fi ldapsearch, folosind același server, modul TLS, DN de bază, identitatea de căutare și atributul nume de utilizator pe care MRBS îl va folosi. Active Directory folosește de obicei sAMAccountName; OpenLDAP folosește în mod obișnuit uid, dar schema de director este autorizată.

Testați identitatea de căutare separat de legarea utilizatorului final și nu publicați niciodată parolele de legătură. Un DN greșit a fost cauza principală în issue-ul #1083.

Cum poate fi limitat accesul LDAP la un grup?¶

Utilizați $ldap_filter pentru a decide ce director ar putea accesa utilizatorii MRBS. Pentru un aspect Active Directory în care apartenența este stocată pe obiectul utilizator, un filtru poate corespunde memberof. Pentru un aspect în stil OpenLDAP în care apartenența este stocată pe obiecte de grup, configurați $ldap_filter_base_dn, $ldap_filter_user_attr și un $ldap_filter corespunzător.

Utilizați DN-ul exact și numele atributelor din director, testați un cont permis și unul respins și confirmați cum se comportă grupurile imbricate. Aceste filtre de acces sunt separate de $ldap_admin_group_dn, care identifică administratorii MRBS. Vezi issue-ul #2033 și Autentificare LDAP.

Autentificare LDAP funcționează; de ce utilizatorul nu este un administrator MRBS?¶

Când $ldap_admin_group_dn este setat, MRBS folosește acel grup în loc de $auth['admin']. Confirma:

grupul complet DN;
$ldap_group_member_attrib — memberof în mod implicit;
că identitatea de căutare LDAP poate citi atributele de membru ale utilizatorului; şi
dacă directorul returnează apartenența directă sau imbricată.

Activați temporar diagnosticarea LDAP numai într-un mediu de testare protejat și eliminați-le ulterior. În issue-ul #3943, identitatea de căutare nu a putut citi inițial informațiile de grup necesare.

De ce poate eșua LDAP după o actualizare MRBS, deși legarea parolei funcționează?¶

MRBS curent poate fi necesar să caute DN-ul utilizatorului și atribute, cum ar fi numele afișat sau adresa de e-mail. Dacă căutarea anonimă nu este disponibilă, configurați:

$ldap_dn_search_attrib = 'sAMAccountName'; // use the directory's real attribute
$ldap_dn_search_dn = 'search-account@example.org';
$ldap_dn_search_password = 'read-from-a-protected-secret';

Oferiți identității de căutare doar permisiunile de citire de care are nevoie. Păstrați parola în afara rădăcinii documentului și includeți-o dintr-un fișier de configurare protejat. Vezi issue-ul #3895.

Poate MRBS să caute mai multe directoare LDAP?¶

Da. Multe setări LDAP, inclusiv $ldap_host, $ldap_port, $ldap_base_dn și atribute de căutare, pot fi matrice. Dacă un parametru LDAP capabil de matrice este o matrice, fiecare parametru capabil de matrice trebuie să aibă același număr de elemente, unul pe director.

Testați autentificarea, căutarea atributelor, filtrele de acces și maparea administratorului pentru fiecare director. Consultați issue-ul #3981 și secțiunea LDAP din systemdefaults.inc.php.

Rezervări, săli și permisiuni¶

De ce funcționează un câmp de rezervare personalizat pentru o rezervare, dar eșuează pentru o serie?¶

Fiecare coloană de rezervare personalizată trebuie să existe în ambele tabele entry și repeat cu același nume, tip, lungime, nullabilitate și implicit. Tratați ambele coloane ca o singură modificare a schemei.

Vezi issue-ul #3986 și Câmpuri personalizate.

Capacitatea sălii împiedică o rezervare cu prea mulți participanți?¶

Nu. Valoarea capacity a sălii reprezintă metadate afișate de MRBS; aceasta nu este comparată automat cu numărul de participanți al unei rezervări. Dacă un site trebuie să aplice această regulă, adăugați un câmp personalizat identic pentru numărul de participanți la entry și repeat, apoi implementați și mențineți validarea pe server. Numai validarea din partea clientului este insuficientă.

Dacă înregistrarea este activată, capacitatea evenimentului controlează înregistrarea pentru acel eveniment; nu selectează automat o sală de dimensiuni adecvate. Consultați issue-ul #1055, Zone și săli și Câmpuri personalizate.

O zonă poate folosi sloturi de 30 de minute dimineața și sloturi de 15 minute mai târziu?¶

Nu prin configurația standard a zonei. O zonă are o rezoluție unică. Utilizați cea mai mică rezoluție necesară pentru întreaga zi sau creați zone separate atunci când resursele și modelul de operare permit acest lucru. O rezoluție dependentă de timp necesită o personalizare menținută a codului.

Vezi issue-ul #4011.

De ce un creator de rezervări nu poate vedea Editare sau Ștergere?¶

Verificați politica de rezervare a zonei existente prin Săli. Limitele și regulile de editare în avans/viitoare pentru rezervările anterioare pot elimina acele acțiuni chiar și de la creator. De asemenea, confirmați identitatea conectată, calitatea de proprietar, starea de administrator și dacă articolul este o apariție sau o serie.

Schimbarea areadefaults.inc.php nu actualizează o zonă existentă. Vedeți issue-ul #3994 și Politici de rezervare.

Sălile selectate într-o rezervare cu mai multe săli sunt conectate permanent?¶

Nu. MRBS creează intrări separate de rezervare. Dacă unul este ulterior editat sau șters, celelalte nu sunt un grup de legătură durabil. Nu copiați o listă generată a tuturor sălilor selectate în fiecare descriere decât dacă site-ul menține, de asemenea, acea listă pe parcursul operațiunilor de creare, editare și ștergere.

Vezi issue-ul #2223.

Pot să adaug mai multe niveluri de acces sau să acord doar un rol personalizat acces la raport?¶

Standardul MRBS folosește nivelurile de acces 0, 1 și 2. Rolurile numerice suplimentare și permisiunile specifice paginii necesită personalizare, teste și revizuire locale după fiecare actualizare. Un patch dintr-o problemă veche nu este o opțiune de configurare acceptată.

Preferați delegarea zonei/sălii standard și rapoartele publice cu liste de permise înguste, acolo unde acestea îndeplinesc cerințele. Vezi issue-ul #3999 și Utilizatori și permisiuni.

E-mail, limbă și oră¶

De ce depanarea e-mailului raportează „Fără destinatari”?¶

Activați cel puțin un rol de destinatar vizat:

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

Pentru prima opțiune, setați $mail_settings['recipients']. Pentru administratorii de zone și săli, păstrați-le adresele de e-mail în MRBS. LDAP utilizatorii au nevoie de un atribut de e-mail care poate fi citit și mapat corect atunci când persoana care face rezervări este notificată. Apoi testați separat crearea, editarea și ștergerea evenimentelor.

Vezi issue-ul #3795 și Notificări prin e-mail.

Ce valoare ar trebui să folosesc pentru `$override_locale`?¶

Folosiți o etichetă de limbă BCP 47, cum ar fi en, en-GB, de, fr sau es, nu un șir local al sistemului de operare. Serverul trebuie să aibă în continuare date locale adecvate. Pe sisteme asemănătoare Unix, locale -a arată localurile instalate.

Lăsați $override_locale gol pentru a utiliza selecția automată MRBS. Vezi issue-ul #3984 și Text și traduceri.

De ce orele afișate sunt greșite cu exact o oră?¶

Verifica, in ordine:

fusul orar al sălii și al zonei;
global $timezone;
Pachetul de date privind fusul orar și fusul orar al PHP;
trecerea la ora de vară a datei afectate; şi
dacă marca temporală stocată sau numai afișarea acesteia este greșită.

Folosiți un fus orar IANA, cum ar fi Europe/Berlin, nu un decalaj UTC fix. Problemele vechi menționează soluții de formatare specifice versiunii; $force_strftime nu este o setare în MRBS 1.12.2 și nu trebuie copiat din issue-ul #3967. Vezi Depanare.

Cum personalizez sau traduc pagina de ajutor și textul interfeței?¶

Pagina de ajutor în aplicație este încărcată de la web/site_faq/. De exemplu, spaniolă folosește site_faq_es.html; setați $faqfilelang = 'es' când limba trebuie selectată în mod explicit. Păstrați un fișier tradus complet pentru fiecare limbă acceptată.

Pentru modificări scurte ale interfeței, utilizați $vocab_override[LANG][TOKEN] în config.inc.php în loc să editați web/lang/lang.*. Câmpurile personalizate ale bazei de date folosesc token-uri precum entry.catering.

Vezi issue-ul #2432 și Text și traduceri.

Rapoarte, multisite și personalizare¶

Cum poate un job programat să exporte un raport sau date iCalendar?¶

Rapoartele GET neautentificate sunt dezactivate implicit. Dacă informațiile pot fi expuse în acest fel, activați-le în mod deliberat și restricționați-le cu:

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

Folosiți o cheie de neghicit, o listă îngustă pentru zonă/sala, HTTPS și un programator protejat. Testați rezultatul exact când sunteți deconectat. O adresă URL a raportului este efectiv o acreditare și poate trece prin jurnalele sau istoricul.

Vezi issue-ul #3742 și Căutare și rapoarte.

Pot mai multe site-uri MRBS să partajeze un set de tabele?¶

Nu, nu dacă rezervările și setările lor trebuie să fie separate. Fiecare site are nevoie de propriile tabele MRBS, fie într-o bază de date separată, fie cu un $db_tbl_prefix unic într-o bază de date partajată. Codul poate fi partajat, dar seturile de tabele nu trebuie să se suprapună.

Creați tabelele fiecărui site cu scripturile de schemă MRBS și aplicați-i prefixul în mod consecvent. Vezi issue-ul #3917 și Multisite.

Fiecare vizualizare sau temă solicitată este disponibilă prin configurare?¶

Nu. Solicitările, cum ar fi inserarea de text suplimentar pentru sală într-un anumit aspect al calendarului, conectarea rezervărilor altfel independente, adăugarea de niveluri de acces sau înlocuirea arhitecturii temei pot necesita modificări de cod. Înainte de a aplica un patch dintr-o problemă de asistență:

verificați dacă 1.12.2 are deja un punct de setare sau de extensie;
păstrați modificarea în afara fișierelor generate și ale furnizorului;
adăugați teste pentru crearea, editarea, ștergerea, confidențialitatea și permisiunile; şi
înregistrați personalizarea pentru următoarea actualizare.

Exemplele includ problema cu vizualizare personalizată #2223 și cerere de temă #22.