Lage støtte for labels på dialoger

[elsand]

Det er behov for sluttbrukere (gjennom sluttbrukerløsninger) å kunne definere metadata på dialoger som kan brukes til f.eks. mappestrukturering, kategorisering, intern status-flagging etc. Dette vil gi sluttbrukere større kontroll over hvordan de ønsker å strukturere sin egen innboks. Siden vi legger opp til at tjenesteeiere skal bruke SO-API med fnr-filtrering for egne flater, trenger vi å eksponere dette for SO-API også (read-only)

For å kunne implementere dette er det en rekke spøsmål som må besvares

• Hvor skal labels defineres?
  • Enkelte parties (kan knyttes til alle dialoger med samme party)
  • Parties m/underenheter (kan knyttes til alle dialoger med samme party, eller for dialoger som er en underenhet av gitt party. På denne måten kan man ha samme sett med labels på tvers av avdelinger organisert som underenheter)
  • For leverandør-party (regnskapsbyråer vil kunne ha behov for å bruke samme type labels på tvers av sine kunder)
  • User-nivå (labels som er personlige, og kun sees av en selv)
• Hvem skal kunne definere labels?
  • Egen systemressurs i Altinn som knyttes til ER-roller / pre-definerte tilgangsgrupper?
• Hvem skal kunne sette labels på dialoger?
  • Må det defineres eksplisitt i XACML?
• Hvordan skal labels struktureres? URN-er med namespacing (for ulike typer labels, f.eks. "arbeidsflate-mappe:Rotmappe/Undermappe/Undermappe")
• Støtte for lokalisering?

Mulig konsept

• Labels defineres som en del av en gruppe
• Definere systemressurser: "labels-admin", "labels-assign", "labels-read"
  • "labels-admin" gir rettighet til å legge til / fjerne / redigere labels innenfor gruppa
  • "labels-assign" gir rettighet til å knytte en label fra gruppa til en dialog (hvilken som helst, også de eid av andre parties)
  • "labels-read" gir kun mulighet til å lese labels (og label assignments) tilhørende den gruppa
  • PRIV og nøkkelrollene pluss kanskje HADM/tilgangsstyrer gir "labels-admin"
  • Alle andre tilgangsgrupper gir labels-read og evt. labels-write
• En label-gruppe eies av alltid av en bruker, men kan også knyttes til en annen party som brukeren har "labels-admin"
  • Andre brukere som har labels-* for det partyet vil da kunne se label-gruppen
    • Kun synlig hvis man foretar et søk kun innenfor det partyet (les: har valgt det partyet som avgiver)
  • Hvem som helst kan "pinne" en labelgruppe (enten en av sine egne) som en global label-gruppe (som da vises uavhengig av hvilken party man ser på, les: er synlig for alle avgivere, også søk-på-tvers)
    • Labelgrupper knyttet til en selv er alltid globale
• Alle med lesetilgang til en labelgruppe kan kopiere den til seg selv

Databaseentiteter og relasjoner

erDiagram
    "Party (owner)" ||--o{ LabelGroup: "owns 0..N"
    "Party (user)" ||--o{ "Party (having labelgroup)" : "has access to labelgroups when assigned label_{read,assign,admin} with" 
    "Party (having labelgroup)" ||--o{ LabelGroup: "associated with 0..N"    
    LabelGroup ||--o{ Label: "contains 1..N"
    Label ||--o{ LabelAssignment : "has 1..N"
    Dialog ||--o{ LabelAssignment : "has 1..N"


    LabelGroup {
        guid labelGroupId PK, FK
        string ownerParty FK
        nullable_string belongsToParty FK
        string name
    }

    Label {
        guid labelId PK, FK
        guid labelGroupId FK
        string name
    }

    LabelAssignment {
        guid assignmentId PK
        guid labelId FK
        guid dialogId FK
        string assignedByParty FK
    }
    

Bruk i DTO-er

• Kan integreres som en del av liste-DTO-en
• Eget rot-aggregat (for administrasjon/tildelinger)