Project

General

Profile

Bug #1519

Fejl fra opensearch bør være mere forklarende

Added by Steen Larsen almost 5 years ago. Updated 18 days ago.

Status:
Reviewed
Priority:
High
Assignee:
Target version:
Estimated time:
URL med eksempel:
Kategorier:
Integration - Brønd - Søg, rankér filtrér sortér, Søgning - Søgeresultat efter søg - Brønd

Description

Problemstilling

Når man benytter søge- og filtreringsindekser vises periodiske fejlbeskeder med teksten "Invalid or unsupported use".

Fejlbeskeder der vises er generelt. ikke er oversat til dansk

Formål

Brugen af kombinatoriske søgninger skal ikke udløse fejlbeskeder og hvis de gør skal de være oversat til dansk.

Løsningsforslag

  1. Analysér hvorfor "Invalid or unsupported use" vises periodisk ved brug af kombinatoriske søgninger.
  2. Hvis fejlbeskeden vises ved en fejl så løs fejlen.
  3. Gør det muligt at oversætte fejlbeskeder.

Original beskrivelse

Når ddbcms-sitet giver 0-hit pga fejl af en eller anden slags fra opensearch bør fejlen være mere forklarende og beskrivende - det så man tydeligt i weekendens servicevindue hvor beskeden blot var "Internal problem"

Visning af disse fejl blev indført i #429 og findes i filen TingClientException.php
Det er ikke selve fejlen fra opensearch der vises, men istedet udvalgte og genkendelige fejl..

Da vi kun benytter dansk i ddbcms så kunne man selvfølgelig vælge at disse tekster skulle kunne oversættes.
Det ville være den enkle løsning.
(hvis vi var flersproglige så ville den engelske tekst netop ikke blive oversat og den vil stadig være mangelfuld)

Det er dem her der genkendes:

Unsupported index
Unsupported boolean modifier
Invalid or unsupported use
Internal problem

Lidt bonusinfo - fejltyperne fra den seneste måned (generaliseret) fra aakb:

10: Query syntax error at pos ...
13: Invalid or unsupported use of parentheses at pos ...
16: Unsupported index (...) at pos ...
46: Unsupported boolean modifier (...) at pos ...
Error: Cannot fetch profile: ...
Error: Unknown sort: ...
Internal problem: Cannot decode Solr re-search
Internal problem: Cannot decode Solr result
Internal problem: No answer from Solr

Som man kan se dækker "Internal problem" over flere forskellige fejltyper men det er vist alle midlertidige problemer i servicen.
Jeg tror ikke det pt. er nødvendigt at udvide listen af kendte fejl.

Invalid or unsupported use.jpg (143 KB) Invalid or unsupported use.jpg Christian Hundebøl Høj, 07/16/2020 11:12 AM
Søgeresultat.jpg (187 KB) Søgeresultat.jpg Christian Hundebøl Høj, 08/19/2020 09:39 AM

Related issues

Related to DDB CMS - Bug #4746: Søgning på navne med citationstegn fejlerClosed
Related to DDB CMS - Bug #4613: Kampagne PLUS : Sletning af modulet ding_campaign_plus_searchClosed
Related to DDB CMS - Bug #3488: Fejlmeddelelse "Invalid or unsupported use" vises efter loginClosed
Related to DDB CMS - Bug #3400: Søgning på forslag fra OpenSuggest giver 0-hit samt fejlmedd.: "Invalid or unsupported use"Closed
Has duplicate DDB CMS - Bug #3488: Fejlmeddelelse "Invalid or unsupported use" vises efter loginClosed
Has duplicate DDB CMS - Bug #4746: Søgning på navne med citationstegn fejlerClosed

History

#1 Updated by Rolf Madsen over 4 years ago

  • Status changed from New to Needs analysis
  • Assignee set to Steen Larsen
  • Target version set to DDB CMS - Analyse og prioritering udestår
  • Kategorier Integration - Brønd - Søg, rankér filtrér sortér, Søgning - Søgeresultat efter søg - Brønd added

Kan du bekræfte at fejlbeskederne er synlige for slutbrugere?

Foreslår du en yderligere detaljering og bedre forklaring af fejlmeddelelserne som Opensearch udleverer?

Hvilke oversættelser vil du foreslå af de eksisterende fejlmeddelelser?
NB. ingen af de nævnte tekster har oversættelsesfunktioner og kan dermed ikke pt. oversættes.

#2 Updated by Steen Larsen over 4 years ago

Ja, det er disse der vises til slutbrugeren:

  1. Unsupported index
  2. Unsupported boolean modifier
  3. Invalid or unsupported use
  4. Internal problem

For 1-3 har brugeren indtastet noget ugyldigt og for 4 er der - forhåbentlig et midlertidigt - problem med opensearch.
Og det er det jeg ønsker at fortælle brugeren.

Fejlene 1+3 kan fremprovokeres på denne måde:
dummy.index=test
Front: Unsupported index
syslog: Unsupported index (dummy.index) at pos 18

du()mmy.test=test
Front: Invalid or unsupported use
syslog: Invalid or unsupported use of parentheses at pos 4

Søgningen term.default="lucca" "
Front: Invalid or unsupported use
syslog: Invalid or unsupported use of parentheses at pos 28
Årsag skyldes at det er det her der sendes til opensearch: (term.default="lucca" and ")

Fejl 2 optræder ikke (mere) i sysloggen

Fejl 4 optræder ved servicevinduerne hos DBC

Dvs når systemet genkender fejlene skal der vises en anden tekst og dén tekst skal selvfølgelig kunne oversættes.
Den engelske tekst skal vel også give mening inden en evt. oversættelse?

#3 Updated by Rolf Madsen 6 months ago

  • Related to Bug #4746: Søgning på navne med citationstegn fejler added

#4 Updated by Rolf Madsen 6 months ago

  • Has duplicate Bug #3488: Fejlmeddelelse "Invalid or unsupported use" vises efter login added

#5 Updated by Rolf Madsen 6 months ago

  • Description updated (diff)
  • Target version changed from DDB CMS - Analyse og prioritering udestår to Release 33 - Bugfixes

#6 Updated by Rolf Madsen 6 months ago

  • Target version changed from Release 33 - Bugfixes to Release 32 - Bugfixes

#7 Updated by Rolf Madsen 6 months ago

  • Related to Bug #4613: Kampagne PLUS : Sletning af modulet ding_campaign_plus_search added

#8 Updated by Rolf Madsen 6 months ago

  • Related to Bug #3488: Fejlmeddelelse "Invalid or unsupported use" vises efter login added

#9 Updated by Rolf Madsen 6 months ago

  • Related to Bug #3400: Søgning på forslag fra OpenSuggest giver 0-hit samt fejlmedd.: "Invalid or unsupported use" added

#10 Updated by Rolf Madsen 6 months ago

Svar fra Erik i #4746#note-1

Open search returnerer:   <dc:creator xsi:type="oss:sort">Elliott, Missy &quot;Misdemeanor&quot;</dc:creator>

#11 Updated by Rolf Madsen 6 months ago

  • Has duplicate Bug #4746: Søgning på navne med citationstegn fejler added

#12 Updated by Rolf Madsen 6 months ago

  • Status changed from Needs analysis to Ready for development
  • Assignee changed from Steen Larsen to Christel Krabbenhøft
  • Priority changed from Normal to High

#13 Updated by Christian Hundebøl Høj 2 months ago

Sker der noget med løsning af det her issue?

Jeg er selv ved at blive skør at få beskeden "Invalid or unsupported use" igen og igen på koldingbib.dk, uden at have nogen anelse om, hvad jeg skal gøre for at fikse problemet, eller hvad problemet overhovedet er. Tidligere i Bug #3488 blev det antydet, at problemet kunne være fallbacksøgningen i serendipitetsmodulet, men det er jo blevet deaktiveret nu ifb. ny huskelisteservice.

Så sent som i dag så jeg fejlen ved at jeg åbnede en post (se vedhæftede billede).

#14 Updated by Rolf Madsen about 1 month ago

Prioriteringen er stadig sat til Release 32, så løsningen skulle gerne komme ud i løbet af efteråret.

#15 Updated by Ninna Rasmussen about 1 month ago

  • Assignee changed from Christel Krabbenhøft to Ninna Rasmussen

Sendes til Reload.

#16 Updated by Rolf Madsen about 1 month ago

  • Description updated (diff)

#17 Updated by Thomas Hansen about 1 month ago

@Christian Hundebøl Høj

Det her issue har ikke noget med dit problem at gøre. Dit issue er at der er noget af det kode der kører i værkvisningen der får konstrueret noget forkert kode. Det skal du oprette en et separat issue på.

#18 Updated by Rolf Madsen about 1 month ago

@Thomas

Forstår jeg dig korrekt at vi skal have dette issue delt op så følgende behandles separat:

  1. Fejlbeskeder skal kunne oversættes.
  2. "Invalid or unsupported use" skal ikke vises når man foretager kombinatoriske søgninger med søgeindekser.

#19 Updated by Thomas Hansen about 1 month ago

@rolf

Ja, egentligt, havde lige overset "Analysér hvorfor "Invalid or unsupported use" vises periodisk ved brug af kombinatoriske søgninger." i beskrivelsen.

Oversættelse af fejlbeskeder og "periodisk fejl i kombinatoriske søgninger" har ikke ret meget med hinanden at gøre.

Hvis jeg skal have nogensomhelst chance for at gøre noget ved det, så skal jeg have mere information om hvor det går galt. Jeg kan ligesom regne ud at problemet er at noget kode får konstrueret en søgning der er invalid, men hvis jeg ikke kan reproducere det.

At oversætte fejlene er ikke det store problem, og for dem der leverer en position kan man gøre det pænere ala

Forkert brug af parentes nær "()mmy.test=test".

Så det er mest hvad I vil have dem oversat til.

#20 Updated by Rolf Madsen about 1 month ago

Problemet med "Invalid or unsupported use" er at den lader til at være periodisk.

Jeg kan fx skrive term.type=dvd and term.subject="danmark" og få fejlen:

Kilde: https://bibliotek.kk.dk/search/ting/term.type%3Ddvd%20and%20term.subject%3D%22danmark%22?

Hvis jeg laver den samme søgning igen vises den ikke.

Prøv forskellige kombinationer er indekser så plejer det at komme ret hurtigt.

#21 Updated by Rolf Madsen about 1 month ago

Giver det overhovedet mening at de fejlbeskeder vises for brugerne?

Det kan jo reelt ikke bruge dem til noget som helst ...

#22 Updated by Steen Larsen about 1 month ago

Der er vel disse scenarier hvor fejl kan opstå:

  1. fra den konkrete indtastede søgning som giver fejl.
  2. fra yderligere videresøgninger der foretages af systemet og som konstrueres forkert baseret på det indtastede.
  3. fra forkert behandling af korrekt indtastet søgning

 

Pkt 1) er der nogle eksempler på i min tidligere note #1519#note-2

Pkt 2) må være det som Rolf og Christian mødes af. Hvis disse "bagved"-liggende søgninger caches kan det måske forklare at de ikke ses hver gang.

Pkt 3) findes måske ikke, men der er dog eksempler som giver forkerte søgeresultater ( "år>2020" vs "år > 2020") men disse er irrelevante i den her sag.

 

Fejl fra pkt 1) bør vises som beskrevet i sagen.

Fejl fra pkt 2) kan brugerne ganske rigtigt ikke bruge til noget og kunne skjules. Dog burde årsagen til fejlen vel undersøges så det kunne løses men det er en anden sag

Fejl fra pkt 3) kan i den her sammenhæng nok ikke skelnes fra 1)

#23 Updated by Rolf Madsen about 1 month ago

@Steen, har du fundet en måde at fremprovokere "Invalid or unsupported use" konsistent?

#24 Updated by Thomas Hansen about 1 month ago

@rolf

> Giver det overhovedet mening at de fejlbeskeder vises for brugerne?

For det første skal de jo have at vide at der er noget galt med søgningen. Bare at give dem "ingen resultater" hjælper dem jo mindre. Og så kan fejlbeskederne forbedres så de får en pointer til hvor i søgestrengen det går galt. Det er også en hjælp.

@steen

> Fejl fra pkt 2) kan brugerne ganske rigtigt ikke bruge til noget og kunne skjules. Dog burde årsagen til fejlen vel undersøges så det kunne løses men det er en anden sag

Ideelt set ja. Men det bliver sat helt nede i opensearch_execute() hvor det er svært at se hvor søgningen kommer fra, og hvis vi lader exception'en boble op, så skal vi håndtere det alle de steder den bliver kaldt.

#25 Updated by Thomas Hansen about 1 month ago

Jeg fiksede ligge debug logging: https://github.com/ding2/ting-client/pull/32

(ellers bliver det skisme op af bakke)

#26 Updated by Thomas Hansen about 1 month ago

@rolf

Jeg kan ikke reproducere i et frisk site. Kan jeg få et dump fra et site hvor det optræder?

#27 Updated by Steen Larsen about 1 month ago

@Rolf ja, jeg har flere eksempler i min note ovenfor, men prøv ti=x1(

Første gang man søger vises fejlen - 2. gang vises den to gange - hvilket kunne være fejlen fra videresøgningen som dukker op her, men som caches efterfølgende? Gentag med x2, x3 osv.

 

At vise fejlene uanset årsag (1+2) er nok bedst - så skal vi blot have lidt mere fokus på at få rettet videresøgningen hvis/når den fejler.

Jeg har ikke kigget i loggen om hvad videresøgningen faktisk gør (hvis det logges?), men hvis den kombinerer det man har indtastet (uanset hvad) med yderligere søgetermer så skal fejlen jo dukke op igen.

Man kunne måske undlade at lave videresøgningen hvis det indtastede ligner alt for meget en kompleks cql-søgning men der er sikkert flere veje at gå.

#28 Updated by Christian Hundebøl Høj about 1 month ago

Thomas Hansen skrev:

@Christian Hundebøl Høj

Det her issue har ikke noget med dit problem at gøre. Dit issue er at der er noget af det kode der kører i værkvisningen der får konstrueret noget forkert kode. Det skal du oprette en et separat issue på.

 

Hej Thomas,

Jeg er absolut ikke eksperten her, men det drejer sig ikke kun om at fejlmeddelelsen dukker op på værkvisningssiden. Her er et dukfrist eksempel fra 2 minutter siden, hvor beskeden dukker op på forsiden. (Jeg har godt nok her klikket fra en værkvisning, apropos det @Steen skriver omkring caching.)

 

#29 Updated by Thomas Hansen about 1 month ago

Christian Rrahn

Det jeg mente var at det var lige vel frisk af nogen at blande dit problem (der er noget kode der får lavet en invalid søgestreng) med generel oversættelser af fejlbeskeden. Du er jo ligeglad med hvor pæne fejlbeskederne er, de skal slet ikke være der.

@steen

Jeg kan se at `term.type=bog and term.subject="danmark"` trigger fejl på bibliotek.kk.dk, men jeg kan ikke få den på mit lokale miljø (som bare er en standard installation). Tyder på at der skal lidt mere komplicerede data til end hvad der er i test biblioteket.

#30 Updated by Steen Larsen about 1 month ago

Nærværende sag går jo på at lave oversættelserne og her burde en søgning som denne: ti=x( udløse en fejl.

Jeg ved ikke hvilket modul der laver videresøgningerne som jeg har kaldt dem, men det er vel også søgninger generelt udløst af andet vist indhold på hjemmesiden og ikke brugerens direkte søgning.

Fejlen udløst af dét modul -  som næsten alle åbenbart har vænnet sig til (siden der ikke er oprettet en sag for længe siden) - kræver jo en passende opsætning.
Din korrekte søgning på bibliotek.kk.dk udløser heller ikke fejlen hos os (aakb.dk) men andre søgninger ser ud til at gør det.
 

#31 Updated by Thomas Hansen about 1 month ago

Nå, men selvom jeg måtte hanke rundt med et gammelt dump af bibliotek.kk.dk (som brugte en brønd version der ikke længere eksisterer), og hacke `opensearch.client.inc` (https://opensearch.addi.dk/b3.5_5.2/ kan ikke lide de userDefinedBoosts som den gamle bib.kk.dk får lavet, "ikke lide" som i white-screen-of-death), så tror jeg at jeg har fundet synderen bag de periodiske fejl.

Ding_campain_plus_search laver en søgning hvor den wrapper den eksisterende i " og tilføjer sit eget. Hvilket giver parse error når der allerede er " i query'en. Har rettet det til at den wrapper den i parenteser som alle andre gør.

Fix: https://github.com/ding2/ding2/pull/1667

 

#32 Updated by Thomas Hansen about 1 month ago

> Nærværende sag går jo på at lave oversættelserne og her burde en søgning som denne: ti=x( udløse en fejl.

Ah, men punkt et i løsningsbeskrivelsen:

> Analysér hvorfor "Invalid or unsupported use" vises periodisk ved brug af kombinatoriske søgninger.

> som næsten alle åbenbart har vænnet sig til (siden der ikke er oprettet en sag for længe siden)

#4613 refererer netop til problemet, den er lukket som duplicate af den her. Og Christian er tydeligvis også generet af det.

 

#33 Updated by Steen Larsen about 1 month ago

det er jo også rigtigt... - så mangler vi jo blot anden del fra formålet ".... og hvis de gør skal de være oversat til dansk", dvs løsningsforslag pkt 3.

Jeg oprettede sagen for 4 år sagen - om årsagen dengang var campaign_plus ved jeg ikke, men det er jo også irrelevant nu.
Hvis fejlen dukker op igen efter rettelsen ved alm brug af hjemmesiden og det uden at man har indtastet en forkert cql-søgning, må vi jo indkredse modulet og løse fejlen.

#34 Updated by Thomas Hansen about 1 month ago

> det er jo også rigtigt... - så mangler vi jo blot anden del fra formålet

Jeg mangler bare hvad man vil have det oversat til, og om vi skal være fancy og klippe den problematiske del af query'en ud og lade være en del af fejl beskrivelsen?

 

#35 Updated by Steen Larsen about 1 month ago

Med de unødvendige parenteser som cql-søgningen traditionelt pakkes ind i, så mistes noget af den oprindelige fejlmeddelelse, så noget fancy skal vi nok ikke arbejde med her.

Eksempel: ti="lucca giver fejlen "10: Query syntax error at pos 44" ved direkte søgning, men "13: Invalid or unsupported use of parentheses at pos 48" når den pakkes ind med ().

Måske er der kun disse typer vi skal behandle - men der kunne måske godt være flere:

  1. Unsupported index
  2. Invalid or unsupported use of parentheses
  3. Internal problem

Men hvad de konkret skal oversættes til har jeg ikke bud på lige nu.

#36 Updated by Thomas Hansen about 1 month ago

> Eksempel: ti="lucca giver fejlen "10: Query syntax error at pos 44" ved direkte søgning, men "13: Invalid or unsupported use of parentheses at pos 48" når den pakkes ind med ().

Well, det betyder også at vi ikke kan differenciere imellem de forskellige fejl, fordi DDB CMSs modificering af queryen før den sendes til opensearch betyder at den kan melde en helt anden fejl end brugeren reelt har lavet.

Så vi ender med en generisk "Syntax error" fejl.

Hvilket bringer os ned på 2 beskeder?

 

#37 Updated by Steen Larsen about 1 month ago

Man kunne skelne forkert brug af et indeks fra en syntaksfejl men det er nok svært at forklare. Forkert indeks er søgninger som "test=lucca" som fejler fordi der ikke er noget indeks "test".

Så syntaksfejl og brøndfejl (Internal problem som beskrevet i sagsbeskrivelsen) er nok de 2 vi bør håndtere.

#38 Updated by Rolf Madsen about 1 month ago

Jeg antager at der er relativt få lånere der benytter indekser, men det er jo et problem hvis biblioteksmedarbejdere ikke bliver opmærksomme på fejl i søgestrenge de lægger til grund for navigationselementer der benyttes af mange lånere.

Er det ikke muligt at "fange" den oprindelige søgestreng inden der bliver sat parenteser om, så vi kan give en reel feedback?

Skal vi tage et Skypemøde så vi kan vende problemstillingerene mere direkte i stedet for at skrive frem og tilbage her over endnu flere dage?

#39 Updated by Thomas Hansen about 1 month ago

@rolf

> Er det ikke muligt at "fange" den oprindelige søgestreng inden der bliver sat parenteser om, så vi kan give en reel feedback?

Jo, men det hjælper ikke ret meget. Vi vil så ikke vide hvor i den streng problemet er, og fejlmeddelelsen kan være helt hen i skoven. F.eks.Steen eksempel med `term.default="lucca" "` vil den sige at problemet er med paranteser, men der er jo ingen paranteser i den originale streng.

Så kan vi sende original strengen til opensearch for at få den til at se om den er korrekt, men så laver du reelt set to søgninger per søgning. Det er du heller ikke interesseret i.

En mere anvendelig løsning ville være at den der hvor den fanger fejlen og printer den, istedet tager den originale streng, laver en søgning på den, og bruger dens fejlbesked. Men det kræver en del omskrivning for at sørge for at originalen er tilgængelig der, plus at vi så skal finde ud af hvad den gør hvis den originale streng ikke giver nogen fejl (for så er det et eller andet moduls modificering der er gået galt).

Sidstnævnte er ikke just noget quickfix, og få det lavet om til to oversætbare fejlbeskeder er stadig et fornuftigt mellemfix, selv hvis man går efter den anden på sigt.

#40 Updated by Steen Larsen about 1 month ago

De ekstra parenteser som tilføjes i CQL-udtrykket er faktisk ikke nødvendige, så de kunne jo fjernes.
"((A or B)) and C" er det samme som "A or B and C" når det er CQL - det er en del af standarden er det er sådan.

 

Jeg kan ikke deltage i evt skype de næste par dage.

 

 

#41 Updated by Simon Holt about 1 month ago

Så vidt jeg husker er der noget kode, der altid sætter parentes omkring brugerens søgning. Samtidig er der flere steder, hvor noget kode til CQL tilføjes til enden med AND samt parentes om den eksiterende query og parentes om det der tilføjes. F.eks. når holdingsitem.agency filter tilføjes. Derfor får vi nogle gange det "((A or B)) and C" som Steen nævner.

https://github.com/ding2/ting-client/blob/master/lib/request/TingClientSearchRequest.php#L53

https://github.com/ding2/ding2/blob/master/modules/ting_field_search/ting_field_search.module#L210

Sidstnævnte er muligvis nødvendig, men den parentes der sættes om brugerens søgning bør kunne udelades, hvis den skaber problemer?

@Steen det er muligvis slet ikke nødvendigt at sætte parentes om den eksisterende query når vi tilføjer noget til enden?

#42 Updated by Thomas Hansen 30 days ago

Well, den simple version:

https://github.com/ding2/ding2/pull/1668 og https://github.com/ding2/ting-client/pull/33

og glem ikke https://github.com/ding2/ding2/pull/1667

@Steen @Simon

Well, hvis I kan stå inde for at der ikke er nogen moduler der laver mere kompleks modifikation end at appende " AND something", og at det ikke vil have andre konsekvenser at droppe paranteserne, så kan vi da godt arbedje med det..

Men jeg er ikke sikker på at det vil forbedre så meget den her:

term.subject="danmark" " and term-type="dvd"

giver mig:

16: Unsupported index (.\"danmark\") at pos 44

hvilket jo ikke er så retvisende.

 

#43 Updated by Thomas Hansen 30 days ago

  • Status changed from Ready for development to Needs code review

#44 Updated by Gitte Barlach 30 days ago

  • Assignee changed from Ninna Rasmussen to Jørgen Nielsen

#45 Updated by Rolf Madsen 29 days ago

I dit eksempel har du et citationstegn for meget i midten mellem danmark" og and:

term.subject="danmark" " and term-type="dvd"

Den søgning giver:

16: Unsupported index (."danmark") at pos 44

Hvis jeg fjerner citationstegnet får jeg den, antager jeg, mere korrekte fejlbesked:

16: Unsupported index (.term-type) at pos 42

#46 Updated by Thomas Hansen 29 days ago

@rolf

Det var det der var min pointe. Hvis vi lader somom brugeren har skrevet den (invalide) streng:

term.subject="danmark" "

Og DDB CMS moduler så tilføjer flere conditions med "and" (og uden parenteser som det gør nu), her representeret med:

and term-type="dvd"

Så får jeg ikke at vide at problemet er at jeg har en " for meget med, og vi er tilbage til misvisende fejlbeskeder.

 

#47 Updated by Rolf Madsen 29 days ago

Aah ... my bad!

#48 Updated by Thomas Hansen 29 days ago


Altså, den eneste måde jeg kan se at man kan få en retvisende fejlbesked er ved at sende brugerens originale søgning til brønden og bede om 0 resultater, hvis den kommer med en fejl, så skulle den passe.

Men ville være smart kun at gøre det når 1. den modificerede søgning fejlede og 2. det er brugerens søgning, og ikke af div. afledte søgninger fra div. moduler. Men det ville lige kræve lidt flytten rundt på sager.

#49 Updated by Rolf Madsen 26 days ago

humn ...

Jeg hælder til at vi ikke gør mere ved det jeg antager er en edge case.

Det problem vi oftest er stødt på og som er mest generende er  "Invalid or unsupported use" så hvis vi har fundet løsningen på den, mener jeg godt vi kan leve med de øvrige fejlbeskeder til vi laver skiftet til Drupal 9 med NEXT projektet. 

#50 Updated by Thomas Hansen 26 days ago

Altså, det der ligger i de tre PRs er:

Fiks de der random fejl forårsaget af campain modulet.

Konsolider alle fejl ned til to "Syntax error" og "Internal error" fejlbeskeder der kan oversættes.

Det syntes jeg godt vi kan leve med til D9.

#51 Updated by Rolf Madsen 26 days ago

Så skal jeg bare lige have bøjet i neon om "Invalid or unsupported use" som fremprovokeres af fx  term.type=dvd and term.subject="danmark" er dække af nogen af de tre PRs?

#52 Updated by Thomas Hansen 26 days ago

Ja, det er https://github.com/ding2/ding2/pull/1667 der fikser det så campain ikke får konstrueret fejlagtige søgninger selvom brugerens søgning er korrekt.

Hvis brugeren har fået lavet en invalid søgning, så vil den sikkert stadig melde fejl. Men de to andre vil gøre fejl beskeden mere menneskevenlig, og som en ekstra lille bonus vil den kun vise hver fejlbesked en gang, så hvis brugeren har lavet en søgning som resulterer i "syntax error", og campaign så laver en ny søgning som også resulterer i syntax error, så vil der kun stå den oversatte version af syntax error en gang.

 

#53 Updated by Rolf Madsen 26 days ago

Perfekt, og tak for opklaringen!

#54 Updated by Jørgen Nielsen 18 days ago

  • Status changed from Needs code review to Reviewed
  • Assignee changed from Jørgen Nielsen to Gitte Barlach

reviewet og godkendt

Also available in: Atom PDF