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