Kalo te dokumentacioni
Baza e njohurive

Rolet dhe nivelet e lejeve

Një rol thotë çfarë mund të bëjë dikush; një akordim adrese thotë mbi çfarë mund ta bëjë.

Hollësi

  • Dy akordime për person, dhe të dyja duhet të pajtohen para se të ndodhë diçka. ROLI, i caktuar te Cilësimet → Anëtarët, thotë çfarë mund të BËJNË në hapësirën e punës: të lexojnë postë, ta dërgojnë, të redaktojnë shabllone, të shtojnë një domen, të krijojnë një çelës API. AKORDIMI i adresës, i caktuar nga kontrolli Ndaj mbi rreshtin e adresës, thotë mbi cilat ADRESA mund ta bëjnë, vetëm për lexim ose për lexim dhe dërgim. Dikush që mban një rol me dërgim brenda dhe asnjë adresë nuk mund të dërgojë nga asgjë; dikush që mban çdo adresë të hapësirës së punës nën një akordim vetëm për lexim nuk mund të dërgojë as nga asnjëra prej tyre.
  • Gjashtë role ekzistojnë pa i krijuar askush dhe çdo hapësirë pune ka të njëjtat gjashtë, prandaj “Admin” do të thotë e njëjta gjë këtu, në dokumentacion dhe në API. Owner, Admin, Member dhe Viewer janë një shkallare: secili mban gjithçka që mban tjetri, prandaj ulja e dikujt ngushton atë që mund të arrijë, në vend që t'ia zëvendësojë me një pjesë tjetër. Developer dhe Billing nuk janë shkallë të asaj shkallareje. Developer ndërton integrime, duke mbajtur çelësa API, webhook-e, shabllone dhe dërgim, ndërsa nuk lexon asnjë mesazh të hapësirës së punës, kurse Billing sheh planin dhe faturat, mund të ndryshojë planin dhe të dhënat e pagesës mbi to, dhe lexon cilësimet e kutisë postare pa mundur të shkruajë ndonjë. Lejet e tyre janë të redaktueshme: një hapësirë pune që parapëlqen që anëtarët të mos shkruajnë shabllone e çshënon, dhe ndryshimi hyn në fuqi te kërkesa e radhës e kujtdo që e mban atë rol SHPREHIMISHT. Dikush roli i të cilit nënkuptohet ende nga një akordim adrese i bërë para se të ekzistonin rolet i ruan parazgjedhjet e dërguara derisa t'i jepet një rol drejtpërdrejt. Po ashtu janë edhe emrat e tyre: një hapësirë pune që funksionon me Ops dhe On-call i riemërton dhe po përshkruan veten, që është pikërisht qëllimi.
  • Owner është përjashtimi në çdo drejtim: i paredaktueshëm, i pafshirshëm, i paakordueshëm. Ai përshkruan llogarinë mbi të cilën është çelësuar hapësira e punës dhe mban çdo leje, përfshirë ato të shtuara në një version të mëvonshëm, prandaj lista e tij llogaritet e nuk ruhet. Kalimi i hapësirës së punës te dikush tjetër është transferim e jo ndryshim roli, dhe këtu nuk ka asgjë që e bën një të tillë.
  • Përtej tyre, një hapësirë pune shkruan të vetat, deri në 24 gjithsej, duke shënuar leje nga e njëjta matricë e grupuar. Shënimi nënkupton: “redakto shabllonet” ruan krahas tij edhe “lexo shabllonet”, sepse një rol që mund të redaktojë një shabllon që nuk e hap dot është një kuti që dikush e harroi e jo një politikë që dikush e do. Fshirja e një roli që e mbajnë njerëz ose çelësa API pyet ku t'i zhvendosë dhe refuzon në vend që të hamendësojë. Një çelës roli i të cilit zhduket do të binte te asnjë tavan fare, që është më i gjerë se roli që sapo iku.
  • Një çelës API mund të lëshohet kundrejt një roli, dhe roli është tavan e jo një akordim i dytë: ajo që mund të bëjë çelësi janë shtrirjet e tij të prera me lejet e rolit, të zgjidhura në çdo kërkesë. Një çelës i krijuar me dërgim mbi të dhe i kufizuar nga Viewer nuk mund të dërgojë, dhe ngushtimi i një roli e revokon atë në çast pa qenë nevoja të rrotullohet çelësi. Asistenti mbahet te e njëjta listë, dhe serveri MCP i ndërton mjetet e një klienti nga lejet e thirrësit, prandaj klienti i një viewer-i nuk ka fare mjet dërgimi brenda, ndërsa çdo mjet i kufizuar rikontrollohet në hyrje, sepse një sesion mund të ndërrojë kuti postare pasi lista është ndërtuar.