For aktør med mange tilganger er det noe som bryter tellingen av dialoger

[LeifHelstad]

Description of the bug

Under test av at bug #1492 var rettet (noe den er) så ble det opplevd samme symptom (at ikke dialoger telles) med en annen bruker 14836098626 som har tilgang til veldig mange personer og organsiasjoner.

I #1492 var problemet at noe var "undefined". I denne nye gjelder nok mer sannsynlig at man har gått over en eller annen terskelverdi. (Uten at det utelukker at også her kan undefined eller noe annet også være årsak.)

Steps To Reproduce

1. Åpne Arbeidsflate i Staging miljø som bruker 14836098626
2. Åpne menyen over mulige aktører brukeren kan se

• observer at det ikke telles opp dialoger på noen av aktørene
• henter man dialoger for "Alle virksomheter" (antakelig 78 virksomheter) så vises ingen dialoger

3. Scroll ned til skillet mellom personer og vikrsomheter

• her virker det forresten å være noe problem med scroll så skjermen må gjøres så høy at man ser hele listen ned hit. Alternativt zoome ut i skjembildet så man ser listen ned hit (det blir opprettet separat bug på dette)
• Observer: Det telles ikke dialoger for første virksomhet "Almektig Ukontroversiell Tiger AS"
  

4. Velg første virksomhet "Allmektig Ukontroversiell Tiger AS"

• Observer: Virksomhet "Allmektig Ukontroversiell Tiger AS" har en dialog
  

Additional Information

Det som kanskje er litt spesielt her er at tilgangen til å få listet virksomheten var tilstede også i går. Men da gikk det ikke an å se dialogen. Her er det endret i policy slik at 14836098626 skal kunne se den.
Ref:
Bjørn Dybvik Langfors 8:38 AM
Jeg har oppdatert policyen for super-simple-service til å inkludere A0239. Ser nå at et søk etter denne ressursen fra var daglige leder 14836098626 får treff på to dialoger hos hhv 314932706 og 313110745, som begge er orger som har tildelt REGN til 213796712, som denne brukeren er DAGL for

Hypotese fra test, det kan være at tellingen ikke hensyntar alle detaljer i tilgangspolicy når tilgangen er arvet via en ORG som er REGN?

[seanes]

Det ser ut som det er en begrensning på maks 20 parties.

For å reprodusere:

query getAllDialogsForParties($partyURIs: [String!], $search: String, $org: [String!], $status: [DialogStatus!]) {
  searchDialogs(
    input: {party: $partyURIs, search: $search, org: $org, status: $status}
  ) {
    items {
      id
    }
  }
}


{
  "partyURIs": [
    "urn:altinn:person:identifier-no:05833149581",
    "urn:altinn:organization:identifier-no:312595710",
    "urn:altinn:person:identifier-no:13918897199",
    "urn:altinn:person:identifier-no:22918699795",
    "urn:altinn:organization:identifier-no:313028410",
    "urn:altinn:organization:identifier-no:311805215",
    "urn:altinn:organization:identifier-no:312474484",
    "urn:altinn:organization:identifier-no:313388042",
    "urn:altinn:organization:identifier-no:312942224",
    "urn:altinn:organization:identifier-no:310047074",
    "urn:altinn:organization:identifier-no:312931761",
    "urn:altinn:organization:identifier-no:310811270",
    "urn:altinn:organization:identifier-no:213365312",
    "urn:altinn:organization:identifier-no:212910872",
    "urn:altinn:organization:identifier-no:314260317",
    "urn:altinn:organization:identifier-no:313464962",
    "urn:altinn:organization:identifier-no:313293092",
    "urn:altinn:organization:identifier-no:314932706",
    "urn:altinn:organization:identifier-no:311570498",
    "urn:altinn:organization:identifier-no:311253042",
    "urn:altinn:organization:identifier-no:215372472"
]
}

Gir null i resultat.

Fjern ett vilkårlig party fra partyURIs slik at den går fra 21 til 20 partyIds, og kallet går fint (= returnerer én dialog)

[LeifHelstad]

@MagnusSandgren og @elsand denne "buggen" på at det cappes på >20 parties før man slutter å hente dialoger er noe som ligger i dialogporten. Spør man med 21 parties får man "null" i svar. Fjernes et tilfeldig party slik at man spør på 20 så får man dialoger i svaret (i dette eksempelet er det kun en dialog.)

Problemet nå er at denne er koblet til repo dialogporten-frontend. Så straks jeg får lagret kommentaren skal jeg forsøke en "Transfer issue" til repo dialogporten.

[LeifHelstad]

@elsand i dagens refinement ble det nevnt at kun dialoger for de 50 første aktørene ble returnert.
Denne saken er et eksempel på at DP lar være å telle dialoger når 20 aktører passeres.
For meg burde denne 20 og 50 grensen ha vært den samme da den setter en øvre grense for antall aktører det hentes dialoger for.
I tillegg ble det i dag nevnt en regel på at det aldri returneres mer enn 1000 dialoger uavhengig av antall aktører de henger på.
Finnes det en samlet oversikt over alle disse øvre grensene?

[elsand]

@LeifHelstad

Nei, det stemmer ikke. Begrensningen er at sluttbruker-API-et for uthenting av dialog-lister krever at det oppgis enten parameter for party (aktør) eller serviceResource (tjeneste), eller begge deler. Hver av disse kan gjentas inntil 20 ganger. Dette betyr altså at man kan gjøre en request som f.eks

/api/v1/enduser/dialogs?party=<orgnr_el_fnr_1>&party=<orgnr_el_fnr_2>&...(andre filtreringer)
/api/v1/enduser/dialogs?serviceResource=<tjeneste_1>&serviceResource=<tjeneste_2>&...(andre filtreringer)

Sistnevnte vil returnere alle dialoger knyttet til tjeneste_1 og tjeneste_2 for alle aktører den autentiserte brukeren har tilgang til, uansett hvor mange det måtte være.

Førstnevnte er da det inverse, og returnerer alle dialoger knyttet til alle tjenester for de oppgitte aktørene (som også brukeren er autorisert for).

Så er REST API-et også paginert. Som default returneres 100 items, men man kan oppgi et limit paramenter opp til 1000, og vil da kunne hente neste sett med X elementer gjennom pagineringslenken som returneres. Her er jeg ikke 100% sikker på hvordan dette er satt opp i GQL, men forventer at det er lagt opp til en tilsvarende pagineringsmekanisme der.

(Regelen med at det aldri returneres mer enn 1000 elementer for hhv innboks og arkiv er imidlertid en begrensning i Altinn 2; der vil du rett og slett få en feilmelding med anmodning om å begrense søket om du det treffer >1000 elementer. Vi har ikke noen tilsvarende begresning i Dialogporten)

[LeifHelstad]

Test

Hvorfor det ikke gir mening å teste dagens AF-implementasjon når man krysser pagineringsgrensen.

I dag blir løsiningen helt uforutsigbar da 100-regelen treffer helt ulikt ut fra hva man "gjør" i GUI

Tenkte eksempeldata:

• Person A har organisasjon B og C som avgivere.
• A, B og C har hver seg en del dialoger etter denne fordelingen
  • A: 55 totalt hvorav 50 uleste
  • B: 65 totalt hvorav 60 uleste
  • C: 75 totalt hvorav 70 uleste
• Basert på erfaring med å møte capping på 100 så leses org først så når AF spør DP om dialoger fra A+B+C så leses de fra C først (i page)

Data vist i GUI ved dagens implementasjon:

• Innboks : antall uleste (rød ball) vil si ca 93 uleste
  • 75 fra C gir 70 uleste
  • 25 (av de 65 fra B) gir ved jevn fordeling ca 23 uleste
• Aktørvalg vil i sum vise 100
  • Totalt 75 fra C
  • Totalt 25 fra B (her stopper page slik at de 40 neste fra B er på neste page som ikke hentes)
  • Ingen fra A (for her er alle 55 på neste page)
• Inne på enkeltaktør vil alle lister være kortere enn 100.
  • A: 55 totalt hvorav 50 uleste
  • B: 65 totalt hvorav 60 uleste
  • C: 75 totalt hvorav 70 uleste
• Detaljer: Teller man sammen detaljene for hver enket vil man få (55+65+75 =) 195 dialoger hvorav (50+60+70 =) 180 uleste
• Summeringer: Ser man på de summeringene som presenteres for bruker telles kun 100 dialoger totalt i aktørliste og innboks vil vise 93 uleste

Konklusjoner

• Vi bør sette pagineringsgrensen ned til 10, det vil gjøre det mer synlig at de ulike hentingene vil medføre resultater på agregert nivå som ikke samsvarer med det man ser når man går inn på enkeltaktører.
• Paginering av dialoger for enkeltaktører er ikke en del av dette problemet, det er sitt eget problem.
• Det som strengt tatt er årsaken til at For aktør med mange tilganger er det noe som bryter tellingen av dialoger #1625 er opprettet, at tellingen ikke gjøres ved 20+ avgivere er ikke problemet med at 100 dialoger grensen gir ulike resultater aggregert sett opp mot resultatet per avgiver. Det betyr at det som er beskrevet under Test her bør opprettes som en egen sak.