Medlemmar och team

Roller

Varje medlem i organisationen har exakt en roll på organisationsnivå.

En organisation måste alltid ha minst en ägare. Du kan inte ta bort eller degradera den sista ägaren.

Hur det avgörs om någon är betalande användare

En enda regel gäller för alla roller ovan:

Du är betalande användare om du kan skriva någonstans. Om allt du har är läsbehörighet, eller om du inte har något alls, är du gratis. Det enda undantaget är teamet Auditors: dess 5 första medlemmar med läsbehörighet är gratis, och varje medlem därefter är en betalande användare.

Bortsett från Auditors avgörs det av den behörighet som dina team ger, inte av deras namn. Ett team med läsbehörighet som du skapar själv är alltså gratis oavsett avgränsning, och att byta namn på ett team ändrar aldrig vad du betalar. Ägare, medlemmar och medarbetare kan skriva och är därför betalande; läsare och gäster kan inte skriva och är det därför inte.

Bjuda in medlemmar

Hanteringen av medlemmar finns i fremforges administrationsgränssnitt på /<org>/_admin/members. Sidan Medlemmar listar varje nuvarande medlem med en panel Hantera per medlem och en inbjudningsdialog högst upp. Forgejos egen sida frem.sh/org/<org>/teams finns kvar som reserv när du behöver sätta ihop mer finkorniga teambehörigheter; sidan i produkten täcker det dagliga flödet för inbjudningar, roller och borttagning.

1. Gå till Organisationens administration → Medlemmar (/<org>/_admin/members).
2. Klicka på Bjud in via e-post.
3. Ange den inbjudnas användarnamn eller e-postadress och välj en roll.
4. Klicka på Skicka inbjudan.

Den inbjudna får ett mejl från noreply@frem.sh med en länk för att acceptera. Länken är giltig i 7 dagar. Om den går ut skickar du den igen från avsnittet Väntande inbjudningar på samma sida.

I avsnittet Väntande inbjudningar visas den inbjudna som Väntar tills inbjudan accepteras. Väntande medlemmar:

• Kan inte nå någon resurs i organisationen.
• Räknas inte som betalande användare förrän de accepterar inbjudan.
• Kan när som helst avbrytas genom att du tar bort dem från teamet medan de fortfarande väntar.

När den inbjudna accepterar ändras statusen till Aktiv och personen läggs till i antalet betalande användare vid nästa faktureringsperiod. Aktivitet krävs inte, det är accepterandet som räknas.

Gratis läsare (läsbehörighet, ingen betalande användare)

En läsare har läsbehörighet till de repon som läsaren har fått: klona, bläddra i kod, läsa issues och pull requests, men kan inte pusha, skapa repon eller nå organisationens administrationsinställningar. Läsare är gratis: de räknas inte mot ditt användartak och faktureras aldrig. Lägg till hur många du vill: intressenter, konsulter som bara behöver titta, dashboards med läsbehörighet och så vidare. Den som också behöver läsa organisationens inställningar, till exempel en revisor för regelefterlevnad, hör i stället hemma i Auditors.

Under huven är en läsare medlem i organisationens kanoniska team Viewers och i inget team som ger skrivbehörighet. Räkningen av användare följer den behörighet ett team ger, inte dess namn: har du bara team med läsbehörighet är du gratis; har du skrivbehörighet någonstans faktureras du. (Om du lägger till någon i både Viewers och Members faktureras personen: skrivbehörigheten vinner.)

Eftersom regeln bygger på behörighet och inte på namn är ett team med läsbehörighet som du skapar själv, Stakeholders, Reviewers eller vad du än kallar det, också gratis, och att avgränsa det till ett fåtal repon ändrar inte det. Använd Guests när du vill ha exakt det: gratis läsning i utvalda repon. Det kanoniska teamet Auditors är inte ett sådant team: fremforge skapar det, det når organisationens inställningar såväl som kod, och bara dess 5 första medlemmar är gratis (se Revisorer).

Lägg till en läsare

Alla de här vägarna fungerar; vägen i produkten är enklast:

1. Från sidan Medlemmar (rekommenderas). Gå till Organisationens administration → Medlemmar (/<org>/_admin/members) → Bjud in via e-post → ange e-postadressen → under Team väljer du Viewers (och inget annat) → Skicka inbjudan. När personen accepterar ansluter den som gratis läsare.
2. Konvertera en befintlig medlem. Öppna medlemmens panel Hantera och flytta personen till Viewers (ta bort den från Members/Owners). Personen försvinner ur antalet betalande användare vid nästa faktureringsperiod.
3. Automatiskt via SSO. Mappa en grupp i identitetsleverantören till teamet Viewers (se SSO och SCIM). Alla i den gruppen provisioneras som gratis läsare, utan någon inbjudan per person.
4. Reserv i Forgejo. frem.sh/org/<org>/teams → Viewers → Lägg till teammedlem. Använd det bara när du behöver en mer finkornig teamsammansättning; sidan Medlemmar täcker det vanliga fallet.

Gratis läsare räknas separat från betalande användare i din faktureringsöversikt (Organisationens administration → Fakturering) och i API:t för användare, så att du alltid ser hur många gratis läsare du har jämfört med hur många betalande användare du använder.

Inte samma sak som en läsare av enbart dokumentation. Om du vill ha någon som kan läsa din publicerade dokumentation men inte har åtkomst till något repo och inget Forgejo-konto alls, lägg inte till personen i Viewers. Ge i stället personens SSO-grupp en tom mappning från grupp till team. Se Wiki och publik dokumentation. En läsare (teamet Viewers) får ett Forgejo-konto och läsbehörighet till de repon som tilldelats; en läsare av enbart dokumentation får inte det.

Gäster (gratis läsning, specifika repon)

En läsare kan läsa varje repo i organisationen. En gäst läser bara de repon som du väljer. Båda är gratis: att läsa kod gör dig aldrig till betalande användare, oavsett avgränsning.

Använd gäster för en konsult som granskar en enda tjänst, en revisor som behöver två repon snarare än fyrtio, eller ett partnerteam som du vill hålla borta från allt annat. Det är den minst privilegierade varianten av en läsare, och den kostar lika mycket: ingenting.

Gäster är det kanoniska teamet Guests, som skapas i varje organisation och är avgränsat till specifika repon i stället för alla.

Lägg till en gäst

1. Gå till Organisationens administration → Medlemmar → Bjud in via e-post → ange e-postadressen → under Team väljer du Guests (och inget annat).
2. Välj vilka repon teamet Guests kan läsa: frem.sh/org/<org>/teams/guests → Repositories → lägg till de repon du vill.
3. Skicka inbjudan. När personen accepterar kan den läsa exakt de repona.

För att begränsa en befintlig gratis läsare till specifika repon öppnar du personens panel Hantera och flyttar den från Viewers till Guests. Personen förblir gratis i båda fallen.

Guests och Collaborators hanteras av fremforge och kan inte tas bort. De styr vad du betalar: Guests håller läsare som är avgränsade till repon gratis, och Collaborators är det som gör en skribent avgränsad till repon till en betalande användare. Att ta bort något av dem skulle i tysthet ändra priset för din organisation, så båda är låsta, precis som Members och Viewers. Du kan fritt ändra vilka repon vart och ett av dem omfattar, och vem som är med i dem.

Revisorer

En revisor kan titta på allt i din organisation och ändra ingenting. Använd rollen för en revisor inom regelefterlevnad eller säkerhet, en intern kontrollfunktion eller vem som helst som behöver granska hur organisationen är konfigurerad snarare än bara läsa dess kod.

Varje organisation har ett kanoniskt team Auditors, som skapas och hanteras av fremforge. Det har läsbehörighet till alla repositoryn, och dess medlemmar kan också öppna organisationens administrationsinställningar. Precis som de andra kanoniska teamen är det låst: du kan inte ta bort det, byta namn på det eller ge det mer än läsbehörighet. En ägare bestämmer vem som är med i det.

Vad en revisor kan se

• Varje repository, med läsbehörighet, precis som en läsare: klona, bläddra i kod, läsa issues och pull requests.
• Organisationens administrationsinställningar på /<org>/_admin/ och motsvarande läsningar i REST-API:t: policyer, säkerhetsinställningar, SSO, medlemmar, fakturering och granskningsloggen. Det inkluderar det som en ägare ser om personer: på sidan Medlemmar medlemmarnas e-postadresser, fullständiga namn, senaste inloggning och MFA-status, och i faktureringsinställningarna faktureringskontakten och id:n för betalningsmandat.
• Inställningar för organisationen och repon i Forgejo (frem.sh/org/<org>/settings, ett repos Settings), med läsbehörighet.
• Bevis för regelefterlevnad och attesteringar. En revisor kan hämta dem; varje hämtning registreras i granskningsloggen.

En banner på varje administrationssida anger att du tittar som revisor med läsbehörighet. Knappar och formulär som skulle ändra något är inaktiverade.

Vad en revisor inte kan göra

• Ändra något. Varje begäran som inte är en läsning avvisas, på administrationssidorna, i API:t och i Forgejo, innan den når endpointen. I fremforges API är avvisningen en 403 med felet auditor-read-only. En revisor kan inte lägga till eller ta bort medlemmar, inte heller andra revisorer.
• Ta ut data i bulk eller se inloggningsuppgifter. Följande avvisas även som läsning: dataexporten, nedladdning av SBOM:er, faktureringsexporten och PDF:er för fakturor, råa CI-loggar, webhook-sidorna och webhook-API:t, sidorna för runners i Forgejo Actions och API:t för registreringstoken för runners, samt sidan för att ta bort organisationen.

Om en revisor behöver någon av de filerna eller en ändring ber revisorn en ägare. En API-token som en revisor använder har alltid bara läsbehörighet.

Lägg till en revisor

1. Ny person. Gå till Organisationens administration → Medlemmar (/<org>/_admin/members) → Bjud in via e-post → ange e-postadressen → under Team väljer du Auditors → Skicka inbjudan.
2. Befintlig medlem. frem.sh/org/<org>/teams → Auditors → Lägg till teammedlem.

För att ta bort en revisor tar du bort personen från teamet Auditors. Åtkomsten till administrationsinställningarna upphör inom 5 minuter.

Den som är med i både Auditors och Owners är ägare. Den som är med i Auditors och i ett team som kan skriva (till exempel Members) behåller sin skrivbehörighet till koden och är revisor med läsbehörighet för inställningarna.

Användare

• De första 5 revisorerna i en organisation är gratis.
• En sjätte eller senare revisor är en betalande användare och räknas mot ditt användartak som alla andra. När taket är nått gäller de vanliga reglerna för fullt användartak.
• En revisor som också är med i ett team som kan skriva är redan betalande användare för det, så personen kostar inget extra och tar inte upp någon av de 5 gratis revisorerna.
• De gratis revisorerna är inte reserverade för vissa personer: när någon av de första fem slutar blir nästa revisor gratis i stället.

Varje läsning av en revisor loggas

Ägares läsningar av administrationsinställningarna loggas inte; revisorers gör det. Varje sida eller API-endpoint som en revisor läser registreras i granskningsloggen som en händelse tenant.auditor.read, högst en gång per revisor och endpoint var 10:e minut. Avvisade försök loggas varje gång.

Ett team som du redan hade kallat “Auditors”

Om din organisation redan hade ett eget team med namnet Auditors innan fremforge införde rollen lät fremforge det vara. Det förblir ett vanligt team: dess medlemmar får ingen åtkomst till administrationsinställningarna, och det prissätts som alla andra team som du har skapat.

När användartaket är nått

Om din organisation har nått sitt användartak visas en sida om fullt användartak på /<org>/seats-full för en medlem som försöker nå organisationen, i stället för den resurs som medlemmen begärde. Från den sidan kan medlemmen med ett klick skicka en begäran till organisationens ägare om att lägga till en användare.

Ägarna får begäran (via e-post och i administrationens notisklocka) och kan lägga till en användare under Organisationens administration → Fakturering, vilket häver spärren för den väntande medlemmen. Höj användartaket innan medlemmen kan fortsätta; fram till dess är åtkomsten pausad på sidan om fullt användartak.

Taket gäller också medlemmar som din identitetsleverantör lägger till via synkronisering av SSO-grupper: vid inloggning placerar gruppsynkroniseringen ingen i ett team med skrivbehörighet när organisationens betalda användare är förbrukade (team med läsbehörighet är gratis och alltid tillåtna). En ändring av taket eller av överskridande av användartaket på sidan Fakturering gäller för gruppsynkroniseringen så snart du sparar den. Detsamma gäller när du sparar en SSO-källa eller dess mappning från grupp till team, vilket säkerställer att det aktuella taket gäller innan källans nästa inloggning.

Ändra roller

En medlems roll (ägare, medlem eller läsare) ändras i produkten från panelen Hantera på sidan Medlemmar. Under huven motsvarar rollen medlemskap i Forgejo-team: Owners = full organisationsadministration, Members = avgränsad läs- och skrivbehörighet enligt teamets tilldelningar av repon, Viewers = läsbehörighet (och gratis). Att flytta en medlem till enbart Viewers tar bort personen ur antalet betalande användare vid nästa faktureringsperiod.

1. Gå till Organisationens administration → Medlemmar (/<org>/_admin/members).
2. Öppna panelen Hantera för medlemmen.
3. Välj den nya rollen och bekräfta. Motsvarande ändring av Forgejo-teamet tillämpas direkt.

För mer finkornig teamsammansättning (egna team, tilldelningar avgränsade till repon) använder du Forgejos egen teamsida på frem.sh/org/<org>/teams. Rolländringar gäller direkt. Det finns ingen respitperiod och inget bekräftelsemejl skickas till medlemmen.

Ta bort en medlem

1. Gå till Organisationens administration → Medlemmar (/<org>/_admin/members).
2. Öppna panelen Hantera för medlemmen och välj Remove member.
3. Bekräfta borttagningen.

Det här händer direkt:

• Åtkomsten till alla organisationens repon återkallas.
• Alla aktiva sessioner (webbläsare eller API) för användaren ogiltigförklaras.
• Medlemmen tas bort från alla teamtilldelningar i organisationen.

Det här ändras inte:

• Repon tas inte bort. Repon tillhör organisationen, inte enskilda medlemmar. En medlem som ägde repon i organisationen tar inte med sig dem när den slutar.
• Issues, PR:er och commits förblir knutna till användarnamnet. Historiska bidrag bevaras.
• Öppna PR:er och issues som medlemmen skapade förblir öppna och oförändrade.

Den borttagna medlemmen tas bort ur antalet betalande användare vid nästa faktureringsperiod. Ingen kreditering ges för den aktuella perioden.

Checklista för avveckling

När en medlem lämnar organisationen går du igenom den här checklistan innan du slutför borttagningen.

• Överför ägarskapet för repon om den som slutar äger några repon direkt (kontrollera Organisationens administration → Repon efter repon med personens användarnamn som ägare). Överför till organisationen eller till en annan medlem innan du tar bort personen.
• Rotera secrets som personen kan ha känt till. Kontrollera vilka secrets som skapades eller senast uppdaterades medan personen hade åtkomst. Rotera alla som nu är exponerade genom att personen slutar.
• Återkalla API-token som personen skapat. Gå till Organisationens administration → API-token (/<org>/_admin/api-tokens) för att se alla organisationens API-token. Återkalla alla token som den som slutar har skapat.
• Kontrollera personliga åtkomsttoken (PAT). PAT är knutna till användarens konto, inte till organisationen. När personen har tagits bort från organisationen kan dess PAT inte längre nå organisationens resurser. Men om den som slutar var ägare, kontrollera att inga token med utökade behörigheter har delats med externa system i personens namn.
• Granska aktiva integrationer och webhooks. Om någon webhook eller extern integration autentiserar som den här användaren, uppdatera den så att den använder en API-token för organisationen eller ett annat konto.

Avprovisionering som hanteras av SCIM

Om SCIM-provisionering är konfigurerad för organisationen hanteras användarnas livscykel av den anslutna identitetsleverantören (Okta, Entra ID osv.). När du inaktiverar eller tar bort en användare i identitetsleverantören inaktiveras den automatiskt i fremforge inom SCIM-synkroniseringens intervall, som oftast är under fem minuter.

När en användare inaktiveras via SCIM:

• Användarens session i fremforge ogiltigförklaras direkt.
• Användaren kan inte logga in via SSO eller med lokalt lösenord.
• Alla fremforge-inloggningsuppgifter som användaren har slutar fungera inom ungefär en minut, och högst 10 minuter: konsolsessioner, inloggningen i CLI:t, de API-token som användaren skapat och användarens AI-anslutningar (MCP). Sessioner och API-token avvisas, de tas inte bort, och fungerar igen om personen återaktiveras. Användarens auktoriseringar för AI-anslutningar återkallas. En dev bench som användaren har igång pausas. Sessioner och API-token avvisas på samma sätt när en administratör spärrar en persons inloggning.
• Användaren tas bort ur antalet betalande användare vid nästa faktureringsperiod.

Manuell borttagning via Organisationens administration → Medlemmar behövs inte när SCIM är aktivt. Identitetsleverantören är sanningskällan för medlemskap. Om du tar bort en användare i fremforge utan att inaktivera den i identitetsleverantören provisionerar SCIM den igen vid nästa synkronisering.

Se SCIM-provisionering för instruktioner om konfiguration.

Medlemmar som bara använder SSO

En medlem som bara någonsin har loggat in via SSO har inget lokalt fremforge-lösenord. Identiteten styrs helt av identitetsleverantören.

Så spärrar du åtkomsten för en medlem som bara använder SSO:

1. Återkalla åtkomsten i identitetsleverantören (inaktivera kontot, ta bort tilldelningen till appen eller stäng av SSO för kontot).
2. Ta eventuellt bort personen från organisationen i fremforge för att städa upp antalet användare.

Det räcker att återkalla åtkomsten i identitetsleverantören för att förhindra inloggning. Sessionen i fremforge misslyckas vid nästa SSO-validering. Om SCIM är aktiverat utlöser inaktiveringen i identitetsleverantören också automatisk avprovisionering, utan det manuella steget att ta bort personen från organisationen.

Bjuda in en tidigare medlem igen

För att bjuda in någon som tidigare har tagits bort skickar du som vanligt en ny inbjudan från Organisationens administration → Medlemmar → Bjud in via e-post.

När personen ansluter igen:

• Tidigare commits, issues och PR:er förblir knutna till användarnamnet.
• Åtkomsten till repon bestäms på nytt av rollen i organisationen och eventuella tilldelningar som medarbetare på repo-nivå. Ingen tidigare åtkomstkonfiguration återställs automatiskt.

Om den tidigare medlemmen tog bort sitt fremforge-konto efter att ha slutat kan användarnamnet visas med en markering för borttaget konto på historiska bidrag. Om en annan person har tagit det användarnamnet under tiden speglar den historiska tillskrivningen det ursprungliga kontot via det underliggande användar-id:t, inte bara användarnamnets textsträng.

Behörigheter per repo

Rollerna på organisationsnivå bestämmer grundåtkomsten. För mer finkornig kontroll kan du lägga till enskilda användare som medarbetare i specifika repon.

Lägg till en medarbetare:

1. Gå till Repot → Inställningar → Medarbetare.
2. Sök efter användaren via användarnamn eller e-postadress.
3. Välj en behörighetsnivå:

Behörigheter som medarbetare läggs till ovanpå användarens roll i organisationen, de ersätter den inte: den högre av de två gäller. En läsare med behörigheten Write som medarbetare i ett repo kan pusha till det repot. En ägare som är medarbetare får inget utöver det som ägarrollen redan ger.

Medarbetare måste vara medlemmar i din organisation

En medarbetare måste vara medlem i den organisation som äger repot. Du kan inte koppla någon från en annan organisation, och du kan inte lägga till ett utomstående konto direkt i ett repo. Bjud först in personen till organisationen (som gäst om den bara behöver läsa) och ge sedan åtkomst till repot.

Det här är en ändring från tidigare beteende, då en repo-administratör kunde koppla vilket befintligt konto som helst på instansen. Kravet på medlemskap gör att alla med åtkomst till din kod visas under Organisationens administration → Medlemmar, vilket också är det som gör åtkomstgranskningar och avveckling fullständiga.

Vad en medarbetare kostar

Bara skrivbehörighet kostar en användare:

När du ger skrivbehörighet till någon som i dag är gratis (en läsare eller gäst) läggs personen automatiskt till i det kanoniska teamet Collaborators, vilket är det som gör den till betalande användare. Du behöver inte flytta personen för hand. Den som redan är betalande, en medlem, en ägare eller en befintlig medarbetare, debiteras inte två gånger.

Om den användaren skulle ta dig över ditt användartak:

• Med överskridande av användartaket aktiverat lyckas tilldelningen och den extra användaren syns på din nästa faktura.
• Med överskridande av användartaket inaktiverat avvisas tilldelningen och du hänvisas till Organisationens administration → Fakturering → Användare. Att stänga av överskridande av användartaket under Organisationens administration → Fakturering är hur du hindrar fremforge från att automatiskt lägga till betalda användare; det är samma reglage som styr inbjudningar och medlemmar som provisioneras via SSO.

Att ta bort någon som betalande användare tar inte bort personens åtkomst helt. Skrivbehörigheter som inte längre täcks av en betald användare sänks till läsbehörighet efter en respitperiod på 7 dagar, så en medarbetare som inte längre är betalande användare blir motsvarigheten till en gäst i stället för att låsas ute. Återställ användaren inom den perioden så ändras ingenting.

Via REST-API

Det dagliga flödet för medlemmarnas livscykel (bjuda in / lista / återkalla / ta bort) finns i det publika API:t. Använd det när du skriptar introduktion av nyanställda från ett HR-system, automatiserar avveckling eller styr arbetet från en AI-agent.

• Lista inbjudningar GET /_app/api/v1/orgs/:slug/members/invitations?status=pending (scope seats:read)
• Bjud in en medlem POST /_app/api/v1/orgs/:slug/members/invitations body: { "email": "...", "full_name": "...", "team_names": [...] } (scope seats:write)
• Återkalla en väntande inbjudan DELETE /_app/api/v1/orgs/:slug/members/invitations/:id (scope seats:write)
• Ta bort en medlem DELETE /_app/api/v1/orgs/:slug/members/:login (scope seats:write)
• Bevilja / avfärda en användare som väntar på att bli betalande användare POST /_app/api/v1/orgs/:slug/members/seat-holds/:id/grant eller .../dismiss (scope seats:write)

Kräver en personlig åtkomsttoken (PAT) med scope 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 referensen för det publika REST-API:t för den fullständiga OpenAPI-specifikationen.

Korsreferenser

• SCIM-provisionering: automatiserad livscykel för användare via Okta, Entra ID eller vilken SCIM 2.0-kompatibel identitetsleverantör som helst
• OIDC SSO: konfigurera SSO så att medlemmar loggar in med sin företagsidentitet
• Fakturering: hur användare räknas och när borttagna medlemmar lämnar antalet betalande användare
• Organisationens administration: fullständig referens för organisationens administrationsyta
• API: hantera medlemmar programmatiskt via REST-API:t