Krav: forvalte tilgangskatalogen gjennom API, med eget nivå for dokumentasjon (BRU-TIL-KAT-001/002)

[krhoybraten-sikt]

Tilgangskatalogen — listen over hvilke tilganger som finnes, og hva hver av dem gir — forvaltes i dag bare av databaseforvaltningen. Denne PR-en beskriver kravene til å forvalte den gjennom API, med to rettighetsnivåer.

De to nivåene

Nivå	Rettigheten omfatter	Hvem
Forvaltning (BRU-TIL-KAT-001)	Opprette en tilgang, endre den, ta den ut av bruk	Utviklere hos Sikt
Dokumentasjon (BRU-TIL-KAT-002)	Oppdatere beskrivelsen — og ingenting annet	Bidragsytere til dokumentasjonen

Begrunnelsen for det andre nivået er at dokumentasjonen av en tilgang eldes raskest og skrives best av dem som kan fagområdet, mens risikoen er lav på en presis måte: en beskrivelse leses ikke av autorisasjonen. Ingen får eller mister tilgang av at teksten endres, og ingen tildeling berøres. Uten et eget nivå må hver tekstforbedring gå gjennom dem som kan endre modellen — og da blir den ikke gjort.

Kolonneskopet er et håndhevingskrav

Den delen som er verdt review: at dokumentasjonsrettigheten bare omfatter beskrivelsen er formulert som et krav til håndhevingen, ikke til hvilke felter en flate viser. En flate som skjuler kodefeltet, over et API som tar imot hele katalograden, oppfyller ikke kravet — da er avgrensningen bare en presentasjon, og enhver klient som snakker med API-et direkte står utenfor den.

Featuren har derfor egne scenarioer for de to formene som skiller et håndhevet kolonneskop fra et presentert et: en forespørsel som endrer både beskrivelsen og noe annet avvises i sin helhet, og avgrensningen gjelder likt når API-et brukes direkte. Designnotatet anbefaler dessuten at dokumentasjonsnivået får sin egen operasjon, som bare tar imot en kode og en beskrivelse, framfor å dele en generell endringsoperasjon og filtrere på rettighet inne i den.

Katalogen kan ikke listes i dag

Kravene omfatter også en listespørring over hele katalogen, paginert og forutsigbart sortert, lesbar for begge nivåene. Ingen av dagens innganger viser katalogen i sin helhet: listene som finnes er alle avledet av noe annet — tilgangene en applikasjon har, tilgangene jeg selv har, tilgangene jeg kan tildele. En tilgang som ennå ikke er tildelt noen finnes dermed i modellen, men er usynlig i løsningen.

Det rammer begge nivåene, og dokumentasjonsnivået hardest: de udokumenterte tilgangene er nettopp dem som ofte ikke er tildelt noen, altså dem ingen liste viser. Paginering er tatt inn i kravet framfor å overlates til utformingen, fordi katalogen verken har organisasjon eller miljø å avgrense på.

To hull kravene forutsetter tettet

Designnotatet navngir dem eksplisitt, siden begge er modellarbeid og ikke bare flatearbeid:

1. Listespørringen over hele katalogen, som beskrevet over.
2. En markør for «tatt ut av bruk». Katalogen har i dag ingen livsløpstilstand — en rad er kode, beskrivelse og sporing — og sletting er utelukket fordi tildelinger, delegeringstak og nekt refererer koden. Hvilken form markøren skal ha står som et åpent designspørsmål.

Valg

• Krav-ID-er: BRU-TIL-KAT-001 og BRU-TIL-KAT-002, etter mønsteret fra naboene under samme kapabilitet (BRU-TIL-SAM-* for organisasjonssamlinger, BRU-TIL-DEL-* for delegeringstak). Plassert i en ny kapabilitetsmappe 11 Tilgangsstyring/04 Tilgangskatalogen.
• Avgrenset til tilgangene selv. Implikasjoner mellom tilganger og navnerom er ikke omfattet — de er den delen som faktisk endrer rekkevidde, og de står som åpent spørsmål. Dokumentasjonsnivået har egne scenarioer for at begge deler avvises.
• Rettighetene er beskrevet funksjonelt («utviklerrettighet for tilgangskatalogen», «rettighet til å oppdatere beskrivelser»), uten rollekoder — navngivningen hører sammen med implementasjonen.

Implementasjonen kommer i FS-plattformen; denne PR-en dekker kravsiden.

Ikke merge — til gjennomlesning.