Test: FluentBooking / Setari / Membru de echipa + primul test de rol cu drepturi reduse

Capabilitate: team_member_add — mai multe persoane care primesc programari, fiecare cu drepturile ei.

Rulari: run-fb-team-20260811 (scriere) + run-fb-team-cert-20260811 (certificare, 7/7 dovezi) · Ruta: POST /wp-json/fluent-booking/v2/settings/team → HTTP 200

De ce a fost nevoie de un cont nou

Ruta refuza, prin design, orice utilizator cu drepturi de administrator — deci pe un site care are DOAR administratori e inutilizabila. Am creat pl-member (rol abonat, fara drepturi de administrare) si i-am dat o singura permisiune: sa-si administreze propriul calendar.

Primul test real cu drepturi reduse

Pana acum, toate testele proiectului rulasera cu cont de administrator — deci nu spuneau nimic despre ce vede un utilizator obisnuit. Acum stim, verificat:

• Listarile sunt filtrate corect. Membrul cere lista de calendare si primeste raspuns valid, dar GOL. La fel la rezervari — numele si emailul participantului nu sunt expuse.
• Accesul direct pe identificator e refuzat. Calendarul altei gazde, programul ei de disponibilitate, webhook-urile si integrarile evenimentelor ei: toate refuzate. Rezervarea altcuiva: negasita.
• Setarile de echipa sunt refuzate — un membru nu-si poate schimba singur permisiunile.
• Interfata se restrange vizibil: meniul WordPress ramane cu Dashboard, Fluent Booking si Profil; butoanele de creare si de setari dispar din FluentBooking.

Concluzie: modelul de permisiuni al plugin-ului tine. Nu am gasit nicio scurgere de date intre gazde. Asta e o constatare pozitiva, dar acum e verificata, nu presupusa.