Baza wiedzy
Role i poziomy uprawnień
Rola mówi, co ktoś może robić; przydział adresu mówi, na czym może to robić.
Szczegóły
- Dwa przydziały na osobę i oba muszą się zgodzić, zanim cokolwiek się wydarzy. ROLA, ustawiana w Ustawienia → Członkowie, mówi, co dana osoba może ROBIĆ w przestrzeni roboczej: czytać pocztę, wysyłać ją, edytować szablony, dodać domenę, wygenerować klucz API. PRZYDZIAŁ adresu, ustawiany z kontrolki Udostępnij w wierszu adresu, mówi, na których ADRESACH może to robić, w trybie tylko do odczytu albo odczyt i wysyłka. Ktoś z rolą zawierającą wysyłkę i bez adresów nie może wysłać znikąd; ktoś, kto ma wszystkie adresy w przestrzeni roboczej w trybie tylko do odczytu, też nie wyśle z żadnego.
- Sześć ról istnieje, zanim ktokolwiek je utworzy, i każda przestrzeń robocza ma te same sześć, więc „Admin” znaczy tu to samo, co w dokumentacji i w API. Owner, Admin, Member i Viewer tworzą drabinę: każda ma wszystko, co następna, więc obniżenie komuś roli zawęża to, do czego sięga, zamiast wymieniać na inny wycinek. Developer i Billing nie są szczeblami tej drabiny. Developer buduje integracje, trzymając klucze API, webhooki, szablony i wysyłkę, nie czytając żadnej poczty przestrzeni roboczej, a Billing widzi plan i faktury, może zmienić plan i dane płatności, a ustawienia skrzynki czyta bez możliwości zapisu. Ich uprawnienia są edytowalne: przestrzeń robocza, która woli, by jej członkowie nie pisali szablonów, odznacza to, a zmiana zaczyna obowiązywać przy kolejnym żądaniu każdego, kto WPROST tę rolę posiada. Ktoś, czyja rola jest wciąż tylko domniemana z przydziału adresu nadanego przed wprowadzeniem ról, zachowuje domyślne ustawienia fabryczne, dopóki nie dostanie roli wprost. Ich nazwy też są edytowalne: przestrzeń robocza działająca na Ops i On-call zmienia im nazwy i opisuje samą siebie, o co właśnie chodzi.
- Owner jest wyjątkiem pod każdym względem: nieedytowalny, nieusuwalny, nieprzypisywalny. Opisuje konto, na którym oparta jest przestrzeń robocza, i ma każde uprawnienie, łącznie z dodanymi w późniejszym wydaniu, dlatego jego lista jest wyliczana, a nie przechowywana. Przekazanie przestrzeni roboczej komuś innemu jest transferem, a nie zmianą roli, i nie ma tu niczego, co by go dokonywało.
- Poza nimi przestrzeń robocza pisze własne, do 24 w sumie, zaznaczając uprawnienia w tej samej pogrupowanej macierzy. Zaznaczenie implikuje: „edytuj szablony” zapisuje obok „czytaj szablony”, bo rola, która może edytować szablon, którego nie może otworzyć, jest zapomnianym polem wyboru, a nie czyjąkolwiek polityką. Usunięcie roli, którą mają ludzie lub klucze API, pyta, dokąd ich przenieść, i odmawia, zamiast zgadywać. Klucz, którego rola zniknęła, spadłby do braku jakiegokolwiek pułapu, co jest szersze niż rola, która właśnie odeszła.
- Klucz API można wystawić względem roli, a rola jest pułapem, a nie drugim przydziałem: to, co klucz może zrobić, to jego własne zakresy przecięte z uprawnieniami roli, rozstrzygane przy każdym żądaniu. Klucz utworzony z wysyłką i ograniczony rolą Viewer nie wyśle, a zawężenie roli odbiera uprawnienia na żywo, bez konieczności rotacji klucza. Asystent podlega tej samej liście, a serwer MCP buduje narzędzia klienta z uprawnień wywołującego, więc klient osoby z rolą Viewer nie ma w sobie w ogóle narzędzia do wysyłki, a każde bramkowane narzędzie sprawdza uprawnienia ponownie na wejściu, bo sesja może przełączyć skrzynki po zbudowaniu listy.