Cím megadása és visszavonása
A második tengely: mely címeket érhet el egy személy, és milyen szinten.
Az oldalon lévő 2 hívás bármelyikét lefuttatja a munkaterületén, a saját kulcsával.
POST /members/{userId}/addresses
A második tengely: mely címeket érhet el egy személy, és milyen szinten.
A hozzáférés nem szerepkör
Az access a régebbi, címenkénti szókészlet, és szándékosan nem fedi át a jogosultságneveket: a member olvassa a címet és a nevében küld, a viewer csak olvassa. Arról semmit nem mond, hogy a személy küldhet-e egyáltalán, ez a szerepkörén múlik, és mindkettőnek engedélyeznie kell a küldést, mielőtt az megtörténik.
| A szerepkörük | A hozzáférésük a billing@ címhez | Küldhetnek-e billing@ nevében |
|---|---|---|
| rendelkezik: `emails:send` | member | Igen. |
| rendelkezik: `emails:send` | viewer | Nem, a hozzáférés elutasítja. |
| nincs `emails:send` | member | Nem, a szerepkör elutasítja. |
| rendelkezik: `emails:send` | nincs hozzáférés | Nem, a cím be sem kerül abba a listába, amelyhez a küldést ellenőrzik. |
Egy szerepkör megadása nem ad címeket. Egy szerepkörrel rendelkező, de hozzáférés nélküli tag ÜRES postafiókot nyit meg, nem mindenkiét, és ez a helyes hibamód addig, amíg még döntesz arról, mit lásson.
Cím megadása
members:write szükséges. POST /members/{userId}/addresses a { addressId, access } törzzsel; az access alapértelmezése member. A teljes tagot adja vissza a jelenlegi állapotában.
curl -X POST "$OE/members/nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t/addresses" -H "$AUTH" \ -H "Content-Type: application/json" \ -d '{ "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8", "access": "viewer" }'{ "object": "member", "userId": "nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t", "email": "[email protected]", "name": "Sam Okonjo", "image": null, "role": { "id": "role_2b81de079c1f0a4b7e05d386", "name": "Support", "builtin": null }, "implied": false, "permissions": ["emails:send", "emails:read", "threads:read", "threads:write"], "addresses": [ { "addressId": "2b81de07-9c1f-4a4b-8e05-d3862c1f0a44", "address": "[email protected]", "access": "member" }, { "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8", "address": "[email protected]", "access": "viewer" } ], "createdAt": "2026-08-12T14:20:00.000Z" }POST az algyűjteményen és nem PUT a páron, mert ez mindenképp upsert, és a sorazonosítót a hívó soha nem nevezi meg. Eltérő access értékkel újraküldve lesz egy viewerből member: (cím, személy) páronként egy sor van, így egy második hívás a szintet módosítja, és nem ad hozzá második hozzáférést. Emiatt ez az a ritka POST, amely biztonságosan megismételhető.
A members:write jogosultsághoz kötött, nem a cím tulajdonjogához, és ez a különbség e hívás és a domains router régebbi hozzáférés-megadó útvonala között. A tulajdonjog a helyes feltétel annak, aki a domaint felvette, és a helytelen egy olyan adminnak, akinek semmi nem a tulajdona, és a tulajdonos nevében kezeli a munkaterület hozzáféréseit. Mindkettő ugyanazt a sort írja.
A teljes tag jön vissza, nem csak a hozzáférés, így a képernyőn lévő sor második kérés nélkül újrarajzolható, és a válasz ugyanúgy néz ki, akár új volt a hozzáférés, akár módosítás.
Egy nem ehhez a munkaterülethez tartozó cím member_not_found, 422, param: "addressId" értékkel. Egy kulcs csak annak a munkaterületnek a címeit oszthatja ki, amelyhez kiállították.
A munkaterület TULAJDONOSÁNAK adott hozzáférés member_is_owner, 422. Neki már minden címhez van hozzáférése, így a hívás semmit nem tudna hozzáadni.
Cím visszavonása
members:write szükséges. DELETE /members/{userId}/addresses/{addressId}. A tagot adja vissza, az adott cím nélkül.
curl -X DELETE \ "$OE/members/nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t/addresses/c40a95f2-1cc6-4d31-82a8-9e075d31c2a8" \ -H "$AUTH"{ "object": "member", "userId": "nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t", "email": "[email protected]", "name": "Sam Okonjo", "image": null, "role": { "id": "role_2b81de079c1f0a4b7e05d386", "name": "Support", "builtin": null }, "implied": false, "permissions": ["emails:send", "emails:read", "threads:read", "threads:write"], "addresses": [ { "addressId": "2b81de07-9c1f-4a4b-8e05-d3862c1f0a44", "address": "[email protected]", "access": "member" } ], "createdAt": "2026-08-12T14:20:00.000Z" }A szűk visszavonás, és ehhez kell nyúlni, ha valaki csapatot vált: megtartja a szerepkörét és a többi címét, ezt az egyet pedig többé nem látja.
A nem ehhez a munkaterülethez tartozó címet elutasítja, nem hagyja csendben figyelmen kívül. Különben egy elgépelt azonosító sikeres visszavonást jelentene, amely meg sem történt, és pontosan ennek a hibának a megelőzésére létezik ez a végpont.
A tag jön vissza és nem egy törlési jelzés, mert az érdekes válasz az, hogy mit érhet el még. Egy { deleted: true } itt a kliensre hagyná, hogy kivonással jöjjön rá.
Ha mindent egyszerre akarsz visszavenni, a DELETE /members/{userId} együtt eltávolítja a szerepkört és minden hozzáférést, és jelenti, hány ment el.