From 7f5ee6bd4f28a1886f9ea8792b2212c990c592af Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kjetil=20R=C3=B8se=20H=C3=B8ybr=C3=A5ten?= Date: Fri, 21 Aug 2026 14:49:05 +0200 Subject: [PATCH] Krav for tildeling av tilgang mot organisasjonssamling (BRU-TIL-SAM-002) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Tildeling av en tilgang til en applikasjon mot en organisasjonssamling er besluttet og under bygging, i motsetning til forvaltningen av samlingene selv (BRU-TIL-SAM-001), som fortsatt er en designdiskusjon. Kravet skilles derfor ut som en egen, vedtatt egenskap med @must @planned. Kjernen er anti-eskaleringsregelen: rettigheten til å tildele kreves i miljøet for hver organisasjon som er aktivt medlem av samlingen, ikke bare for én. Én tildeling mot en samling gir tilgangen i alle medlemmene, så delvis dekning ville vært en vei til å tildele i organisasjoner man ikke har rett i. Featuren dekker også temporalitet og sporbarhet, idempotens i begge retninger, at tilbaketrekking ikke berører tilgang som består på annen vei, at virkningen følger medlemslisten videre, og at tildelingene er skjermet mens katalogen og medlemslisten er åpen lesning. Designnotatet begrunner gatingen og hvorfor kravet står uavhengig av hvordan samlingene selv forvaltes. --- ...tilgang_mot_organisasjonssamling.design.md | 149 ++++++++++++ ...e_tilgang_mot_organisasjonssamling.feature | 228 ++++++++++++++++++ 2 files changed, 377 insertions(+) create mode 100644 krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/02 Organisasjonssamlinger/tildele_tilgang_mot_organisasjonssamling.design.md create mode 100644 krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/02 Organisasjonssamlinger/tildele_tilgang_mot_organisasjonssamling.feature diff --git a/krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/02 Organisasjonssamlinger/tildele_tilgang_mot_organisasjonssamling.design.md b/krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/02 Organisasjonssamlinger/tildele_tilgang_mot_organisasjonssamling.design.md new file mode 100644 index 0000000..0128ba2 --- /dev/null +++ b/krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/02 Organisasjonssamlinger/tildele_tilgang_mot_organisasjonssamling.design.md @@ -0,0 +1,149 @@ +# Designnotat: Tildele tilgang mot en organisasjonssamling + +**Relatert feature:** +[`tildele_tilgang_mot_organisasjonssamling.feature`](./tildele_tilgang_mot_organisasjonssamling.feature) +(BRU-TIL-SAM-002). + +Til forskjell fra forvaltningen av samlingene selv (BRU-TIL-SAM-001, som fortsatt er en +designdiskusjon) er denne delen besluttet og under bygging. Notatet forklarer de to valgene som +bærer kravet: hvordan tildelingen er gatet, og hvorfor kravet står uavhengig av hvordan +samlingene forvaltes. + +## Utgangspunktet: mengden finnes, skriveflaten er den nye delen + +Datamodellen for organisasjonssamlinger er i produksjonsløypa (migrering 0029): katalogen over +samlinger, temporale medlemskap per miljø, og temporale tildelinger mot en samling. +Autorisasjonen utvider allerede en aktiv tildeling mot en samling til de organisasjonene som er +aktive medlemmer **i det samme miljøet**, side om side med de direkte tildelingene, og resultatet +rolleekspanderes og dedupliseres. Utvidelsen krysser aldri miljø. + +Det som manglet var skriveflaten: tildelingstabellen var lukket for alt annet enn +databaseforvaltningen. Migrering 0045 åpner **én** av de tre flatene — å gi og trekke tilbake en +tilgang mot en samling som alt finnes. Katalogen og medlemskapene er like lukkede som før, og +hvem som skal få forvalte dem er fortsatt BRU-TIL-SAM-001s spørsmål. + +Mottakeren er en **applikasjon**. Det er applikasjonsadministratorens flyt, den samme som +BRU-APP-API-007 og BRU-APP-API-008 beskriver for én organisasjon, bare rettet mot en mengde. +Brukere som mottaker er ikke tatt med: modellen skiller ikke, men behovet er bare kjent for +applikasjoner, og en flate vi ikke vet formen på er lettere å legge til enn å ta bort. + +## Gatingen: full dekning, ikke delvis + +Rettigheten er **den samme som for å tildele mot én organisasjon** — tildelingsretten per +(organisasjon, miljø), `BRUKERADMIN_TILDELING_SKRIV`. Ingen ny rollekode, ingen egen +samlingsrolle. Å tildele mot en mengde er ikke en annen handling enn å tildele mot et medlem av +den. + +Kravet er at rettigheten må finnes i miljøet for **hver** organisasjon som er aktivt medlem av +samlingen der. Begrunnelsen er anti-eskalering: + +- Én tildeling mot samlingen gir tilgangen i hver aktive medlemsorganisasjon. Holdt det å ha + rettigheten i **én** av dem, kunne en administrator ved ett lærested gitt en applikasjon + tilgang ved alle de andre ved å gå gjennom en samling lærestedet er medlem av. Rekkevidden av + det man skriver må ligge innenfor rekkevidden av det man har rett til. +- Formen gir en administrator myndighet over nøyaktig de samlingene hen alt har myndighet over + hver enkelt medlemsorganisasjon i — ikke mer, ikke mindre. + +**Den tomme mengden er et eget ledd.** «Ingen medlemsorganisasjon utenfor rettigheten min» er +trivielt sant for en samling uten aktive medlemmer i miljøet, og uten et tillegg ville enhver +innlogget kunne skrevet en tildeling mot en slik samling. Regelen krever derfor også at kalleren +har tildelingsrett et sted i miljøet, altså er en administrator med tildelingsmyndighet i det +hele tatt. En tildeling mot en tom samling har ingen virkning før organisasjoner meldes inn. + +**Alternativet er avvist.** Å gate tildeling mot samling på et globalt, Sikt-nivå privilegium — +slik forvaltningen av samlinger må gates, siden en samling ikke har noen eierorganisasjon å skope +til — ville gjort tildeling mot samling til et Sikt-anliggende. Bestillingen er at +applikasjonsadministratorer skal kunne bruke samlinger, og dekningskravet er det som gjør det +forsvarlig uten å flytte handlingen til Sikt. + +## Dekningen vurderes ved tildelingstidspunktet + +Sjekken skjer når tildelingen gis. Meldes en organisasjon inn i en samling som alt har +tildelinger, utvides de tildelingene til den nye organisasjonen — uten at dekningskravet ser det. +Ingen sjekk på tildelingssiden kan forhindre det, heller ikke en strengere enn denne. + +Det er ikke et hull i regelen, men en presisering av hvor den hører: det som kan fange dette er +en revalidering **på medlemskapssiden** (avvis en innmelding som ville utvidet en eksisterende +tildeling utover innmelderens egen rett), eller en varsling. Begge hører i forvaltningsflaten for +medlemskap, som ikke er åpnet, og de er en del av grunnen til at medlemskapsforvaltningen er +strengere gatet enn tildelingen. Notert som oppfølger til BRU-TIL-SAM-001. + +## Uavhengig av forvaltningsmodellen + +Kravet gjelder likt enten samlinger og medlemslister forvaltes gjennom en flate i løsningen, via +API, eller kun av databaseforvaltningen gjennom migreringer: + +- Alle reglene i featuren er formulert mot en samling som **finnes** og en medlemsliste som + **gjelder**. Ingen av dem forutsetter hvem som skrev dem, eller hvordan. +- Dekningskravet leser medlemslisten slik den er, uansett hvem som vedlikeholder den. +- Dynamikken — at virkningen følger medlemslisten — er en egenskap ved utvidelsen i + autorisasjonen, ikke ved forvaltningsflaten. + +Konsekvensen er at tildeling mot samling kan tas i bruk før forvaltningsspørsmålet er avgjort. +I dag finnes én samling, opprettet av databaseforvaltningen; den er nok til at kravet har mening. +Blir forvaltningen senere en flate i løsningen, endrer ikke det en enkelt regel her. + +## Temporalitet, idempotens og «fortsatt effektiv» + +Tildelingen er temporalt modellert, som de direkte tildelingene: å trekke tilbake er å **lukke +gyldigheten**, ikke å slette innslaget. Historikken svarer derfor på hva som har vært gitt, når, +av hvem, og når det ble trukket tilbake. Begge operasjonene er idempotente — å gi en tilgang som +alt gjelder, og å trekke tilbake en som ikke gjelder, er suksess uten at historikken endres. +Idempotensen er ikke en bakvei rundt gatingen: rettigheten sjekkes også i de tilfellene der ingen +rad skrives, så «du mangler rettighet» og «det var alt gjort» er ulike svar. + +**Det finnes ikke ett «fortsatt effektiv»-svar for en tilbaketrekking mot en samling**, og +featuren lover ikke ett. En applikasjon kan beholde tilgangen i noen medlemsorganisasjoner — +gjennom en direkte tildeling, gjennom en annen samling, eller fordi en sterkere tilgang omfatter +den — og miste den i resten. Svaret er altså ett per organisasjon. Det ærlige stedet å lese det er +applikasjonens egen tilgangsliste for organisasjonen; en enkeltverdi på tilbaketrekkingen måtte +enten forenkle eller være en liste vi ikke kan fylle ærlig, siden innsyn i de direkte tildelingene +er en annen rettighet enn den som kreves her. + +Det som **er** synlig, og som featuren lover, er at en direkte tildeling står uendret etter at +tildelingen mot samlingen er trukket tilbake — og motsatt: fjernes den direkte tildelingen, består +tilgangen gjennom samlingen. De to veiene er uavhengige. + +## Skjermet lesning: du ser det du kunne skrevet + +Katalogen og medlemslistene er åpen lesning — hvilke samlinger som finnes og hvilke organisasjoner +de består av trenger ingen skjerming. **Tildelingene mot en samling er skjermet**, og +lesesemantikken er den samme mengden som skrivesemantikken: du ser de tildelingene du selv kunne +skrevet, altså de mot samlinger der rettigheten din dekker hver aktive medlemsorganisasjon i +miljøet. For alle andre er listen tom. + +Det gir en felle flaten må håndtere: **en tom liste betyr ikke at samlingen er uten tildelinger.** +Featuren har et eget scenario for det, og UI-et bør si det, ikke vise «ingen tilganger». + +Medlemslisten er samtidig forklaringen på et avslag: den sier hvilke organisasjoner rettigheten +kreves for. Å hente den sammen med et avslag er derfor det som gjør feilmeldingen brukbar. + +## Ikke-funksjonelt + +Dekningskravet koster i takt med antall aktive medlemmer i miljøet, per tildeling som vurderes. +Ved dagens volum (den eneste samlingen som finnes har 37 medlemmer i produksjon) er det uten +betydning. Forvaltningsregelen om at samlinger over 500 medlemmer skal ytelsesmåles før de tas i +bruk — se BRU-TIL-SAM-001 — er også taket for dette predikatet. Grensen håndheves ikke her; den er +en prosessregel. + +## Avklarte valg + +- Mottaker er en applikasjon; tildelingen er applikasjonsadministratorens handling. +- Rettigheten er tildelingsretten, ikke et eget samlingsprivilegium — men den kreves for **hver** + aktive medlemsorganisasjon i miljøet (full dekning), og for minst én organisasjon i miljøet. +- Tildeling og tilbaketrekking er temporale og idempotente; historikken består. +- Tildelingene mot en samling er skjermet med samme mengde som skrivingen; katalog og medlemsliste + er åpen lesning. +- Kravet står uavhengig av forvaltningsmodellen for samlinger og medlemskap. + +## Åpne spørsmål + +- [ ] Skal en tilgang som følger av en samling vises i applikasjonens egen tilgangsliste, og + hvordan skal det fremgå at den ikke kan fjernes der? Provenienssporet henger sammen med + visningen av mine tilganger, jf. BRU-TIL-SAM-001. +- [ ] Skal brukere kunne være mottaker av en tildeling mot en samling, eller bare applikasjoner? +- [ ] Skal en innmelding i en samling revalideres mot innmelderens egen tildelingsrett, eller + varsles? Hører i medlemskapsflaten. +- [ ] Skal delegering til en applikasjon senere kunne uttrykkes mot en samling? I dag må + delegering gjøres per organisasjon, og samlingsformen gjelder bare applikasjonens egne + tilganger. diff --git a/krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/02 Organisasjonssamlinger/tildele_tilgang_mot_organisasjonssamling.feature b/krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/02 Organisasjonssamlinger/tildele_tilgang_mot_organisasjonssamling.feature new file mode 100644 index 0000000..adad032 --- /dev/null +++ b/krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/02 Organisasjonssamlinger/tildele_tilgang_mot_organisasjonssamling.feature @@ -0,0 +1,228 @@ +# language: no +@BRU-TIL-SAM-002 @must @planned +Egenskap: Tildele tilgang til en applikasjon mot en organisasjonssamling + Som bruker med applikasjonsadministrator-rollen + ønsker jeg å tildele en tilgang til en applikasjon mot en organisasjonssamling i et gitt miljø + slik at applikasjonen får tilgangen i alle organisasjonene i samlingen uten at den må tildeles + én gang per organisasjon. + + En organisasjonssamling er en navngitt mengde organisasjoner. Å tildele mot samlingen er den + samme handlingen som å tildele mot én organisasjon — bare uttrykt mot en mengde: tilgangen får + virkning i hver organisasjon som er aktivt medlem av samlingen i det samme miljøet. Det er + tildelingens form, ikke tilgangens navn, som gjør virkningen bred. + + Tildelingen gjelder ett miljø, og virkningen krysser aldri miljø: både tildelingen og + medlemskapet må gjelde i miljøet det slås opp i. En samling kan derfor ha ulike medlemmer i + test og i produksjon uten at et testmedlemskap noensinne gir tilgang i produksjon. + + Egenskapen speiler tildel- og fjern-flyten for enkeltorganisasjoner, BRU-APP-API-007 og + BRU-APP-API-008, og den er uavhengig av hvordan samlingene selv forvaltes: reglene under + gjelder enten medlemslistene vedlikeholdes gjennom løsningen eller av databaseforvaltningen. + Forvaltningen av samlinger og medlemskap er en egen kravdiskusjon, jf. BRU-TIL-SAM-001. + + # ÅPNE SPØRSMÅL: + # - Skal en tilgang som følger av en samling vises i applikasjonens egen tilgangsliste, og + # hvordan skal det i så fall fremgå at den ikke kan fjernes der? I dag leses den på + # samlingen, ikke på applikasjonen. + # - Skal brukere, og ikke bare applikasjoner, kunne være mottaker av en tildeling mot en + # samling? Modellen skiller ikke, men behovet er bare kjent for applikasjoner. + + Bakgrunn: + Gitt jeg er innlogget i løsningen + Og det finnes en organisasjonssamling med medlemsorganisasjoner i et miljø + + Regel: En tildeling gjelder én tilgang, én applikasjon, én samling og ett miljø + + Scenario: Tildele en tilgang mot en samling + Gitt jeg har rettighet til å tildele tilgangen i hver av samlingens medlemsorganisasjoner i miljøet + Når jeg tildeler tilgangen til en applikasjon mot samlingen i det miljøet + Så er tilgangen gitt mot samlingen for det miljøet + Og det fremgår hvilken samling og hvilket miljø tildelingen gjelder + + Scenario: Tilgangen får virkning i hver medlemsorganisasjon i miljøet + Gitt jeg har rettighet til å tildele tilgangen i hver av samlingens medlemsorganisasjoner i miljøet + Når jeg tildeler tilgangen til en applikasjon mot samlingen i det miljøet + Så har applikasjonen tilgangen i hver organisasjon som er aktivt medlem av samlingen i miljøet + Og applikasjonen har ikke tilgangen i organisasjoner som ikke er medlem + + Scenario: Tildeling i ett miljø gir ingen virkning i et annet + Gitt samlingen har medlemsorganisasjoner i både testmiljøet og produksjonsmiljøet + Og jeg har rettighet til å tildele tilgangen i hver av medlemsorganisasjonene i testmiljøet + Når jeg tildeler tilgangen til en applikasjon mot samlingen i testmiljøet + Så har applikasjonen tilgangen i medlemsorganisasjonene i testmiljøet + Og applikasjonen har ikke tilgangen i produksjonsmiljøet + + Scenario: Tilgangen drar med seg de tilgangene den omfatter + Gitt tilgangen omfatter svakere tilganger + Når tilgangen er gitt til en applikasjon mot samlingen i et miljø + Så har applikasjonen også de svakere tilgangene i medlemsorganisasjonene i miljøet + + Scenario: Tildele flere tilganger mot flere samlinger i samme forespørsel + Gitt jeg har rettighet til å tildele tilgangene i hver medlemsorganisasjon i de aktuelle samlingene og miljøene + Når jeg tildeler flere tilganger mot flere samlinger i samme forespørsel + Så er hver tilgang gitt mot den samlingen og det miljøet den ble sendt inn for + + Scenario: Tilgang kan gis til en deaktivert applikasjon + Gitt applikasjonen er deaktivert + Og jeg har rettighet til å tildele tilgangen i hver av samlingens medlemsorganisasjoner i miljøet + Når jeg tildeler tilgangen mot samlingen i det miljøet + Så er tilgangen registrert mot samlingen + Og deaktiveringen er uendret + + Regel: Tildeling mot en samling krever rettighet til å tildele i hver av medlemsorganisasjonene + + # Dette er egenskapens kjerneregel, og den er en anti-eskaleringsregel. Én tildeling mot en + # samling gir tilgangen i hver aktive medlemsorganisasjon. Holdt det å ha rettigheten i én + # av dem, kunne en administrator ved ett lærested gitt en applikasjon tilgang ved alle de + # andre ved å gå gjennom en samling lærestedet er medlem av. Rekkevidden av det man skriver + # skal ligge innenfor rekkevidden av det man selv har rettighet til. + # + # Rettigheten er den samme som for å tildele mot én organisasjon, jf. BRU-APP-API-007 — det + # er ikke en ny rettighet, og ingen egen samlingsrolle kreves. Den er per organisasjon og + # per miljø, som ellers. + + Scenario: Tildeling avvises når rettigheten mangler i én medlemsorganisasjon + Gitt jeg har rettighet til å tildele tilgangen i alle samlingens medlemsorganisasjoner i miljøet unntatt én + Når jeg forsøker å tildele tilgangen til en applikasjon mot samlingen i det miljøet + Så avvises tildelingen + Og ingen tilgang er gitt mot samlingen + Og det fremgår at rettigheten kreves for hver av medlemsorganisasjonene + + Scenario: Tildeling gjennomføres når rettigheten dekker alle medlemsorganisasjonene + Gitt jeg har rettighet til å tildele tilgangen i hver av samlingens medlemsorganisasjoner i miljøet + Og jeg har rettigheten også i organisasjoner utenfor samlingen + Når jeg tildeler tilgangen til en applikasjon mot samlingen i det miljøet + Så er tilgangen gitt mot samlingen + + Scenario: Rettigheten vurderes per miljø + Gitt jeg har rettighet til å tildele tilgangen i hver av samlingens medlemsorganisasjoner i testmiljøet + Og jeg har ikke rettigheten i produksjonsmiljøet + Når jeg forsøker å tildele tilgangen mot samlingen i produksjonsmiljøet + Så avvises tildelingen + + Scenario: Ingenting skrives når ett innslag i forespørselen avvises + Gitt jeg sender flere tildelinger i samme forespørsel + Og jeg mangler rettigheten i én medlemsorganisasjon for ett av innslagene + Når jeg forsøker å utføre forespørselen + Så avvises hele forespørselen + Og ingen av tildelingene er gitt + + Scenario: Samling uten aktive medlemmer i miljøet krever likevel tildelingsmyndighet i miljøet + Gitt en samling ikke har aktive medlemsorganisasjoner i et miljø + Og jeg har ikke rettighet til å tildele tilganger i noen organisasjon i det miljøet + Når jeg forsøker å tildele en tilgang mot samlingen i det miljøet + Så avvises tildelingen + + Scenario: Tilgang gitt mot en samling uten aktive medlemmer har ingen virkning + Gitt en samling ikke har aktive medlemsorganisasjoner i et miljø + Og jeg har rettighet til å tildele tilganger i det miljøet + Når jeg tildeler en tilgang til en applikasjon mot samlingen i det miljøet + Så er tilgangen gitt mot samlingen + Men applikasjonen har ikke tilgangen i noen organisasjon + + Regel: Å gi en tilgang som alt er gitt, eller trekke tilbake en som ikke gjelder, er suksess + + Scenario: Tildele en tilgang som alt gjelder mot samlingen + Gitt en tilgang er gitt til en applikasjon mot en samling i et miljø + Når jeg tildeler den samme tilgangen mot den samme samlingen og det samme miljøet på nytt + Så er tildelingen registrert som utført + Og tidspunktet tilgangen opprinnelig ble gitt er uendret + Og det finnes fortsatt bare én gjeldende tildeling for kombinasjonen + + Scenario: Trekke tilbake en tilgang som ikke gjelder + Gitt en applikasjon ikke har en gjeldende tilgang mot en samling i et miljø + Når jeg trekker tilbake den tilgangen mot samlingen i det miljøet + Så er tilbaketrekkingen registrert som utført + Og historikken er uendret + + Regel: En tilgang trekkes tilbake ved at gyldigheten lukkes, og historikken består + + Scenario: Trekke tilbake en tilgang gitt mot en samling + Gitt en tilgang er gitt til en applikasjon mot en samling i et miljø + Og jeg har rettighet til å tildele tilgangen i hver av samlingens medlemsorganisasjoner i miljøet + Når jeg trekker tilbake tilgangen mot samlingen i det miljøet + Så har applikasjonen ikke lenger tilgangen i medlemsorganisasjonene i miljøet + Og tilgangen gjelder fortsatt i de øvrige miljøene den er gitt i + + Scenario: Den tilbaketrukne tilgangen står i historikken + Gitt en tilgang er trukket tilbake mot en samling i et miljø + Når jeg åpner tilgangene for samlingen + Så ser jeg den tilbaketrukne tilgangen med tidspunktet den ble gitt og tidspunktet den ble trukket tilbake + Og jeg ser hvem som ga den og hvem som trakk den tilbake + + Scenario: Se hvilke tilganger som gjelder nå + Gitt en samling har både gjeldende og tilbaketrukne tilganger + Når jeg åpner tilgangene for samlingen og velger å se kun de gjeldende + Så ser jeg tilgangene som gjelder nå + Og de tilbaketrukne er ikke med i utvalget + + Regel: Tilbaketrekking berører ikke tilgang som består på annen vei + + Scenario: Tilgang tildelt direkte i en medlemsorganisasjon består + Gitt en applikasjon har en tilgang både mot en samling og tildelt direkte i en medlemsorganisasjon + Når jeg trekker tilbake tilgangen mot samlingen + Så har applikasjonen fortsatt tilgangen i den organisasjonen + Og den direkte tildelingen står uendret i applikasjonens egen tilgangsliste + + Scenario: Tilgang gitt gjennom en annen samling består + Gitt en organisasjon er medlem av to samlinger som begge har den samme tilgangen gitt mot seg + Når jeg trekker tilbake tilgangen mot den ene samlingen + Så har applikasjonen fortsatt tilgangen i organisasjonen gjennom den andre samlingen + + Scenario: Å fjerne en direkte tildeling fjerner ikke tilgangen som følger av samlingen + Gitt en applikasjon har en tilgang både mot en samling og tildelt direkte i en medlemsorganisasjon + Når jeg fjerner den direkte tildelingen i organisasjonen + Så er den direkte tildelingen fjernet + Og applikasjonen har fortsatt tilgangen i organisasjonen fordi organisasjonen er medlem av samlingen + Og tildelingen mot samlingen står uendret + + Regel: Virkningen følger medlemslisten + + # Dekningskravet vurderes når tildelingen gis. Endres medlemslisten etterpå, endres + # virkningen med den, uten at tildelingen berøres — å melde en organisasjon inn i en samling + # som alt har tildelinger, utvider de tildelingene til organisasjonen. Det er grunnen til at + # forvaltningen av medlemskapene er en egen og strengere gatet handling enn tildelingen, jf. + # BRU-TIL-SAM-001, og det er der en eventuell revalidering hører hjemme. + + Scenario: Ny medlemsorganisasjon omfattes av tildelingen + Gitt en tilgang er gitt til en applikasjon mot en samling i et miljø + Når en organisasjon meldes inn i samlingen i det miljøet + Så har applikasjonen tilgangen også i den organisasjonen + Og tildelingen mot samlingen står uendret + + Scenario: Organisasjon som meldes ut mister tilgangen + Gitt en tilgang er gitt til en applikasjon mot en samling i et miljø + Og en organisasjon er aktivt medlem av samlingen i det miljøet + Når organisasjonen meldes ut av samlingen i det miljøet + Så har applikasjonen ikke lenger tilgangen i den organisasjonen + Og tildelingen mot samlingen står uendret + + Scenario: Endring i medlemslisten i ett miljø endrer ikke virkningen i et annet + Gitt en tilgang er gitt til en applikasjon mot en samling i både testmiljøet og produksjonsmiljøet + Når en organisasjon meldes ut av samlingen i testmiljøet + Så har applikasjonen fortsatt tilgangen i organisasjonen i produksjonsmiljøet + + Regel: Tildelingene mot en samling er skjermet, mens katalogen og medlemslisten er åpen + + Scenario: Se tildelingene mot en samling jeg kan tildele mot + Gitt jeg har rettighet til å tildele tilganger i hver av samlingens medlemsorganisasjoner i miljøet + Når jeg åpner tilgangene for samlingen + Så ser jeg hvilke applikasjoner som har fått hvilke tilganger, i hvilket miljø + + Scenario: Tildelingene er ikke synlige uten rettigheten + Gitt en samling har tilganger gitt mot seg i et miljø + Og jeg mangler rettigheten til å tildele i én av samlingens medlemsorganisasjoner i miljøet + Når jeg åpner tilgangene for samlingen + Så ser jeg ingen tildelinger + Og det fremgår at en tom liste ikke betyr at samlingen er uten tildelinger + + Scenario: Katalogen og medlemslisten er synlig uten rettigheten + Gitt jeg ikke har rettighet til å tildele tilganger i noen av samlingens medlemsorganisasjoner + Når jeg åpner samlingen + Så ser jeg samlingens navn, beskrivelse og medlemsorganisasjoner per miljø + Men jeg ser ingen handling for å tildele en tilgang mot samlingen + + Scenario: Medlemslisten forklarer et avslag + Gitt en tildeling mot en samling er avvist fordi rettigheten mangler i en medlemsorganisasjon + Når jeg åpner medlemslisten for samlingen i miljøet + Så ser jeg hvilke organisasjoner rettigheten kreves for