Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • D deichman
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 16
    • Issues 16
    • List
    • Boards
    • Service Desk
    • Milestones
  • Jira
    • Jira
  • Merge requests 3
    • Merge requests 3
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • digibib
  • deichman
  • Issues
  • #126

Closed
Open
Created Apr 12, 2020 by Martin Christensen@martin

Mere struktur på det nye filtering parameter til pluklister (Vigtig)

Petter har lavet en ny struktur for hvordan vi skal laver filtrerne fremover, dette er lavet for at undgå at vi skal have flere strategier for hvordan vi laver filtre (altså "bjor" vs. ikke "bjor").

Den gamle måde for på hvordan vi lavet filter endtil nu er.

Hvis materialet er på filialen "bjor" bruger vi "pickLocation" indeks (0 indekseret)

index 2 => floor
index 3 => section
index 4 => collection
index 5 => subcollection

Hvis materialet ikke er på filialen "bjor"

Ccode    => department
Category => location

Så vi har endtil nu arbejdet med 6 forskellige filtre (her har vi ikke tag "findes kun her" med).

Den nye måde vi får filtrerings værdier på er fra en parameter "filtering" som er et array af strenge.

Her er et par eksempler.

fsme
"filtering": [
                        "Barn",
                        "Bok",
                        "Fag",
                        "Eventyr"
                    ],

bjor
"filtering": [
                        "pub",
                        "2",
                        "barn",
                        "fakta",
                        "samfunn"
                    ],

For at undgå at skulle bruge 2 strategier for filtering fremover skal vi udvide størrelse af "filtering" og definere en mapping fra index til filter. Denne mapping er den som bestemmer hvad for et filter en værdi i array er og det bestemmer den human readable værdien i UI'et i app'en. Det er nødvendig med sådan en ændring for at vi kan slippe for 2 strategier, fx. har "Bok" fra fsme samme index som "2" fra bjor og "2" er jo en etage, hvilket jeg går ud fra "Bok" ikke er.

Et eksemple på en mapping kunne se således ud (kom endelige med et alternativ):

0 => Det nye filter som vi ikke bruger lige nu, den har værdien "pub" ovenfor.
1 => floor
2 => department
3 => section
4 => location
5 => collection
6 => subcollection

Denne mapping vil betyde at værdierne at "filtering" overfor kunne se ud på følgende måde.

fsme:
"filtering": [
                        "",
                        "",
                        "Barn",
                        "",
                        "Bok",
                        "Fag",
                        "Eventyr"
                    ],

bjor:
"filtering": [
                        "pub",
                        "2",
                        "",
                        "barn",
                        "",
                        "fakta",
                        "samfunn"
                    ],

Med denne ændring kan vi impl. vi nye filter færdig.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking