Medlemmer og teams
Oversat fra den engelske original. Hvis de to versioner er forskellige, gælder den engelske. Oversættelsen er endnu ikke korrekturlæst af en dansk modersmålsbruger.
Roller
Hvert medlem af en organisation har præcis én rolle på organisationsniveau.
| Rolle | Hvad de kan |
|---|---|
| Owner | Fuld administration af organisationen: administrere fakturering, konfigurere SSO og SCIM, administrere sikkerhedspolitik, invitere og fjerne medlemmer, oprette og slette repositories, tilgå alle repository-indstillinger og se revisionsloggen |
| Member | Adgang til de repositories, de har fået adgang til; kan oprette nye repositories (hvis organisationens politik tillader det); ingen adgang til organisationens administrationsindstillinger |
| Reader | Kun læseadgang til de repositories, de har fået adgang til — clone, gennemse kode, læse issues og pull requests. Kan ikke pushe, oprette repositories eller komme ind i organisationens administrationsindstillinger. Readers optager ikke en betalt plads — se Gratis læsere nedenfor |
| Guest | Kun læseadgang, men afgrænset til bestemte repositories i stedet for hele organisationen. Samme muligheder som en Reader på de repoer, de får adgang til. Gratis — Guests optager ikke en betalt plads |
| Collaborator | Skriveadgang afgrænset til bestemte repositories. Kan pushe samt oprette og lukke issues og pull requests, men kun på de repoer. Ingen adgang til organisationens administration. Optager en betalt plads |
En organisation skal altid have mindst én Owner. Du kan ikke fjerne eller nedgradere den sidste Owner.
Sådan afgøres en plads
Én regel gælder for alle rollerne ovenfor:
Du optager en betalt plads, hvis du kan skrive et sted. Hvis alt, hvad du har, er læseadgang — eller du ikke har noget — er du gratis.
Det afgøres af den rettighed, dine teams giver, ikke af deres navne. Et team med kun læseadgang, som du selv opretter, er derfor gratis uanset afgrænsning, og at omdøbe et team ændrer aldrig, hvad du betaler. Owners, Members og Collaborators kan skrive og er derfor betalte; Readers og Guests kan ikke og er det derfor ikke.
Invitation af medlemmer
Medlemsadministrationen ligger i fremforges administrationsgrænseflade på /<org>/_admin/members — siden Medlemmer viser alle nuværende medlemmer med en Administrer-skuffe for hvert medlem og en Invite-dialog øverst. Forgejos egen side frem.sh/org/<org>/teams er stadig tilgængelig som reserveløsning, når du har brug for at sammensætte mere finkornede teamrettigheder; siden i produktet dækker det daglige flow med invitation, rolle og fjernelse.
- Gå til Administration → Medlemmer (
/<org>/_admin/members). - Klik på Invite member.
- Indtast brugernavnet eller e-mailadressen på den inviterede, og vælg en rolle.
- Klik på Send invitation.
Den inviterede modtager en e-mail fra noreply@frem.sh med et link til at acceptere. Linket er gyldigt i 72 timer (styres af Forgejo). Hvis det udløber, kan du sende det igen fra afsnittet Ventende invitationer på samme side.
I afsnittet Ventende invitationer vises den inviterede som Afventer, indtil invitationen er accepteret. Ventende medlemmer:
- Har ikke adgang til nogen af organisationens ressourcer.
- Tæller ikke som en betalt plads, før de har accepteret invitationen.
- Kan til enhver tid annulleres ved at fjerne dem fra teamet, mens de stadig afventer.
Når den inviterede accepterer, skifter status til Aktiv, og personen lægges til antallet af betalte pladser ved næste faktureringsperiode. Aktivitet er ikke et krav — det er accepten, der tæller.
Gratis læsere (kun læseadgang, ingen betalt plads)
En Reader har kun læseadgang til de repositories, personen har fået adgang til — clone, gennemse kode, læse issues og pull requests — men kan ikke pushe, oprette repositories eller komme ind i organisationens administrationsindstillinger. Readers er gratis: de tæller ikke med i din pladsgrænse og faktureres aldrig. Tilføj så mange, du vil — revisorer, interessenter, konsulenter der kun skal kigge, dashboards med læseadgang og så videre.
Bag kulisserne er en Reader medlem af organisationens faste Viewers-team og af intet team, der giver skriveadgang. Optællingen af pladser følger den rettighed, et team giver, ikke dets navn: har du kun teams med læseadgang, er du gratis; har du skriveadgang et sted, bliver du faktureret. (Tilføjer du nogen til både Viewers og Members, bliver de faktureret — skriveadgang vinder.)
Fordi reglen bygger på rettigheder og ikke på navne, er et team med kun læseadgang, som du selv opretter — Auditors, Stakeholders eller hvad du nu kalder det — også gratis, og at afgrænse det til en håndfuld repositories ændrer ikke på det. Brug Guests, når det netop er det, du vil have: gratis læseadgang til udvalgte repositories.
Tilføj en læser
Alle disse veje virker; vejen i produktet er den enkleste:
- Fra siden Medlemmer (anbefalet). Gå til Administration → Medlemmer (
/<org>/_admin/members) → Invite member → indtast e-mailadressen → vælg Viewers (og intet andet) under Team(s) → Send invitation. Når personen accepterer, bliver vedkommende tilføjet som gratis læser. - Konvertér et eksisterende medlem. Åbn medlemmets Administrer-skuffe, og flyt personen til Viewers (fjern vedkommende fra Members/Owners). Personen falder ud af antallet af betalte pladser ved næste faktureringsperiode.
- Automatisk via SSO. Knyt en gruppe i identitetsudbyderen til Viewers-teamet (se SSO og SCIM). Alle i gruppen bliver provisioneret som gratis læsere — der er ikke brug for invitationer til hver enkelt.
- Forgejos egen reserveløsning.
frem.sh/org/<org>/teams→ Viewers → Add team member. Brug kun denne vej, når du har brug for en mere finkornet teamsammensætning; siden Medlemmer dækker det normale tilfælde.
Gratis læsere tælles separat fra betalte pladser i dit faktureringsoverblik (Administration → Fakturering) og i seats-API’et, så du altid kan se, hvor mange gratis læsere du har i forhold til, hvor mange betalte pladser du bruger.
Ikke det samme som en læser af kun dokumentation. Hvis du vil give nogen adgang til at læse jeres publicerede dokumentation uden nogen adgang til repositories og helt uden en Forgejo-konto, skal du ikke tilføje dem til Viewers — giv i stedet deres SSO-gruppe en tom tilknytning fra gruppe til team. Se Wiki and public docs. En Reader (Viewers-teamet) får en Forgejo-konto og læseadgang til de repoer, personen har fået adgang til; en læser af kun dokumentation gør ikke.
Guests (gratis læseadgang, bestemte repositories)
En Reader kan læse alle repositories i organisationen. En Guest læser kun de repositories, du vælger. Begge er gratis — læseadgang koster aldrig en plads, uanset afgrænsning.
Brug Guests til en konsulent, der skal gennemgå én service, en revisor, der har brug for to repositories frem for fyrre, eller et partnerteam, som du vil holde ude af alt andet. Det er den mindst privilegerede udgave af en Reader, og den koster det samme: ingenting.
Guests er det faste Guests-team, som oprettes i alle organisationer og er afgrænset til bestemte repositories i stedet for dem alle.
Tilføj en gæst
- Gå til Administration → Medlemmer → Invite member → indtast e-mailadressen → vælg Guests (og intet andet) under Team(s).
- Vælg, hvilke repositories Guests-teamet kan læse:
frem.sh/org/<org>/teams/guests→ Repositories → tilføj de repositories, du vil have med. - Send invitationen. Når personen accepterer, kan vedkommende læse præcis de repositories.
Hvis du vil begrænse en eksisterende gratis Reader til bestemte repositories, så åbn personens Administrer-skuffe og flyt vedkommende fra Viewers til Guests. Personen er gratis i begge tilfælde.
Guests og Collaborators styres af fremforge og kan ikke slettes. De bestemmer, hvad du betaler — Guests holder læsere afgrænset til repositories gratis, og Collaborators er det, der gør en skriver afgrænset til repositories til en betalt plads. Hvis det ene af dem blev fjernet, ville din organisation stille og roligt få en ny pris, så begge er låst, ligesom Members og Viewers. Du kan frit ændre, hvilke repositories hvert team dækker, og hvem der er med i det.
Når alle pladser er brugt
Hvis din organisation har nået sin pladsgrænse, får et medlem, der forsøger at tilgå organisationen, vist en “seats full”-side på /<org>/seats-full i stedet for den ressource, personen bad om. Fra den side kan personen med ét klik sende en anmodning om en ekstra plads til organisationens ejere.
Ejerne modtager anmodningen (via e-mail og i administrationens notifikationsklokke) og kan tilføje en plads under Administration → Fakturering, hvilket fjerner blokeringen for det ventende medlem. Hæv pladsgrænsen, før medlemmet kan fortsætte; indtil da er personens adgang sat på pause på seats-full-siden.
Ændring af roller
Et medlems rolle (Owner, Member eller Reader) ændres i produktet fra Administrer-skuffen på siden Medlemmer. Bag kulisserne svarer rollen til medlemskab af Forgejo-teams: Owners = fuld administration af organisationen, Members = afgrænset læse-/skriveadgang bestemt af teamets repo-tildelinger, Viewers = kun læseadgang (og gratis). Flytter du et medlem, så det kun er i Viewers, falder det ud af antallet af betalte pladser ved næste faktureringsperiode.
- Gå til Administration → Medlemmer (
/<org>/_admin/members). - Åbn Administrer-skuffen for medlemmet.
- Vælg den nye rolle, og bekræft. Den tilsvarende ændring af Forgejo-teams træder i kraft med det samme.
Til en mere finkornet teamsammensætning (egne teams, tildelinger afgrænset til repoer) bruger du Forgejos egen teamside på frem.sh/org/<org>/teams. Rolleændringer træder i kraft med det samme. Der er ingen overgangsperiode, og der sendes ingen bekræftelsesmail til medlemmet.
Fjernelse af et medlem
- Gå til Administration → Medlemmer (
/<org>/_admin/members). - Åbn Administrer-skuffen for medlemmet, og vælg Remove member.
- Bekræft fjernelsen.
Det sker med det samme:
- Adgangen til alle organisationens repositories trækkes tilbage.
- Alle aktive sessioner (browser eller API) for brugeren bliver ugyldige.
- Medlemmet fjernes fra alle teamtildelinger i organisationen.
Det ændrer sig ikke:
- Repositories slettes ikke. Repoer tilhører organisationen, ikke de enkelte medlemmer. Et medlem, der ejede repoer i organisationen, tager ikke repoerne med, når vedkommende forlader den.
- Issues, PR’er og commits forbliver tilskrevet personens brugernavn. Historikken over bidrag bevares.
- Åbne PR’er og issues, som personen har oprettet, forbliver åbne og uændrede.
Det fjernede medlem tages ud af antallet af betalte pladser ved næste faktureringsperiode. Der gives ingen kreditering for den aktuelle periode.
Tjekliste til offboarding
Når et medlem forlader organisationen, så gå denne tjekliste igennem, før du gennemfører fjernelsen.
- Overdrag ejerskab af repositories, hvis medlemmet, der stopper, selv ejer repoer direkte (tjek Administration → Repositories for repoer med personens brugernavn som ejer). Overdrag dem til organisationen eller til et andet medlem, før personen fjernes.
- Rotér hemmeligheder, som personen kan have kendt. Tjek, hvilke hemmeligheder der blev oprettet eller sidst opdateret, mens personen havde adgang. Rotér dem, der nu er eksponeret, fordi personen stopper.
- Tilbagekald API-tokens, som personen har oprettet. Gå til Administration → API-tokens (
/<org>/_admin/api-tokens) for at se alle organisationens API-tokens. Tilbagekald alle tokens, som medlemmet, der stopper, har oprettet. - Tjek personlige access tokens (PAT’er). PAT’er er knyttet til brugerens konto, ikke til organisationen. Når personen er fjernet fra organisationen, kan vedkommendes PAT’er ikke længere tilgå organisationens ressourcer. Men hvis medlemmet var Owner, så bekræft, at ingen tokens med udvidede scopes er delt med eksterne systemer i personens navn.
- Gennemgå aktive integrationer og webhooks. Hvis en webhook eller en ekstern integration godkender sig som denne bruger, så opdatér den til at bruge et API-token for organisationen eller en anden konto.
Deprovisionering styret af SCIM
Hvis SCIM-provisionering er konfigureret for organisationen, styres brugernes livscyklus af den tilknyttede IdP (Okta, Entra ID osv.). Når du deaktiverer eller fjerner en bruger i IdP’en, bliver personen automatisk deaktiveret i fremforge inden for SCIM-synkroniseringsintervallet, som typisk er under fem minutter.
Når en bruger deaktiveres via SCIM:
- Personens fremforge-session bliver ugyldig med det samme.
- Personen kan ikke logge ind via SSO eller med lokal adgangskode.
- Personens plads fjernes fra antallet af betalte pladser ved næste faktureringsperiode.
Manuel fjernelse via Administration → Medlemmer er ikke nødvendig, når SCIM er aktivt. IdP’en er den autoritative kilde til medlemskab. Hvis du fjerner en bruger i fremforge uden at deaktivere vedkommende i IdP’en, vil SCIM provisionere personen igen ved næste synkronisering.
Se SCIM-provisionering for vejledning i opsætning.
Medlemmer der kun bruger SSO
Et medlem, der kun nogensinde har logget ind via SSO, har ingen lokal fremforge-adgangskode. Personens identitet styres udelukkende af IdP’en.
Sådan blokerer du adgangen for et medlem, der kun bruger SSO:
- Tilbagekald personens adgang i IdP’en (deaktivér kontoen, fjern tildelingen til appen, eller slå SSO fra for kontoen).
- Fjern eventuelt også personen fra organisationen i fremforge for at rydde op i antallet af pladser.
Det er nok at tilbagekalde adgangen i IdP’en for at forhindre login. fremforge-sessionen fejler ved næste SSO-validering. Hvis SCIM er slået til, udløser deaktiveringen i IdP’en også automatisk deprovisionering, uden at du manuelt skal fjerne personen fra organisationen.
Geninvitation af et tidligere medlem
Hvis du vil invitere en person, der tidligere er blevet fjernet, sender du helt almindeligt en ny invitation fra Administration → Medlemmer → Invite member.
Når personen vender tilbage:
- Tidligere commits, issues og PR’er forbliver tilskrevet personens brugernavn.
- Adgang til repositories bestemmes på ny ud fra rollen i organisationen og eventuelle collaborator-tildelinger på repo-niveau. Ingen tidligere adgangskonfiguration gendannes automatisk.
Hvis det tidligere medlem har slettet sin fremforge-konto efter at være stoppet, kan brugernavnet blive vist med en markering for slettet konto på historiske bidrag. Hvis en anden person i mellemtiden har taget brugernavnet, afspejler den historiske tilskrivning den oprindelige konto via det underliggende bruger-id, ikke kun brugernavnet som tekst.
Rettigheder pr. repository
Roller på organisationsniveau bestemmer grundadgangen. Hvis du vil have mere finkornet kontrol, kan du tilføje enkelte brugere som collaborators på bestemte repositories.
Tilføj en collaborator:
- Gå til Repository → Settings → Collaborators.
- Søg efter brugeren på brugernavn eller e-mail.
- Vælg et rettighedsniveau:
| Rettighed | Hvad de kan |
|---|---|
| Read | Clone, pull, se issues og PR’er |
| Write | Læseadgang plus push af branches, oprette og lukke issues og PR’er |
| Admin | Skriveadgang plus administration af repository-indstillinger, branch protection, webhooks og hemmeligheder |
Collaborator-rettigheder lægges oven i brugerens rolle i organisationen og erstatter den ikke — den højeste af de to gælder. En Reader med Write-collaboratoradgang til et repo kan pushe til det repo. En Owner, der er collaborator, får ikke noget ud over det, Owner-rollen allerede giver.
Collaborators skal være medlemmer af din organisation
En collaborator skal være medlem af den organisation, der ejer repositoryet. Du kan ikke tilknytte en person fra en anden organisation, og du kan ikke tilføje en udefrakommende konto direkte til et repository — invitér personen til organisationen først (som Guest, hvis vedkommende kun skal have læseadgang), og giv derefter adgang til repositoryet.
Det er en ændring i forhold til tidligere, hvor en repository-administrator kunne tilknytte en hvilken som helst eksisterende konto på instansen. Kravet om medlemskab betyder, at alle med adgang til jeres kode vises under Administration → Medlemmer, og det er også det, der gør adgangsgennemgange og offboarding komplette.
Hvad en collaborator koster
Kun skriveadgang koster en plads:
| Collaborator-rettighed | Plads |
|---|---|
| Read | Gratis — det samme som en Guest, afgrænset til det repository |
| Write eller Admin | Optager en betalt plads |
Giver du skriveadgang til en person, der i dag er gratis (en Reader eller Guest), bliver vedkommende automatisk tilføjet det faste Collaborators-team, og det er det, der gør personen til en betalt plads. Du behøver ikke flytte personen manuelt. En person, der allerede er betalt — en Member, en Owner eller en eksisterende Collaborator — bliver ikke opkrævet to gange.
Hvis den plads vil bringe dig over din pladsgrænse:
- Med pladsoverskridelse (seat overage) slået til lykkes tildelingen, og den ekstra plads kommer med på din næste faktura.
- Med pladsoverskridelse slået fra afvises tildelingen, og du bliver henvist til Administration → Fakturering → Pladser. At slå pladsoverskridelse fra under Administration → Fakturering er måden at forhindre fremforge i automatisk at tilføje betalte pladser på — det er den samme indstilling, der styrer invitationer og medlemmer provisioneret via SSO.
Når du fjerner en persons plads, fjerner du ikke vedkommendes adgang helt. Skriveadgange, der ikke længere er dækket af en plads, nedgraderes til læseadgang efter en overgangsperiode på 7 dage, så en Collaborator, der mister sin plads, bliver det samme som en Guest i stedet for at blive lukket ude. Gendanner du pladsen inden for den periode, ændres intet.
Via REST API
Det daglige flow for medlemmers livscyklus (invitér / list / tilbagekald / fjern) er tilgængeligt i det offentlige API. Brug det, når du scripter onboarding fra et HR-system, automatiserer offboarding eller styrer driften fra en AI-agent.
- List invitationer
GET /_app/api/v1/orgs/:slug/members/invitations?status=pending(scopeseats:read) - Invitér et medlem
POST /_app/api/v1/orgs/:slug/members/invitationsbody:{ "email": "...", "full_name": "...", "team_names": [...] }(scopeseats:write) - Tilbagekald en ventende invitation
DELETE /_app/api/v1/orgs/:slug/members/invitations/:id(scopeseats:write) - Fjern et medlem
DELETE /_app/api/v1/orgs/:slug/members/:login(scopeseats:write) - Tildel / afvis et pladsforbehold (seat hold)
POST /_app/api/v1/orgs/:slug/members/seat-holds/:id/granteller.../dismiss(scopeseats:write)
Kræver et Personal Access Token (PAT) med scopet seats:write:
curl -X POST \
-H "Authorization: Bearer ${FREMFORGE_PAT}" \
-H "Content-Type: application/json" \
-d '{"email":"new.hire@example.com","full_name":"New Hire","team_names":["engineering"]}' \
https://frem.sh/_app/api/v1/orgs/acme/members/invitationsSe referencen for det offentlige REST API for den fulde OpenAPI-specifikation.
Krydshenvisninger
- SCIM-provisionering, automatiseret livscyklus for brugere via Okta, Entra ID eller enhver IdP, der understøtter SCIM 2.0
- OIDC SSO, konfigurér SSO, så medlemmer logger ind med deres virksomhedsidentitet
- Billing, hvordan pladser tælles, og hvornår fjernede medlemmer forsvinder fra antallet af betalte pladser
- Administration, fuld reference for organisationens administrationsflade
- API, administrér medlemmer programmatisk via REST API’et