Medlemmer og team

Roller

Hvert medlem i en organisasjon har nøyaktig én rolle på organisasjonsnivå.

En organisasjon må alltid ha minst én Owner. Du kan ikke fjerne eller degradere den siste Owner.

Hvordan det avgjøres om noen er en betalt bruker

Én regel dekker alle rollene over:

Du er en betalt bruker hvis du kan skrive et sted. Hvis alt du har, er lesetilgang, eller du ikke har noe, er du gratis. Det eneste unntaket er teamet Auditors: de første 5 medlemmene med lesetilgang er gratis, og hver av dem etter det er en betalt bruker.

Bortsett fra Auditors avgjøres dette av tillatelsen teamene dine gir, ikke av navnene deres. Et team med bare lesetilgang som du oppretter selv, er derfor gratis uansett omfang, og å gi et team nytt navn endrer aldri hva du betaler. Owners, Members og Collaborators kan skrive, så de er betalte brukere; Readers og Guests kan ikke det, så de er ikke det.

Invitere medlemmer

Medlemsadministrasjonen ligger i adminflaten i fremforge på /<org>/_admin/members. Siden Members viser hvert nåværende medlem med en Manage-skuff per medlem og en Invite-dialog øverst. Forgejos egen side frem.sh/org/<org>/teams er fortsatt tilgjengelig som reserveløsning når du trenger å sette sammen mer finmaskede teamtillatelser; siden i produktet dekker den daglige flyten med invitasjoner, roller og fjerning.

1. Gå til Organisasjonsadministrasjon → Medlemmer (/<org>/_admin/members).
2. Klikk Inviter via e-post.
3. Skriv inn brukernavnet eller e-postadressen til den du inviterer, og velg en rolle.
4. Klikk Send invitasjon.

Den inviterte får en e-post fra noreply@frem.sh med en lenke for å godta. Lenken er gyldig i 7 dager. Hvis den utløper, sender du den på nytt fra seksjonen Ventende invitasjoner på samme side.

I seksjonen Ventende invitasjoner vises den inviterte som Venter til invitasjonen er godtatt. Ventende medlemmer:

• har ikke tilgang til noen ressurser i organisasjonen.
• teller ikke som betalt bruker før de godtar invitasjonen.
• kan avbrytes når som helst ved å fjerne dem fra teamet mens de fortsatt venter.

Når den inviterte godtar, endres statusen til Aktiv, og personen legges til i antallet betalte brukere ved neste faktureringsperiode. Aktivitet kreves ikke; det er godtakelsen som teller.

Gratis lesere (lesetilgang, ingen betalt bruker)

En Reader har lesetilgang til repositoryene personen får: klone, bla i koden, lese issues og pull requests, men kan ikke pushe, opprette repositoryer eller nå organisasjonsadministrasjonen. Readers er gratis: de teller ikke mot brukertaket ditt og faktureres aldri. Legg til så mange du vil: interessenter, konsulenter som bare trenger å se, dashbord med lesetilgang og så videre. En som også trenger å lese organisasjonsinnstillingene, for eksempel en samsvarsrevisor, hører i stedet hjemme i Auditors.

Teknisk sett er en Reader medlem av organisasjonens faste team Viewers og av ingen team som gir skrivetilgang. Tellingen av brukere følger tillatelsen et team gir, ikke navnet: har du bare team med lesetilgang, er du gratis; har du skrivetilgang et sted, faktureres du. (Hvis du legger noen til i både Viewers og Members, faktureres personen; skrivetilgang vinner.)

Fordi regelen bygger på tillatelser og ikke på navn, er også et team med bare lesetilgang som du oppretter selv, gratis, enten det heter Stakeholders, Reviewers eller noe annet, og det endrer seg ikke om teamet avgrenses til en håndfull repositoryer. Bruk Guests når du vil ha akkurat det: gratis lesetilgang til utvalgte repositoryer. Det faste teamet Auditors er ikke et av disse: fremforge oppretter det, det når organisasjonsinnstillingene i tillegg til koden, og bare de første 5 medlemmene er gratis (se Revisorer).

Legge til en leser

Hvilken som helst av disse fungerer; veien i produktet er den enkleste:

1. Fra siden Members (anbefalt). Gå til Organisasjonsadministrasjon → Medlemmer (/<org>/_admin/members) → Inviter via e-post → skriv inn e-postadressen → velg Viewers (og ingenting annet) under Team → Send invitasjon. Når personen godtar, blir den med som gratis leser.
2. Gjør om et eksisterende medlem. Åpne medlemmets Administrer-skuff og flytt personen til Viewers (fjern den fra Members/Owners). Personen faller ut av antallet betalte brukere ved neste faktureringsperiode.
3. Automatisk via SSO. Koble en gruppe hos identitetsleverandøren til teamet Viewers (se SSO og SCIM). Alle i den gruppen provisjoneres som gratis lesere, uten invitasjon per person.
4. Reserveløsning i Forgejo. frem.sh/org/<org>/teams → Viewers → Legg til teammedlem. Bruk dette bare når du trenger en mer finmasket teamsammensetning; siden Members dekker det vanlige tilfellet.

Gratis lesere telles separat fra betalte brukere i faktureringssammendraget (Organisasjonsadministrasjon → Fakturering) og i API-et for brukere, så du alltid kan se hvor mange gratis lesere du har sammenlignet med hvor mange betalte brukere du bruker.

Ikke det samme som en leser av bare dokumentasjon. Hvis du vil at noen skal kunne lese den publiserte dokumentasjonen din, men ikke ha tilgang til repositoryer og ingen Forgejo-konto i det hele tatt, skal du ikke legge personen til i Viewers. Gi i stedet SSO-gruppen personen er i, en tom kobling fra gruppe til team. Se Wiki og offentlig dokumentasjon. En Reader (teamet Viewers) får en Forgejo-konto og lesetilgang til repositoryene den får; en leser av bare dokumentasjon gjør ikke det.

Gjester (gratis lesetilgang, bestemte repositoryer)

En Reader kan lese hvert repository i organisasjonen. En Guest leser bare repositoryene du velger. Begge er gratis: å lese kode koster aldri en betalt bruker, uansett omfang.

Bruk Guests for en konsulent som går gjennom én tjeneste, en revisor som trenger to repositoryer og ikke førti, eller et partnerteam du vil holde unna alt annet. Det er versjonen av en Reader med minst mulig tilgang, og den koster det samme: ingenting.

Gjester er det faste teamet Guests, som opprettes i hver organisasjon og er avgrenset til bestemte repositoryer i stedet for alle.

Legge til en gjest

1. Gå til Organisasjonsadministrasjon → Medlemmer → Inviter via e-post → skriv inn e-postadressen → velg Guests (og ingenting annet) under Team.
2. Velg hvilke repositoryer teamet Guests kan lese: frem.sh/org/<org>/teams/guests → Repositoryer → legg til repositoryene du vil.
3. Send invitasjonen. Når personen godtar, kan den lese akkurat de repositoryene.

For å begrense en eksisterende gratis Reader til bestemte repositoryer åpner du Administrer-skuffen og flytter personen fra Viewers til Guests. Personen er gratis i begge tilfeller.

Guests og Collaborators styres av fremforge og kan ikke slettes. De avgjør hva du betaler: Guests holder lesere med tilgang til bestemte repositoryer gratis, og Collaborators er det som gjør en skribent med tilgang til bestemte repositoryer til en betalt bruker. Å fjerne et av dem ville i det stille endret prisen for organisasjonen, så begge er låst, som Members og Viewers. Du kan fritt endre hvilke repositoryer hvert av dem dekker, og hvem som er med.

Revisorer

En Auditor kan se alt i organisasjonen, men ikke endre noe. Bruk rollen for en samsvars- eller sikkerhetsrevisor, en intern kontrollfunksjon eller alle som må gjennomgå hvordan organisasjonen er konfigurert, og ikke bare lese koden.

Hver organisasjon har et fast team Auditors, som opprettes og styres av fremforge. Det har lesetilgang til alle repositoryer, og medlemmene kan også åpne organisasjonsadministrasjonen. Som de andre faste teamene er det låst: du kan ikke slette det, gi det nytt navn eller gi det mer enn lesetilgang. En eier bestemmer hvem som er med.

Hva en revisor kan se

• Hvert repository, med lesetilgang, som en Reader: klone, bla i koden, lese issues og pull requests.
• Organisasjonsadministrasjonen på /<org>/_admin/ og de tilsvarende lesingene i REST-API-et: policyer, sikkerhetsinnstillinger, SSO, medlemmer, fakturering og revisjonsloggen. Det omfatter det en Owner ser om personer: på siden Medlemmer medlemmenes e-postadresser, fulle navn, siste innlogging og MFA-status, og i faktureringsinnstillingene fakturakontakten og ID-ene til betalingsfullmaktene.
• Organisasjons- og repositoryinnstillinger i Forgejo (frem.sh/org/<org>/settings, Innstillinger for et repository), med lesetilgang.
• Samsvarsbevis og attesteringer. En revisor kan hente dem; hver henting registreres i revisjonsloggen.

Et banner på hver adminside sier at du ser siden som revisor med lesetilgang. Knapper og skjemaer som ville endret noe, er deaktivert.

Hva en revisor ikke kan gjøre

• Endre noe. Hver forespørsel som ikke er en lesing, avvises i adminsidene, i API-et og i Forgejo, før den når endepunktet. I fremforge-API-et er avvisningen en 403 med feilen auditor-read-only. En revisor kan ikke legge til eller fjerne medlemmer, heller ikke andre revisorer.
• Ta ut data i store mengder eller se legitimasjon. Dette avvises selv som lesing: dataeksporten, nedlasting av SBOM-er, fakturaeksporten og faktura-PDF-er, rå CI-logger, webhook-sidene og webhook-API-et, sidene for Forgejo Actions-runnere og API-et for registreringstokener for runnere, og siden for å slette organisasjonen.

Hvis en revisor trenger en av disse filene eller en endring, spør den en eier. Et API-token som en revisor bruker, har aldri annet enn lesetilgang.

Legge til en revisor

1. Ny person. Gå til Organisasjonsadministrasjon → Medlemmer (/<org>/_admin/members) → Inviter via e-post → skriv inn e-postadressen → velg Auditors under Team → Send invitasjon.
2. Eksisterende medlem. frem.sh/org/<org>/teams → Auditors → Legg til teammedlem.

For å fjerne en revisor fjerner du personen fra teamet Auditors. Tilgangen til organisasjonsadministrasjonen opphører innen 5 minutter.

En som er i både Auditors og Owners, er en Owner. En som er i Auditors og i et team som kan skrive (for eksempel Members), beholder skrivetilgangen til koden og er revisor med lesetilgang i innstillingene.

Brukere

• De første 5 revisorene i en organisasjon er gratis.
• Revisor nummer seks og utover er en betalt bruker og telles mot brukertaket som alle andre. Når alle brukerne er i bruk, gjelder de vanlige reglene for fullt brukertak.
• En revisor som også er i et team som kan skrive, er allerede en betalt bruker av den grunn, så personen koster ingenting ekstra og teller ikke blant de 5 gratis revisorene.
• De gratis revisorene er ikke bestemte personer: når en av de første fem går ut, blir neste revisor gratis i stedet.

Hver lesing en revisor gjør, logges

Eiernes lesinger av organisasjonsadministrasjonen logges ikke; revisorenes gjør det. Hver side eller hvert API-endepunkt en revisor leser, registreres i revisjonsloggen som en tenant.auditor.read-hendelse, høyst én gang per revisor og endepunkt hvert 10. minutt. Avviste forsøk logges hver gang.

Et team du allerede har kalt «Auditors»

Hvis organisasjonen allerede hadde et eget team med navnet Auditors før fremforge innførte rollen, lot fremforge det være. Det forblir et vanlig team: medlemmene får ikke tilgang til organisasjonsadministrasjonen, og det prises som alle andre team du har laget.

Når brukertaket er nådd

Hvis organisasjonen har nådd brukertaket, vises en side for «seats full» på /<org>/seats-full for et medlem som prøver å få tilgang til organisasjonen, i stedet for ressursen medlemmet ba om. Fra den siden kan medlemmet med ett klikk sende en forespørsel til organisasjonens eiere om å legge til en bruker.

Eierne får forespørselen (på e-post og i varselklokken i administrasjonen) og kan legge til en bruker under Organisasjonsadministrasjon → Fakturering, som opphever sperren for medlemmet som venter. Hev brukertaket før medlemmet kan gå videre; inntil da står tilgangen på pause på seats-full-siden.

Taket gjelder også for medlemmer som identitetsleverandøren din legger til gjennom SSO-gruppesynkronisering: ved innlogging setter gruppesynkroniseringen ingen inn i et team med skrivetilgang når organisasjonens betalte brukere er brukt opp (team med lesetilgang er gratis og alltid tillatt). En endring av taket eller av overforbruk av brukere på faktureringssiden gjelder for gruppesynkroniseringen så snart du lagrer den. Det samme gjør lagring av en SSO-kilde eller dens kobling fra gruppe til team, som sørger for at det gjeldende taket brukes allerede ved neste innlogging via den kilden.

Endre roller

Et medlems rolle (Owner, Member eller Reader) endres i produktet fra Administrer-skuffen på siden Members. Teknisk sett tilsvarer rollen medlemskap i Forgejo-team: Owners = full administrasjon av organisasjonen, Medlemmer = avgrenset lese- og skrivetilgang definert av teamets tilganger til repositoryer, Viewers = lesetilgang (og gratis). Å flytte et medlem til bare Viewers tar personen ut av antallet betalte brukere ved neste faktureringsperiode.

1. Gå til Organisasjonsadministrasjon → Medlemmer (/<org>/_admin/members).
2. Åpne Administrer-skuffen for medlemmet.
3. Velg den nye rollen og bekreft. Den tilsvarende endringen i Forgejo-teamet trer i kraft med en gang.

For mer finmasket teamsammensetning (egne team, tilganger avgrenset til repositoryer) bruker du Forgejos egen teamside på frem.sh/org/<org>/teams. Rolleendringer trer i kraft med en gang. Det finnes ingen frist, og det sendes ingen bekreftelse på e-post til medlemmet.

Fjerne et medlem

1. Gå til Organisasjonsadministrasjon → Medlemmer (/<org>/_admin/members).
2. Åpne Administrer-skuffen for medlemmet og velg Remove member.
3. Bekreft fjerningen.

Dette skjer med en gang:

• Tilgangen til alle repositoryer i organisasjonen tilbakekalles.
• Alle aktive sesjoner (nettleser eller API) for brukeren gjøres ugyldige.
• Medlemmet fjernes fra alle team i organisasjonen.

Dette endres ikke:

• Repositoryer slettes ikke. Repositoryer tilhører organisasjonen, ikke enkeltmedlemmer. Et medlem som eide repositoryer i organisasjonen, tar dem ikke med seg når det går.
• Issues, PR-er og commits forblir tilskrevet brukernavnet. Historiske bidrag bevares.
• Åpne PR-er og issues personen har skrevet, forblir åpne og uendret.

Det fjernede medlemmet tas ut av antallet betalte brukere ved neste faktureringsperiode. Det gis ingen kreditt for inneværende periode.

Sjekkliste for offboarding

Når et medlem forlater organisasjonen, går du gjennom denne sjekklisten før du fullfører fjerningen.

• Overfør eierskapet til repositoryer hvis medlemmet som går, eier repositoryer direkte (sjekk Organisasjonsadministrasjon → Repositoryer etter repositoryer med brukernavnet som eier). Overfør dem til organisasjonen eller til et annet medlem før du fjerner personen.
• Roter secrets personen kan ha kjent. Sjekk hvilke secrets som ble opprettet eller sist oppdatert mens personen hadde tilgang. Roter alle som nå er eksponert fordi personen har gått.
• Tilbakekall API-tokener personen har opprettet. Gå til Organisasjonsadministrasjon → API-tokener (/<org>/_admin/api-tokens) for å se alle API-tokener for organisasjonen. Tilbakekall alle tokener som medlemmet som går, har opprettet.
• Se etter personlige tilgangstokener (PAT-er). PAT-er er knyttet til brukerens konto, ikke til organisasjonen. Når personen er fjernet fra organisasjonen, kan PAT-ene ikke lenger nå organisasjonens ressurser. Men hvis medlemmet som går, var Owner, bør du forsikre deg om at ingen tokener med utvidede scopes er delt med eksterne systemer i personens navn.
• Gå gjennom aktive integrasjoner og webhooker. Hvis en webhook eller en ekstern integrasjon autentiserer seg som denne brukeren, oppdaterer du den til å bruke et API-token for organisasjonen eller en annen konto.

Deprovisjonering styrt av SCIM

Hvis SCIM-provisjonering er konfigurert for organisasjonen, styres brukernes livssyklus av den tilkoblede IdP-en (Okta, Entra ID osv.). Når du deaktiverer eller fjerner en bruker i IdP-en, deaktiveres brukeren automatisk i fremforge innen SCIM-synkroniseringsintervallet, som vanligvis er under fem minutter.

Når en bruker deaktiveres via SCIM:

• Sesjonen i fremforge gjøres ugyldig med en gang.
• Brukeren kan ikke logge inn via SSO eller lokalt passord.
• All fremforge-legitimasjon personen har, slutter å virke innen omtrent et minutt, og høyst 10 minutter: konsollsesjoner, innloggingen i CLI-et, API-tokenene personen har opprettet, og AI-tilkoblingene (MCP). Sesjoner og API-tokener avvises, men slettes ikke, og virker igjen hvis personen reaktiveres. Autorisasjonene for AI-tilkoblingene tilbakekalles. En utviklingsbench personen har kjørende, suspenderes. Sesjoner og API-tokener avvises på samme måte når en administrator blokkerer innloggingen til en person.
• Personen fjernes fra antallet betalte brukere ved neste faktureringsperiode.

Manuell fjerning via Organisasjonsadministrasjon → Medlemmer trengs ikke når SCIM er aktivt. IdP-en er fasiten for medlemskap. Hvis du fjerner en bruker i fremforge uten å deaktivere den i IdP-en, provisjonerer SCIM brukeren på nytt ved neste synkronisering.

Se SCIM-provisjonering for oppsett.

Medlemmer som bare bruker SSO

Et medlem som bare noen gang har logget inn via SSO, har ikke noe lokalt passord i fremforge. Identiteten styres helt av IdP-en.

Slik blokkerer du tilgangen for et medlem som bare bruker SSO:

1. Tilbakekall tilgangen i IdP-en (deaktiver kontoen, fjern personen fra apptildelingen eller slå av SSO for kontoen).
2. Fjern eventuelt personen fra organisasjonen i fremforge for å rydde i antallet brukere.

Det er nok å tilbakekalle tilgangen i IdP-en for å hindre innlogging. Sesjonen i fremforge feiler ved neste SSO-validering. Hvis SCIM er slått på, utløser deaktiveringen i IdP-en også automatisk deprovisjonering uten at du trenger å fjerne personen fra organisasjonen manuelt.

Invitere et tidligere medlem på nytt

For å invitere noen som tidligere er fjernet, sender du en ny invitasjon fra Organisasjonsadministrasjon → Medlemmer → Inviter via e-post som vanlig.

Når personen kommer tilbake:

• Tidligere commits, issues og PR-er forblir tilskrevet brukernavnet.
• Tilgangen til repositoryer bestemmes på nytt av rollen i organisasjonen og eventuelle collaborator-tildelinger på repositorynivå. Tidligere tilgangskonfigurasjon gjenopprettes ikke automatisk.

Hvis det tidligere medlemmet slettet fremforge-kontoen sin etter å ha gått, kan brukernavnet vises som en slettet konto på historiske bidrag. Hvis en annen person har tatt brukernavnet i mellomtiden, følger den historiske tilskrivingen den opprinnelige kontoen via den underliggende bruker-ID-en, ikke bare brukernavnet som tekst.

Tillatelser per repository

Rollene på organisasjonsnivå bestemmer grunntilgangen. For mer finmasket kontroll kan du legge til enkeltbrukere som collaborators på bestemte repositoryer.

Legg til en collaborator:

1. Gå til Repository → Innstillinger → Samarbeidspartnere.
2. Søk etter brukeren med brukernavn eller e-postadresse.
3. Velg et tillatelsesnivå:

Collaborator-tillatelser legges til brukerens rolle i organisasjonen og erstatter den ikke; den høyeste av de to gjelder. En Reader med Write som collaborator på et repository kan pushe til det repositoryet. En Owner som er collaborator, får ingenting utover det Owner-rollen allerede gir.

Collaborators må være medlemmer av organisasjonen din

En collaborator må være medlem av organisasjonen som eier repositoryet. Du kan ikke knytte til noen fra en annen organisasjon, og du kan ikke legge til en ekstern konto direkte på et repository. Inviter personen til organisasjonen først (som Guest hvis den bare trenger lesetilgang), og gi deretter tilgang til repositoryet.

Dette er en endring fra tidligere, da en administrator for et repository kunne knytte til en hvilken som helst eksisterende konto på instansen. Når medlemskap kreves, vises alle med tilgang til koden din under Organisasjonsadministrasjon → Medlemmer, og det er også det som gjør tilgangsgjennomganger og offboarding fullstendige.

Hva en collaborator koster

Bare skrivetilgang koster en betalt bruker:

Når du gir skrivetilgang til en som i dag er gratis (en Reader eller Guest), legges personen automatisk til i det faste teamet Collaborators, som er det som gjør den til en betalt bruker. Du trenger ikke flytte personen for hånd. En som allerede faktureres, et Member, en Owner eller en eksisterende Collaborator, belastes ikke to ganger.

Hvis den brukeren ville tatt deg over brukertaket:

• Med overforbruk av brukere slått på lykkes tildelingen, og den ekstra brukeren kommer på neste faktura.
• Med overforbruk av brukere slått av avvises tildelingen, og du henvises til Organisasjonsadministrasjon → Fakturering → Brukere. Å slå av overforbruk av brukere under Organisasjonsadministrasjon → Fakturering er måten du hindrer fremforge i å legge til betalte brukere automatisk på; det er den samme bryteren som styrer invitasjoner og medlemmer provisjonert via SSO.

Når noen ikke lenger teller som betalt bruker, mister personen ikke tilgangen helt. Skrivetilganger som ikke lenger dekkes av en betalt bruker, reduseres til lesetilgang etter en frist på 7 dager, så en Collaborator som ikke lenger er betalt bruker, blir det samme som en Guest i stedet for å bli stengt ute. Gjenopprett brukeren innen fristen, så endres ingenting.

Via REST-API

Den daglige flyten for medlemmenes livssyklus (invitere / liste / tilbakekalle / fjerne) er tilgjengelig i det offentlige API-et. Bruk det når du skripter onboarding fra et HR-system, automatiserer offboarding eller styrer driften fra en AI-agent.

• List invitasjoner GET /_app/api/v1/orgs/:slug/members/invitations?status=pending (scope seats:read)
• Inviter et medlem POST /_app/api/v1/orgs/:slug/members/invitations body: { "email": "...", "full_name": "...", "team_names": [...] } (scope seats:write)
• Tilbakekall en ventende invitasjon DELETE /_app/api/v1/orgs/:slug/members/invitations/:id (scope seats:write)
• Fjern et medlem DELETE /_app/api/v1/orgs/:slug/members/:login (scope seats:write)
• Innvilg / avvis en venteforespørsel om bruker POST /_app/api/v1/orgs/:slug/members/seat-holds/:id/grant eller .../dismiss (scope seats:write)

Krever et personlig tilgangstoken (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/invitations

Se referansen for det offentlige REST-API-et for hele OpenAPI-spesifikasjonen.

Se også

• SCIM-provisjonering: automatisert brukerlivssyklus via Okta, Entra ID eller en hvilken som helst IdP som følger SCIM 2.0
• OIDC SSO: konfigurer SSO slik at medlemmer logger inn med bedriftsidentiteten sin
• Fakturering: hvordan brukere telles, og når fjernede medlemmer går ut av antallet betalte brukere
• Organisasjonsadministrasjon: full referanse for organisasjonsadministrasjonen
• API: administrer medlemmer programmatisk via REST-API-et