Etablere søke-API for dialoger for sluttbrukere

[elsand]

Dialogporten skal ha et søke-API som gjør det mulig å hente ut lister av dialoger for sluttbrukere.

DTO-ene som brukes for å beskrive dialoger i lister har mindre informasjon enn detalj-visningen. Den skal inneholde informasjon om

• Id
• Org
• Tjenesteressurs
• Party
• Status
• ExtendedStatus (hvis satt)
• CreatedAt, UpdatedAt, DueAt
• Tittel
• Avsenders navn

Autorisasjon

Se #42

Tasks

Preview Give feedback

1. Etablere endepunkt /api/v1/endusers/dialogs/
2. Analyse: Avgjøre hvilke krav til filtrering skal ha; om noen.
3. Ha støtte for filtrering på (full match, kan oppgi lister); org, serviceresource, party, status, extendedstatus
4. Ha støtte for å oppgi til/fra datoer for hhv createdat, updatedat, dueat
5. Ha støtte for et søkeparameter som søker i title, avsenders navn og searchTags, samt ha et parameter for språk
6. Ha støtte for sortering på createdat, updatedat, dueat både stigende og synkende (en flere felter)
7. Ha støtte for limit
8. Implementere validering per kriterier under

Akseptansekriterier

GITT en autorisert forespørsel til søke-API-et
NÅR det ikke oppgis noen parametre
SÅ skal det returneres opptil 100 elementer sortert synkende etter createdAt

GITT en autorisert forespørsel til søke-API-et
NÅR søkeparameter oppgis uten at parameter for søkespråk oppgis
SÅ skal det returneres en liste med dialogliste-DTO-er som inneholder det oppgitte søkeordet i title, searchTags eller avsenders navn på hvilket som helst av del definerte språkene

GITT en autorisert forespørsel til søke-API-et
NÅR søkeparameter oppgis og parameter for søkespråk oppgis
SÅ skal det returneres en liste med dialogliste-DTO-er som inneholder det oppgitte søkeordet i title, searchTags eller avsenders navn på det oppgitt språket

GITT en autorisert forespørsel til søke-API-et
NÅR det verken oppgis filteringsparametere for party eller for tjenesteressurs
SÅ skal det returneres en 400 Bad request med feilmelding om at minst ett party eller minst én tjenesteressurs må oppgis

GITT en autorisert forespørsel til søke-API-et
NÅR det oppgis filtreringsparametre som inneholder kommadelte lister av verdier for en eller flere av følgende felter: org, serviceresource, party, status, extendedstatus
SÅ skal det returneres en liste med dialogliste-DTO-er som svarer til filtrene, hvor feltene AND-es og listene innfor hvert felt OR-es, sortert synkende etter createdAt

GITT en autorisert forespørsel til søke-API-et
NÅR det oppgis filtreringsparametre som inneholder kommadelte lister av verdier for en eller flere av følgende felter: org, serviceresource, party, status, extendedstatus
OG en av de oppgitte listene for org, serviceresource, party eller extendedstatus inneholder mer enn 20 verdier
SÅ skal det returneres en 400 Bad request med feilmelding om at maks 20 verdier kan oppgis

GITT en autorisert forespørsel til søke-API-et
NÅR det oppgis filtreringsparametre som inneholder kommadelte lister av verdier for status
OG en av de oppgitte verdiene ikke er en kjent status-verdi
SÅ skal det returneres en 400 Bad request med feilmelding om hvilke status-verdier som er gyldige

GITT en autorisert forespørsel til søke-API-et
NÅR til/fra datoer for createdAt og/eller updatedAt og eller dueAt oppgis i ISO 8601 timestamp-format med tidssone
SÅ skal det returneres en liste med dialogliste-DTO-e som svarer til filtrene sortert synkende etter createdAt

GITT en autorisert forespørsel til søke-API-et
NÅR sorteringsparametere oppgir én av createdat, updatedat og dueat
OG parameter for sorteringsretning oppgis til synkende eller er ikke oppgitt
SÅ skal det returneres en liste med dialogliste-DTO-er som svarer til sorteringsparameterne synkende

GITT en autorisert forespørsel til søke-API-et
NÅR sorteringsparametere oppgir én av createdat, updatedat og dueat
OG parameter for sorteringsretning oppgis til stigende
SÅ skal det returneres en liste med dialogliste-DTO-er som svarer til sorteringsparameterne stigende

GITT en autorisert forespørsel til søke-API-et
NÅR det oppgis sorteringsparametre som ikke er kjente
SÅ skal det returneres en feilmelding (400 Bad Request) med body som informerer om hvilke sorteringsparametre som er gydlige

GITT en autorisert forespørsel til søke-API-et
NÅR det oppgis filtreringsparametere som ikke er kjente
SÅ skal disse ignoreres, og det returneres en liste som spesifisert over

GITT en autorisert forespørsel til søke-API-et
NÅR det oppgis et pagineringsantall og dette antallet er et heltall mellom 1-1000
SÅ skal det returneres opptil det oppgitte pagineringsantallet elementer som svarer til evt. oppgitte filtre og sorteringsrekkefølge

GITT en autorisert forespørsel til søke-API-et
NÅR det oppgis et pagineringsantall og dette antallet IKKE er et heltall mellom 1-1000
SÅ skal det returneres en feilmelding (400 Bad request) med body som informerer om feilen

GITT en autorisert forespørsel til søke-API-et
NÅR en dialog har en satt VisibleAt-dato som er ETTER gjeldende tidspunkt
SÅ skal dialogen ikke vises i lista

GITT en autorisert forespørsel til søke-API-et
NÅR en dialog har en satt ExpiresAt-dato som er FØR gjeldende tidspunkt
SÅ skal dialogen ikke vises i lista

GITT en autorisert forespørsel til søke-API-et
NÅR en forespørselen inneholder et filters om reduserer antall elementer til null, eller brukeren ikke er autorisert for noen elementer
SÅ skal returen være en tom liste og 200 OK

GITT en autorisert forespørsel til søke-API-et
NÅR en forespørselen inneholder et after-parameter som ikke er et ISO 8901-timestamp
SÅ skal det returneres en feilmelding (400 Bad request) med body som informerer om feilen

GITT en autorisert forespørsel til søke-API-et
NÅR en forespørselen inneholder et after-parameter som er et ISO 8901-timestamp
OG parameter for sorteringsretning oppgis til synkende eller er ikke oppgitt
OG parameter for sortering ikke er oppgitt
SÅ skal det returneres alle dialoger som har createdAt < oppgitt timestamp

GITT en autorisert forespørsel til søke-API-et
NÅR en forespørselen inneholder et after-parameter som er et ISO 8901-timestamp
OG parameter for sorteringsretning oppgis til stigende
OG parameter for sortering ikke er oppgitt
SÅ skal det returneres alle dialoger som har createdAt > oppgitt timestamp

GITT en autorisert forespørsel til søke-API-et
NÅR en forespørselen inneholder et after-parameter som er et ISO 8901-timestamp
OG parameter for sortering er oppgitt
SÅ skal det returneres alle dialoger som har sorteringsfelt-verdi større/mindre (avhengig av sorteringsretning) enn eller lik oppgitt timestamp

Se også

• Implementere full autorisasjonskontroll på dialoger i søke-API for sluttbrukere #42
• Etablere søke-API for dialoger for tjenesteeiere #117

[elsand]

PostgreSQL full text-search: https://www.postgresql.org/docs/current/textsearch.html
Extension support for pg_trgm: https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-extensions#postgres-14-extensions

Bruk av full text match og pg_trgm sammen: https://www.postgresql.org/docs/13/pgtrgm.html#id-1.11.7.40.9

Eksempel på bruk av pg_trgm og similarity (%) operator for fuzzy matching:

-- Det kreves GIN indekser for felter som skal søkes i
CREATE INDEX trgm_idx_title ON dialogsUSING GIN (title gin_trgm_ops);
CREATE INDEX trgm_idx_searchtags ON dialogs USING GIN (body gin_trgm_ops);
CREATE INDEX trgm_idx_sendername ON dialogs USING GIN (body gin_trgm_ops);
CREATE INDEX trgm_idx_body ON dialogs USING GIN (body gin_trgm_ops);


SELECT *
FROM dialogs 
WHERE title % 'satisfied' OR searchtags % 'satisfied' OR sendername % 'satisfied' OR body % 'satisfied';

-- Vil returnere rader hvor noen av disse feltene inneholder ord som f.eks. "satisfying"

-- Se også
SET pg_trgm.similarity_threshold = 0.3;

[elsand]

Edit: Vi går bort fra dette i denne omgang.

Forklaring på kriterie:

| GITT en autorisert forespørsel til søke-API-et
| NÅR en forespørselen inneholder et after-parameter som er en sammensatt nøkkel av et ISO 8901-timestamp og en id
| SÅ kal det returneres alle elementer med utgangspunkt i createdAt (jf sorteringsrekkefølge) fra, og ikke med, oppgitt id

Dette er for å kunne håndtere paginering gjennom elementer med lik createdAt. Ta f.eks.:

id	createdAt
1	2021-01-01
2	2021-01-02
3	2021-01-02
4	2021-01-02
5	2021-01-03

• after=2021-01-02 vil returnere radene 2,3,4,5.
• after=2021-01-02_4 vil returnere radene 4,5.
• after=2021-01-02_4 vil med motsatt sorteringsrekkefølge returnere radene 4,3,2,1

[elsand]

Lukke analyse-tasken for søke-kriterie-krav. Vi må ta utgangspunkt i noe for å kunne foreta en autorisasjon, og for felles arbeidsflate vil det i første omgang alltid være snakk om én party. "Søk-på-tvers"-funksjonalitet vil også kunne håndteres gjennom at man kan søke på flere avgivere (opptil et gitt antall, foreløpig definert som 20), eller bare oppgi en eller flere service resources (også oppad begrenset til 20). Denne begrensningen er for å unngå ekstremt store responser knyttet til autorisasjon (se #42)

[elsand]

Oppdaterte kriterier:

• Fjernet kriterie om å kunne oppgi flere sorteringsfelter - kun ett av created, updated, due kan oppgis
• La til krav om at pagineringsverdi skal være den samme som sorteringsverdi, hvis oppgitt. Hvis ikke oppgitt, benyttes createdAt.

Edit: fler-feltssortering er tilbake pga. funksjonelt behov for dueAt_asc,updatedAt_desc