Pertanyaan yang sering diajukan¶

FAQ ini merangkum pertanyaan yang berulang dalam isu dukungan MRBS, baik yang masih terbuka maupun yang sudah ditutup. Jawabannya telah diperiksa terhadap MRBS 1.12.2; solusi lama tidak disertakan hanya karena pernah disebutkan dalam sebuah isu.

Bagaimana FAQ ini dipilih¶

Tinjauan tersebut mencakup masalah yang memiliki setidaknya satu dari label berikut: Help, Help from scratch, LDAP help need, Problems with room's capacity, support, spanish help, support request, help wanted, dan custom view help.

Pada 26 Juli 2026, label support request saja mencakup 3.076 isu: 1.590 terbuka dan 1.486 tertutup. Banyak di antaranya merupakan kasus historis yang diimpor, penyesuaian sekali pakai, permintaan fitur, atau pertanyaan tanpa jawaban terkonfirmasi. Di bawah ini hanya disertakan pertanyaan berulang yang jawabannya masih berguna untuk versi 1.12.2. Tautan isu menunjukkan asal informasi, bukan menggantikan referensi konfigurasi terkini.

Instalasi dan diagnosis¶

Mengapa saya melihat halaman kosong atau HTTP 500?¶

Baca log kesalahan server web dan PHP terlebih dahulu. Halaman kosong hanyalah gejala yang terlihat; pesan kesalahan yang berguna biasanya tercatat di log. Kemudian periksa:

versi PHP yang didukung dan ekstensi yang diperlukan;
config.inc.php dengan php -l config.inc.php;
konektivitas basis data dan driver PDO yang cocok;
izin file dan konfigurasi PHP aktif; dan
apakah permintaan yang gagal mencapai instalasi MRBS yang diinginkan.

Jangan aktifkan tampilan kesalahan PHP publik pada sistem produksi dan jangan tempelkan kredensial ke dalam masalah. Lihat Pemecahan masalah. kasus dukungan #1007 asli tidak memiliki perbaikan spesifik produk yang dikonfirmasi, itulah sebabnya jawaban ini dimulai dengan bukti dari log lokal.

Gunakan database dan nama pengguna persis yang dibuat oleh panel kontrol hosting. cPanel sering kali mengawali keduanya dengan nama akun hosting. Verifikasi juga bahwa pengguna memiliki hak istimewa pada database tersebut. SQLSTATE[28000] atau “Akses ditolak untuk pengguna” adalah kesalahan autentikasi atau pemberian database, bukan kesalahan tabel MRBS.

Jaga agar $db_database, $db_login, dan $db_password konsisten dengan nilai panel kontrol. Buat skema hanya setelah koneksi berhasil. Lihat isu #3801 dan Instalasi.

Mengapa perubahan konfigurasi tidak berpengaruh?¶

Periksa apakah Anda mengedit config.inc.php yang dimuat oleh penerapan dan situs ini. Nilai yang ditetapkan kemudian akan menggantikan nilai sebelumnya. Pengaturan disimpan untuk area yang ada di database; mengubah areadefaults.inc.php mengubah default untuk area baru saja. Dalam mode multisitus, konfirmasikan situs yang dipilih dan konfigurasinya. Terakhir, hapus atau mulai ulang PHP opcode caching jika memungkinkan.

Lihat config.inc.php secara mendalam dan Pemecahan masalah.

Masuk dan LDAP¶

Bagaimana cara mengharuskan pengguna masuk sebelum mereka melihat kalender?¶

Tetapkan:

$auth['deny_public_access'] = true;

Uji tampilan saat tidak masuk di jendela browser privat. Pengaturan ini memblokir akses publik ke kalender; pengaturan ini tidak memilih atau mengonfigurasi metode autentikasi. Lihat isu #3979 dan Pengguna dan izin.

Mengapa MRBS mengatakan bahwa ekstensi PHP LDAP tidak ada?¶

Pasang atau aktifkan ekstensi LDAP pada lingkungan PHP yang digunakan server web, lalu mulai ulang lingkungan tersebut. PHP pada baris perintah dan PHP pada server web dapat memuat file php.ini yang berbeda, jadi periksa lingkungan web dan jangan hanya mengandalkan php -m. Nama paket dan perintah mulai ulang bergantung pada sistem operasi dan instalasi PHP.

Lihat isu #1022 dan Autentikasi LDAP.

Bagaimana cara menemukan DN dasar LDAP dan DN pengguna yang benar?¶

Jangan menyimpulkan pohon direktori dari nama organisasi. Kueri dengan klien LDAP seperti ldapsearch, menggunakan server yang sama, mode TLS, DN dasar, identitas pencarian, dan atribut nama pengguna yang akan digunakan MRBS. Direktori Aktif biasanya menggunakan sAMAccountName; OpenLDAP biasanya menggunakan uid, tetapi skema direktori bersifat otoritatif.

Uji identitas pencarian secara terpisah dari pengikatan pengguna akhir dan jangan pernah mempublikasikan kata sandi pengikatan. DN yang salah adalah penyebab utama isu #1083.

Bagaimana akses LDAP dibatasi pada grup?¶

Gunakan $ldap_filter untuk memutuskan direktori mana yang dapat diakses pengguna MRBS. Untuk tata letak Direktori Aktif yang keanggotaannya disimpan pada objek pengguna, filter dapat cocok dengan memberof. Untuk tata letak gaya OpenLDAP yang keanggotaannya disimpan pada objek grup, konfigurasikan $ldap_filter_base_dn, $ldap_filter_user_attr, dan $ldap_filter yang sesuai.

Gunakan nama DN dan atribut yang tepat dari direktori, uji akun yang diizinkan dan ditolak, dan konfirmasikan perilaku grup bertingkat. Filter akses ini terpisah dari $ldap_admin_group_dn, yang mengidentifikasi MRBS administrator. Lihat isu #2033 dan LDAP autentikasi.

Jika $ldap_admin_group_dn disetel, MRBS menggunakan grup tersebut, bukan $auth['admin']. Konfirmasikan:

kelompok DN lengkap;
$ldap_group_member_attrib — memberof secara default;
bahwa identitas pencarian LDAP dapat membaca atribut keanggotaan pengguna; dan
apakah direktori mengembalikan keanggotaan langsung atau bersarang.

Aktifkan sementara diagnostik LDAP hanya di lingkungan pengujian yang dilindungi dan hapus diagnostik tersebut setelahnya. Di isu #3943, identitas pencarian awalnya tidak dapat membaca informasi grup yang diperlukan.

Mengapa LDAP bisa gagal setelah peningkatan MRBS meskipun pengikatan kata sandi berfungsi?¶

MRBS saat ini mungkin perlu mencari DN dan atribut pengguna seperti nama tampilan atau email. Jika pencarian anonim tidak tersedia, konfigurasikan:

$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';

Berikan identitas pencarian hanya izin baca yang diperlukan. Simpan kata sandinya di luar akar dokumen dan sertakan dari file konfigurasi yang dilindungi. Lihat isu #3895.

Bisakah MRBS mencari lebih dari satu direktori LDAP?¶

Ya. Banyak pengaturan LDAP, termasuk $ldap_host, $ldap_port, $ldap_base_dn, dan atribut pencarian, dapat berupa array. Jika satu parameter LDAP berkemampuan array adalah sebuah array, setiap parameter berkemampuan array harus memiliki jumlah elemen yang sama, satu per direktori.

Uji login, pencarian atribut, filter akses, dan pemetaan administrator untuk setiap direktori. Lihat isu #3981 dan bagian LDAP di systemdefaults.inc.php.

Pemesanan, ruangan, dan izin¶

Mengapa bidang pemesanan khusus berfungsi untuk satu pemesanan tetapi gagal untuk serangkaian pemesanan?¶

Setiap kolom pemesanan khusus harus ada di tabel entry dan repeat dengan nama, jenis, panjang, nullability, dan default yang sama. Perlakukan kedua kolom sebagai satu perubahan skema.

Lihat isu #3986 dan Bidang khusus.

Apakah kapasitas ruangan mencegah pemesanan dengan peserta terlalu banyak?¶

Tidak. Nilai ruangan capacity adalah metadata ruangan yang ditampilkan oleh MRBS; ini tidak secara otomatis dibandingkan dengan jumlah peserta pemesanan. Jika situs harus menerapkan aturan ini, tambahkan bidang khusus jumlah peserta yang identik ke entry dan repeat, lalu terapkan dan pertahankan validasi sisi server. Validasi sisi klien saja tidak cukup.

Jika pendaftaran diaktifkan, kapasitas acaranya mengontrol pendaftaran untuk acara tersebut; itu tidak secara otomatis memilih ruangan dengan ukuran yang sesuai. Lihat isu #1055, Area dan ruangan, dan Bidang khusus.

Bisakah satu area menggunakan slot 30 menit di pagi hari dan slot 15 menit di kemudian hari?¶

Tidak melalui konfigurasi area standar. Suatu area mempunyai resolusi satu kali. Gunakan resolusi terkecil yang diperlukan sepanjang hari, atau buat area terpisah jika sumber daya dan model operasi mengizinkannya. Resolusi yang bergantung pada waktu memerlukan penyesuaian kode yang dipertahankan.

Lihat isu #4011.

Mengapa pembuat pemesanan tidak dapat melihat Edit atau Hapus?¶

Periksa kebijakan pemesanan area yang ada melalui Ruangan. Batasan dan aturan pengeditan di muka/di masa mendatang untuk pemesanan sebelumnya dapat menghapus tindakan tersebut bahkan dari pembuatnya. Konfirmasikan juga identitas masuk, kepemilikan, status administrator, dan apakah item tersebut merupakan satu kejadian atau serangkaian.

Mengubah areadefaults.inc.php tidak memperbarui area yang ada. Lihat isu #3994 dan Kebijakan pemesanan.

Apakah ruangan yang dipilih dalam pemesanan multikamar terhubung secara permanen?¶

Nomor MRBS membuat entri pemesanan terpisah. Jika salah satu kemudian diedit atau dihapus, grup lainnya bukan grup tertaut yang tahan lama. Jangan menyalin daftar semua ruangan yang dipilih ke dalam setiap deskripsi kecuali situs juga menyimpan daftar tersebut selama operasi pembuatan, pengeditan, dan penghapusan.

Lihat isu #2223.

Dapatkah saya menambahkan lebih banyak tingkat akses atau memberikan akses laporan khusus peran saja?¶

Standar MRBS menggunakan tingkat akses 0, 1, dan 2. Peran numerik tambahan dan izin khusus halaman memerlukan penyesuaian, pengujian, dan peninjauan otorisasi lokal setelah setiap peningkatan. Patch dari masalah lama bukanlah opsi konfigurasi yang didukung.

Lebih memilih delegasi area/ruangan standar dan laporan publik dengan daftar izin sempit jika memenuhi persyaratan. Lihat isu #3999 dan Pengguna dan izin.

Email, bahasa, dan waktu¶

Mengapa proses debug email melaporkan “Tidak ada penerima”?¶

Aktifkan setidaknya satu peran penerima yang dituju:

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

Untuk opsi pertama, atur $mail_settings['recipients']. Untuk administrator area dan ruangan, simpan alamat email mereka di MRBS. LDAP pengguna memerlukan atribut email yang dapat dibaca dan dipetakan dengan benar saat pemesan diberi tahu. Kemudian uji buat, edit, dan hapus acara secara terpisah.

Lihat isu #3795 dan Pemberitahuan email.

Nilai mana yang harus saya gunakan untuk `$override_locale`?¶

Gunakan tag bahasa BCP 47 seperti en, en-GB, de, fr, atau es, bukan string lokal sistem operasi. Server harus tetap memiliki data lokal yang sesuai. Pada sistem mirip Unix, locale -a menampilkan lokal yang diinstal.

Biarkan $override_locale kosong untuk menggunakan MRBS pemilihan otomatis. Lihat isu #3984 dan Teks dan terjemahan.

Mengapa waktu yang ditampilkan tepat satu jam salah?¶

Periksa, secara berurutan:

zona waktu ruangan dan area;
global $timezone;
paket data zona waktu dan zona waktu PHP;
transisi musim panas pada tanggal yang terkena dampak; dan
apakah stempel waktu yang disimpan atau hanya tampilannya saja yang salah.

Gunakan zona waktu IANA seperti Europe/Berlin, bukan offset UTC yang tetap. Edisi lama menyebutkan solusi pemformatan khusus versi; $force_strftime bukan merupakan pengaturan di MRBS 1.12.2 dan tidak boleh disalin dari isu #3967. Lihat Pemecahan masalah.

Bagaimana cara menyesuaikan atau menerjemahkan halaman Bantuan dan teks antarmuka?¶

Halaman Bantuan dalam aplikasi dimuat dari web/site_faq/. Misalnya, bahasa Spanyol menggunakan site_faq_es.html; atur $faqfilelang = 'es' ketika bahasa harus dipilih secara eksplisit. Simpan file terjemahan lengkap untuk setiap bahasa yang didukung.

Untuk perubahan antarmuka singkat, gunakan $vocab_override[LANG][TOKEN] di config.inc.php daripada mengedit web/lang/lang.*. Bidang database khusus menggunakan token seperti entry.catering.

Lihat isu #2432 dan Teks dan terjemahan.

Laporan, multisitus, dan penyesuaian¶

Bagaimana cara pekerjaan terjadwal mengekspor laporan atau data iCalendar?¶

Laporan GET yang tidak diautentikasi dinonaktifkan secara default. Jika informasi mungkin terekspos dengan cara ini, aktifkan dengan sengaja dan batasi dengan:

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

Gunakan kunci yang tidak dapat ditebak, daftar izin area/ruangan sempit, HTTPS, dan penjadwal yang dilindungi. Uji keluaran persisnya saat keluar. URL laporan secara efektif merupakan kredensial dan dapat bocor melalui log atau riwayat.

Lihat isu #3742 dan Cari dan laporkan.

Bisakah beberapa situs MRBS berbagi satu set tabel?¶

Tidak, tidak jika pemesanan dan pengaturannya harus terpisah. Setiap situs memerlukan tabel MRBS tersendiri, baik di database terpisah atau dengan $db_tbl_prefix unik di database bersama. Kode dapat dibagikan, namun kumpulan tabel tidak boleh tumpang tindih.

Buat tabel setiap situs dengan skrip skema MRBS dan terapkan awalannya secara konsisten. Lihat isu #3917 dan Multisitus.

Apakah setiap tampilan atau tema yang diminta tersedia melalui konfigurasi?¶

Tidak. Permintaan seperti memasukkan teks ruangan tambahan ke dalam tata letak kalender tertentu, menghubungkan pemesanan independen, menambahkan tingkat akses, atau mengganti arsitektur tema mungkin memerlukan perubahan kode. Sebelum menerapkan patch dari masalah dukungan:

periksa apakah 1.12.2 sudah memiliki titik pengaturan atau ekstensi;
menyimpan perubahan di luar file yang dihasilkan dan vendor;
menambahkan tes untuk membuat, mengedit, menghapus, privasi, dan izin; dan
catat penyesuaian untuk peningkatan berikutnya.

Contohnya termasuk edisi tampilan khusus #2223 dan permintaan tema #22.