Rollefordelingen
Ejeren opretter arbejdsrummet og kan administrere dets medlemmer og apps. En administrator kan administrere team og credentials, men overtager ikke automatisk ejerskabet. En udvikler kan registrere og redigere apps, indsende til review og arbejde med sandbox. En læser kan se den tilladte arbejdsrumsinformation, men ikke udstede credentials eller ændre appens state.
Serveren afgør rollerne ud fra arbejdsrummets medlemsliste. UI’et deaktiverer relevante knapper, men det er ikke tilstrækkeligt: alle skrivninger går gennem en rollechecket serverkommando. Et klientvalgt role-felt kan ikke gøre en udvikler til ejer eller Hours-reviewer.
Visse handlinger kræver både korrekt arbejdsrumsrolle og AAL2. Det gælder bl.a. klienthemmeligheder og webhooksigneringshemmeligheder. En udviklerrolle er således ikke en indirekte tilladelse til at hente appens fortrolige produktionscredential.
Invitation og accept
En ejer eller administrator angiver e-mail og rolle og opretter et invitationslink. Serveren gemmer et hash af en tilfældig hin_-kode. Den rå kode vises én gang og leveres som et kopierbart link; Hours sender ikke en mail på brugerens vegne.
Linket udløber efter 72 timer og kan kun accepteres med den inviterede, bekræftede e-mail. Serveren kontrollerer samtidig, at arbejdsrummet fortsat er aktivt, og at inviterende person stadig har en administrativ rolle. En invitation skaber ikke et abonnement eller en kundetilknytning.
Accept er eksplicit. At åbne linket ændrer ikke i sig selv et medlemskab. Er personen allerede medlem, overskriver accept ikke vedkommendes rolle med en gammel invitation. Rolleændringer foretages som en særskilt administrativ handling.
Ejerens særlige rolle
Ejeren er beskyttet mod almindelig fjernelse eller rolleændring gennem teamkommandoerne. Det undgår et arbejdsrum uden ansvarlig ejer. En fuld, bekræftet ejerskabsoverdragelse er ikke tilgængelig som en knap; den skal ikke simuleres ved først at slette ejeren.
Ejerskifte, døde konti og juridiske ændringer hos udgiveren håndteres uden for teamkommandoerne og ikke gennem en generisk adminomgåelse i partnerflowet.
Offboarding og kopierede hemmeligheder
Når et medlem fjernes, stopper nye konsolhandlinger og sandboxtokens, der er bundet til vedkommendes aktuelle medlemskab. En klienthemmelighed kan imidlertid allerede være kopieret til en server eller en persons egne noter. Fjernelse fra teamlisten sletter ikke den viden.
Rotér app-ejede credentials ved relevant offboarding. Suspendér appen, når der er mistanke om kompromittering, og afklar kundegrants separat. Opret den nye hemmelighed, installér den i integrationens secret manager, test tokenudveksling og tilbagekald den gamle. Gem ikke hemmeligheder i delte kodeeksempler eller projektbeskrivelser.
Samtidig administration
Teamændringer og appadministration anvender en arbejdsrumsafgrænset låserækkefølge. Medlemskabet kontrolleres efter låsen, så en operation ikke fortsætter på en rolle, der er blevet fjernet, mens den ventede. Låsen er ikke global på tværs af alle udviklerarbejdsrum.
Det betyder, at fjernelse under appredigering, accepteret invitation efter inviterens fjernelse og credentialudstedelse efter degradering afvises korrekt, hvis rollen ikke længere gælder.
Hvad teamet kan se
Konsollen viser appprofiler, revisionsstatus, credentialmetadata, egne sandboxoplysninger, reviewbegrundelser, et begrænset udsnit af webhookforsøg og arbejdsrummets aktivitetslog. Den genviser ikke rå credentialværdier. Kundens egne grantoversigter vises gennem en separat ejerautoriseret visning.
Vurdér adgangsbehovet til profil-, review- og driftsmetadata, før et større udviklerteam tages i brug. Læserrollen er ikke nødvendigvis passende for eksterne observatører, blot fordi den ikke kan skrive. Mindst mulig adgang gælder også administrative metadata.