Feat: Preserve Active Filters in URL
Closed this issue · 3 comments
Feature Request: Preserve Active Filters in URL
Description:
To maintain a consistent and user-friendly experience, active filters chosen by the end-user should be preserved in the URL. This ensures filters are persistent across page reloads or when bookmarks are saved. Additionally, sensitive data such as party IDs should not be included; instead, names or other non-sensitive identifiers should be used.
Background:
Currently, filters are being utilized as query parameters to rehydrate the filter state (e.g., populate search and filters with pre-selected values) when loading "saved searches." However, once these values are loaded, the filters query parameters are removed from the URL. This approach introduces unwanted side effects and is brittle to maintain.
Furthermore, the URL is not being updated when filters are applied. As a result, reloading the page or manually saving a bookmark does not preserve the active filters.
Proposed Improvements:
-
Dynamic URL Update:
- Applying filters should dynamically update the URL to reflect the active filters.
- This ensures that the current state is easily shareable and bookmarkable.
-
Persistent Reloads:
- Reloading the page should load the filters from the URL and rehydrate the state seamlessly.
-
Context-Aware Filters:
- Filters that are not applicable for the selected party should be ignored and removed from the URL.
- Example: If a filter is applied to Party X but the user switches to Party Y, and the filter is not relevant to Party Y’s dialogs, it should not be retained in the active filters.
-
Retain Query Parameters:
- After filters are loaded from the URL, the query parameters should remain intact.
- This prevents unexpected behavior and ensures consistency for users navigating back or refreshing the page.
Acceptance Criteria:
- The URL should accurately reflect the active filters at all times.
- Reloading or bookmarking a page with active filters should maintain the filter state.
- Filters irrelevant to the current party should be excluded from the URL.
- Query parameters should not be removed after loading filters.
- Party IDs should be replaced with names or other non-sensitive identifiers in the URL, e.g. for senders and receivers. (This is already in place today).
Technical Notes:
- Ensure changes are compliant with security standards to avoid exposing sensitive information in the URL.
TestPlan
TestCase : Preserve Active Filters in URL : Dynamic URL Update : Retain Query Parameters (1xx)
TC-100 : active filters chosen by the end-user should be preserved in the URL
TC-101 : Applying filters should dynamically update the URL to reflect the active filters
TC-102 : After filters are loaded from the URL, the query parameters should remain intact.
TC-103 : This prevents unexpected behavior and ensures consistency for users navigating back ...
TC-104 : This prevents unexpected behavior and ensures consistency for users ... refreshing the page
TC-105 : The URL should accurately reflect the active filters at all times.
ExpectedResult (1xx)
ER-10x : Expectations are included in each TC description
TestCase : Preserve Active Filters in URL : Persistent Reloads (2xx)
TC-200 : ensures filters are persistent across page reloads
TC-201 : Reloading the page should load the filters from the URL and rehydrate the state seamlessly
TC-202 : Reloading ... a page with active filters should maintain the filter state.
ExpectedResult (2xx)
ER-20x : Expectations are included in each TC description
TestCase : Preserve Active Filters in URL : Context-Aware Filters (3xx)
TC-300 : ensures filters are persistent when bookmarks are saved
TC-301 : the current state is easily shareable and bookmarkable
TC-302 : ...bookmarking a page with active filters should maintain the filter state.
ExpectedResult (3xx)
ER-30x : Expectations are included in each TC description
TestCase : Preserve Active Filters in URL (4xx)
TC-400 : sensitive data such as party IDs should not be included
TC-401 : names or other non-sensitive identifiers should be used
TC-402 : Query parameters should not be removed after loading filters
TC-403 : Party IDs should be replaced with names or other non-sensitive identifiers in the URL, e.g. for senders and receivers.
ExpectedResult (4xx)
ER-40x : Expectations are included in each TC description
TestCase : Context-Aware Filters (5xx)
TC-500 : Filters that are not applicable for the selected party should be ignored and removed from the URL
TC-501 : If a filter is applied to Party X but the user switches to Party Y, and the filter is not relevant to Party Y’s dialogs, it should not be retained in the active filters
TC-502 : Filters irrelevant to the current party should be excluded from the URL
ExpectedResult (5xx)
ER-50x : Expectations are included in each TC description
TestRun
TestData (1xx)
TD-100 + 101 + 102 + 105 : Aktør 08895699684 : Avsender : DMF
TD-103 : "Go Back"/"Tibake", benytter "(Alt + Pil venstre)"
TD-104 : "CTRL + R"
ActualResult (1xx)
🟢 AR-100 + 101 + 102 + 105 : https://af.tt.altinn.no/?loggedIn=true&sender=Direktoratet+for+mineralforvaltning
🟡 AR-103 : Tilbake i historikk (Alt + Pil venstre) sender bruker tilbake til siden før arbeidsflate ble åpnet. Å navigere tilbake i historikk fungerer ikke så lange det ikke finnes historikk å navigere i.
Se diskusjon under "Observasjon" og "Konklusjon". Det er mulig dette kan ansees som en feil. Det er kun et corner-case der bruker kun har stått i innboks og manipulert masse på filtre. Tilbake tar brukeren ut av innboks og samtidig ut av arbeidsflate.
🟢 AR-104 : Sidne lastes på nytt. URL = OK, viste filtre = OK, listede dialoger = OK
Observasjon
- Tilbake-navigasjon som sådan fungerer så lenge det finnes noe å navigere i. Hvis kan går rundt i menyvalg som "Utkast", "Lagrede søk" og "Papirkurv" så dannes historikk man kan navigere bakover i.
- Problemet er at arbeidsflate ikke skiller på en side med eller uten filter så det er slik "innboks" så ut når man klikket videre til "utkast" som huskes.
- Bruker kan gå "fremover" til innboks igjen og sette et nytt filter. Gjør man da to tilbake (via utkast) så kommer bruker tilbake til innboks med det filteret som opprinnelig ble satt.
- Da er det mulig det er riktig at man stepper helt ut av arbeidsflate om man kun har stått i innboks. Uavhengig av hvor mye man har vridd og vendt på filtre i innboksen.
Konklusjon
- Modifisering av filter som medfører modifisering av URL er ikke en ny side. Det er bare en ny URL til (en variant av) samme side.
- Dette kan være litt forvirrende, da man basert på erfaring fort kan tenke at en oppdatert URL er en ny side (i historikk).
- Samtidig er det ikke en ny side, for det er kun parametre etter "?" som er endret.
Ref: samme side med flere parametere (der historikk husker siden med siste parametersett)
https://af.tt.altinn.no/
https://af.tt.altinn.no/?sender=Skatteetaten
Versus at "utkast" er en annen side og at navigering til utkast danner historikk
Hvis det er slik at "sidehistorikk" ikke kan ansees som en "filterhistorikk" så er muligens TC-103 med AR-103 helt OK?
TestData (2xx)
TD-200 + 201 + 202 : Aktør 08895699684 : Avsender : DMF : "CTRL + R"
ActualResult (2xx)
🟢 AR-200 + 201 + 202 : Fungerer i praksis likt som TC+AR-104
TestData (3xx)
TD-300 + 301 + 302 : Aktør 08895699684 : Avsender : DMF : Legg til i favoritter via "CTRL + D"
ActualResult (3xx)
🟢 AR-300 : Favoritt-bokmerket husker filtervalget : https://af.tt.altinn.no/?loggedIn=true&sender=Direktoratet+for+mineralforvaltning
🟢 AR-301 : Favoritt-bokmerket kan enkelt hentes og deles
🟢 AR-301 : Å bokmerke den opprinnelige siden medførte ikke noen utilsiktede endringer på siden
TestData (4xx)
TD-400 + 401 + 403 : Aktør 26818999827 : Avsender : Skatt og Digdir
TD-402 : Lagre filter fra TC-400 : Lukk kriteriene slik at alle filterparametre fjernes fra URL : Hent filter fra "Lagrede søk (1)"
ActualResult (4xx)
🟢 AR-400 + 401 + 403 : URL inneholder ikke sensitive data, kun navn : https://af.tt.altinn.no/?loggedIn=true&allParties=true&sender=Skatteetaten&sender=digitaliseringsdirektoratet
🟡 AR-400 + 401 : Merknad fra test: Dette reduserer kvaliteten på søket. Hvis en org skulle justere på navnet så vil søket slutte å fungere. F.eks. org-nr er mer persistent i så måte. Og org-nr er ikke en personopplysning og derfor heller ikke sensitiv.
🟢 AR-402 : Når filter hentes opp er både URL og resultat likt som når filterkriterier ble valgt i TC-400
TestData (5xx)
TD-500 : Bruker = 26818999827 : Aktør = Alle virksomheter : Avsender = Skatteetaten
TD-501 : Etter TC-500 bytt Aktør = Henynsløs Parat Tiger AS
TD-502 : Henynsløs Parat Tiger AS har ingen meldinger fra Skatteetaten
ActualResult (5xx)
🟢 AR-500 : Egentlig kun et prep-steg for TC-500 : URL = https://af.tt.altinn.no/?loggedIn=true&allParties=true&sender=Skatteetaten
🟡 AR-501 + 502 : Filteret for sender = Skatteetaten beholdes selv om Skatteetaten ikke er avsender på dialoger for Henynsløs Parat Tiger AS
Diskusjon
Jeg har diskutert denne med Sean og her er det kommet til endriger etter at Aksept Kritere (kulepunkt 4) ble skrevet.
Endringen bygger på at tomme filter som ikke gir treff har vært skjult for bruker. Dette har hindret bruker i å "rydde opp selv". Derfor må filter som "plutselig" ikke gir treff fortsette å vises for bruker slik at bruker selv kan fjerne dem manuelt fra det samlede filteret.
TestRapport
Det er gjort noen observasjoner, disse er ulik grad avklart underveis slik at AF #1598 som Story kan ansses som levert.
🟡 AR-103 :
Tilbake i historikk (Alt + Pil venstre) sender bruker tilbake til siden før arbeidsflate ble åpnet. Å navigere tilbake i historikk fungerer ikke så lange det ikke finnes historikk å navigere i.
Konklusjon
Dagens eneste historikk er "sidehistorikk". Det finnes ikke konseptuelt noe "filterhistorikk".
Når det navnigeres vis de ulike menyelementene Utkast, Lagrede søk og Papirkurv så åpnes nye sider og det dannes sidehistorikk.
Det dannes altså sidehistorikk når man forlater "innboks", og da huskes gjeldende filter parametere som en del av side-URL som forlates.
Det er her muligheten for å "jukse litt" også åpner seg. For ved å velge innboks på nytt i menyen så kan man få inn innboks med ulike filtre i sidehistorikk (disse ser ut til å reloade litt dårlig når man går frem og tilbake, men med en ekstra refresh fungerer de)
- Med "Tilbake" og "Fremover" i sidehistorikk kan jeg veksle mellom disse to, men jeg må gjøre en ekstra reload for at de skal ta effekt
https://af.tt.altinn.no/?sender=Digitaliseringsdirektoratet
https://af.tt.altinn.no/?status=NEW
🟡 AR-400 + 401 :
Merknad fra test: Dette reduserer kvaliteten på søket. Hvis en org skulle justere på navnet så vil søket slutte å fungere. F.eks. org-nr er mer persistent i så måte. Og org-nr er ikke en personopplysning og derfor heller ikke sensitiv.
Konklusjon
Basert på akseptkritere kulepunkt 5 så er dette ønsket.
🟡 AR-501 + 502 :
Filteret for sender = Skatteetaten beholdes selv om Skatteetaten ikke er avsender på dialoger for Henynsløs Parat Tiger AS
Konklusjon
Her er akseptkritere kulepunkt 3 blitt "om ønsket" etter det ble skrevet og kulepunkt 4, der filter ikke skal fjernes, fremtvinger den observerte oppførsel.
Andre observasjoner
Det er gjort en parallell observasjon underveis i testen. Denne oppretter Sean en egen sak på (#1659).
Når man velger aktør "Alle virksomheter" får man i utgangspunktet denne URL
Hvis man så velger en konkret aktør etterpå så fosvinner ikke allParties=true fra URL
Bytter man til en tredje vil man bytte den spesifikk samtidig som man fortsatt drar rundt på allParties=True
Bytter man så til Alle Virksonheter så drar man også med seg den siste spesifikke videre
Det observeres en del rusk, men siden grunnfunksjonaliteten om at filter ivaretas i URL og kan lagres som bokmerker og ikke skades hverken om de benyttes som bokmerker eller lagrede søk gjør at som helhet på Story må det settes Test = Passed.