Project

General

Profile

Bug #3905

Cashingstrategi og performance (forsat fra #2223)

Added by Gitte Barlach 9 months ago. Updated 6 months ago.

Status:
Resolved (tag version)
Priority:
Urgent
Assignee:
Estimated time:
URL med eksempel:
Kategorier:
Driftsvedligehold - Refaktorering (Opdatering af kodebasen)

Description

(forsat fra #2223, den del der angår performance, herunder indspark fra Randers)

Skærmbillede 2018-12-03 11.34.46.png (274 KB) Skærmbillede 2018-12-03 11.34.46.png Der vises ingen beholdningsoplysninger Gitte Barlach, 12/03/2018 11:35 AM
Skærmbillede 2018-12-03 11.57.06.png (11 KB) Skærmbillede 2018-12-03 11.57.06.png Min kontoknappen samt genvejsmenu+ en bliver ikke indlæst Gitte Barlach, 12/03/2018 11:57 AM
Skærmbillede 2018-12-03 11.58.41.png (105 KB) Skærmbillede 2018-12-03 11.58.41.png Sider under /user giver fejl Gitte Barlach, 12/03/2018 11:59 AM
Skærmbillede 2018-12-10 18.41.02.png (42.6 KB) Skærmbillede 2018-12-10 18.41.02.png Gitte Barlach, 12/10/2018 06:58 PM
Skærmbillede 2018-12-10 18.44.45.png (147 KB) Skærmbillede 2018-12-10 18.44.45.png Gitte Barlach, 12/10/2018 06:58 PM
Skærmbillede 2018-12-10 18.39.06.png (79.9 KB) Skærmbillede 2018-12-10 18.39.06.png under forsøg på et gemme mine ændringer i brugerprofilen smider sitet (upgrade-fbs) pludselig denne fejl Gitte Barlach, 12/10/2018 06:59 PM

Related issues

Has duplicate DDB CMS - Bug #3970: Reserverknapperne vises med forsinkelseClosed

History

#1 Updated by Rolf Madsen 9 months ago

  • Priority changed from High to Urgent

#2 Updated by Rolf Madsen 9 months ago

Jeg mener dette issue skal løses og udrulles hurtigst muligt ud fra en antagelse om at performance er væsentligt forværret med udrulningen af #2223.

#3 Updated by Rolf Madsen 9 months ago

  • Target version changed from Release 31 - Adgangsplatform og LUG to Release 30 - BPI, Kampagneplus og Sektioner - (Reload)

#4 Updated by Gitte Barlach 8 months ago

Sagen her indeholder 2 aspekter:

(som jeg lige gentager her, selvom de også fremgår af #2223)

a) Ny cashing introduceret i rel. 29-2  (7.x-4.5.0) via #2223 øger svartiderne og giver dårlig performance
Indspark fra Àrni: "Derfor har jeg udvidet cachen til at cache alle objekterne og tjekke om de er i cachen for vi prøver at hente dem fra brønden. De får søgningen ned til 2 - 2.5 sekunder som er acceptabelt."
Spm fra Gitte: Det lyder interessant. Kan vi komme til at se din løsning ? hvor ligger koden henne?
Svar fra Árni:
 

Her er vores kode:

# This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- a/opensearch.client
+++ b/opensearch.client
@@ -366,6 +366,7 @@
     return $opensearch_static_fast[$cid];
   }
 
+
   // Check the database/memcached cache for the request also check that the
   // cache data has not expired before using it.
   $cache = cache_get($cid, 'cache_opensearch');
@@ -375,10 +376,27 @@
     // Update the static cache with the database cache content to speed up the
     // next request for the same data.
     $opensearch_static_fast[$cid] = $data;
-
     return $data;
   }
 
+  // Check if the individual objects are cached. If one is missing we complete
+  // the request to the well.
+  if ($request instanceof TingClientObjectRequest) {
+    $allfound = true;
+    $objects = array();
+    foreach ($request->getObjectIds() as $id) {
+      if (array_key_exists($id, $opensearch_static_fast)) {
+        $objects[$id] = $opensearch_static_fast[$id][$id];
+      } else {
+        $allfound = false;
+        break;
+      }
+    }
+    if ($allfound) {
+      return $objects;
+    }
+  }
+
   try {
     timer_start('ting');
     $res = _opensearch_get_client()->execute($request);
@@ -501,8 +519,16 @@
     $object_response = array();
     $object_response[$object->id] = clone $object;
     _opensearch_cache_insert($object_request, $object_response, $opensearch_static_fast);
+
+    // When we use getobjects to load multiple objects in one request we don't 
+    // hit the cache therefor each object is added here.
+    foreach ($collection->objects as $object) {
+      $object_response = array();
+      $object_response[$object->id] = clone $object;
+      $opensearch_static_fast[$object->id] = $object_response;
   }
 }
+}
 
 /**
  * Insert search response based on request.

Vi er midt i at få en ny hjemmeside op og køre så den er ikke på github endnu.


b) SAL introduceret i rel. 28 (7.x-4.3.0) øger svartiderne og giver dårlig performance
(dvs. sammenligningsgrundlaget er reelt set 4.2.1 da det er releasen før SAL)
Indspark fra Árni: "Det bagvedliggende problem er at søgeabstraktionslaget har indført fejl i koden som går voldsomt ud over performance."
Spm. fra Gitte: kan du beskrive de omtalte fejl helt konkret ?
Svar fra Árni: 

Det grundlæggende problem er siden bliver ved med at hente de samme data fra brønden igen og igen. Alle de nødvendige data i søgeresultatet bliver returneret fra brønden i det første kald til Opensearch alligevel prøver hjemmesiden at hente de samme data optil 4 gange per post som fører til 20 - 30 kald til Opensearch.

Det første kald sker allerede som en del af søgningen. I metoden opensearch_do_search bliver følgende metode kaldet efter at søgningen er gennemført:

$search_result->collections = entity_load('ting_collection', array(), array('ding_entity_id' => $ids)); linje 230 opensearch.client.inc

Det medfører at man laver et nyt kald til brønden for at hente alle værkerne som allerede er hentet i det første kald engang til. (Det her bliver løst af cachelaget så requesten rammer cachen i stedet).

Derefter er der 3 forskellige metoder som medfører et kald til brønden efter de poster som bliver behandlet i metoden:

ting_covers_get linje 134 i ting.covers.module

getPrimary_object() i linje 523 i ting.entities.inc

getOnlineUrl() i linje 217 i OpensearchTingObject.php //metoden kalder getRelations som loader en masse objecter.

 

Alle disse kald efter objekter bliver til 20 - 30 kald til brønden. Cachelaget fanger nogen af dem men det bliver stadigvæk til en del kald til brønden efter poster.

Det her var ikke et problem for søgeabstraktlaget kom til. Det kan vi se at sider som vejlebib.dk som stadigvæk kører på ældre kode har en fin performance.

Jeg har kun set på overflødige kald i forbindelse med søgning og ikke kigget på det i andre sammenhæng.

Men det grundlæggende problem er der bliver lavet et kald til brønden i en situation hvor de nødvendige data allerede er tilstede. Og det er også lidt af en code smell at hele håndteringen af søgninger og poster er så kompliceret som det er tilfældet. Det gør at der nemt opstår den her type fejl. 

#5 Updated by Kasper Garnæs 8 months ago

  • Status changed from Ready for development to Development

Jeg har set på problemstilling B først.

 

det grundlæggende problem er der bliver lavet et kald til brønden i en situation hvor de nødvendige data allerede er tilstede.

Det er korrekt, at der mange steder i kildekoden er funktioner, der kan medføre kald til Opensearch, hvis nødvendig data ikke allerede er tilstede i cachen. Dette skyldes dog at funktionerne kan blive kaldt i sammenhænge hvor dataen mangler, og så kan et kald til OpenSearch (eller cachen) være nødvendigt.

Eksempelvis bliver ting_covers_get() kaldt fra page callbacks, hvor den eneste data der findes i den kontekst er id'erne på de materialer der er angivet i URL'erne. Hvis systemet skal kunne sende en *hel* Ting entity videre til de moduler der skal loade covers'ne, så skal data om entitieten hentes fra OpenSearch /cache først). ting_covers_get() kunne refaktoreres til at tage et eller flere Ting entities som argument. Så ville det være den omkringliggende kode som var ansvarlig for at sørge for at data var til rådighed om det så er fra cache eller ej. Forslag til pull requests der refaktorer dette er velkomne.

Derudover: ting_covers_get bliver kaldt asynkront som en del af renderingen af et søgeresultat i Core pt. Cache eller ej så påvirker det altså ikke direkte hvor hurtigt brugeren kan se listen.

 

Det her var ikke et problem for søgeabstraktlaget kom til.

Som jeg ser det relaterer ingen af de nævnte eksempler sig til introduktionen af søgeabstraktionslaget (SAL).

1. opensearch_do_search() /  man laver et nyt kald til brønden for at hente alle værkerne som allerede er hentet i det første kald engang til.

Denne opførsel er præcis den samme i ting_do_search() fra 7.x-4.2.1 (sidste release før SAL) som i opensearch_do_search() fra 7.x-4.3.0 (første release med SAL).

2. ting_covers_get()

Der er ikke blevet ændret i kildekoden til ting_covers_module som en del af SAL.

3. getPrimary_object()

Metoden kalder implicit getEntities pga. brug af PHPs magiske metoder i DingEntityBase. getEntities loader i sig selv Ting entites, der kan medføre kald til Opensearch, hvis nødvendig data ikke allerede er tilstede i cachen. Situationen er dog præcis den samme i 7.x-4.2.1 før SAL.

4. getOnlineUrl()

Som ved getPrimary_object() indeholder implementationen af getOnline_url() i 7.x-4.2.1 loading af Ting entities.

 

Når det ovenstående er sagt så skal jeg samtidig også sige at jeg i min undersøgelse af situationen har jeg indtil videre fundet én fejl i forbindelse med introduktionen af SAL. I koden som renderer et felt der viser om et materiale er online eller ej, så har SAL medført risiko for unødvendige kald til OpenSearch. Det medfører at systemet ikke benytter den data der allerede findes i cachen.

Følgende PR addresserer denne fejl: https://github.com/ding2/ding2/pull/1269

Hvis rettelsen indføres i release 4.3.x og 4.4.0 så peger mine undersøgelser på at performance ift. søgning vil være som på 7.x-4.2.1, dvs. én søgning, ét request til OpenSearch (se nærmere i PR'et).

#2223 har medført en opdateret cachemodel som i mit testscenarie medfører et ekstra kald til OpenSearch. Min undersøgelse peger på at den situation ville kunne håndteres med en tilgang á la den, Arni foreslår i pkt. A. Den ser jeg nærmere på herefter. Derfor er dette issue heller ikke sat til review endnu.

#6 Updated by Jesper Kristensen 8 months ago

Jeg har tilladt mig at review PR'er med isOnline fixet (som jeg kan godkende) vel vidende at der kan komme flere PR's på dette issue.

#7 Updated by Kasper Garnæs 8 months ago

  • Status changed from Development to Needs code review
  • Assignee changed from Kasper Garnæs to Gitte Barlach

Jeg har gennemgået problemstilling A. Baseret på det løsningsforslag Arní er kommet med har jeg opdateret cachehåndteringen, så vi så prøver at undgå requests efter objekter som vi allerede har hentet ifm. søgning eller hentning af andre objekter. Hvis ændringen medtages, så er en søgning med en tom cache reduceret til ét request til OpenSearch og dermed være på niveau med release 4.2.1.

https://github.com/ding2/ding2/pull/1271

 

Jeg skal dog samtidig sige at disse ændringer kun øger kompleksiteten af vores cachestrategi. Der er en risiko for at vi ikke er nået meget længere ift. den indsats som er blevet lagt i #2223. Jeg ved dog ikke om den problemstilling, som lå til baggrund for #2223, er blevet løst i arbejdet.

#8 Updated by Gitte Barlach 8 months ago

  • Assignee changed from Gitte Barlach to Jesper Kristensen

#9 Updated by Jesper Kristensen 8 months ago

  • Status changed from Needs code review to Reviewed
  • Assignee changed from Jesper Kristensen to Gitte Barlach

Rigtig gode rettelse og forbedringer til cache.

Reviewed og afventer release

#10 Updated by Kasper Garnæs 8 months ago

  • Status changed from Reviewed to Technical test

Jeg har tilladt mig at merge denne da hastighedsforbedringerne alene i vores continuous integration proces er værd at få med.

#11 Updated by Gitte Barlach 8 months ago

Jeg har testet rettelserne (3905-7.x-4.5.0.patch) på stg.aakb.dk, og har indtil videre kun fundet en fejl ift. at reserver-knappen ikke vises på materialer i karruseller på forsiden; den fejl er i øvrigt giftig at sige noget om da vi har #3944

Meserverknappen ankommer i alle andre tilfælde med en anelse forsinkelse. Dette gælder både værk- og materialevisning, samt de andre karruseller på siden /public-lists samt "Biblioteket foreslår materialer til dig" nedenfor materialevisningen, samt nyheder med vedhæftede materialer. Denne forsinkelse synes jeg er blevet mere mærkbar. Til gengæld er søgning og visning generelt væsentligt hurtigere.

#12 Updated by Kasper Garnæs 8 months ago

  • Status changed from Technical test to Needs code review
  • Assignee changed from Gitte Barlach to Jesper Kristensen


Jesper Kristensen har bemærket at den foreslåede ændring medfører en warning i PHPs logs. Dette PR retter dette: https://github.com/ding2/ding2/pull/1280.

#13 Updated by Jesper Kristensen 8 months ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Jesper Kristensen to Kasper Garnæs

Det var lige en lille ting!

#14 Updated by Jesper Kristensen 8 months ago

  • Status changed from Reviewed - Needs info/rework to Reviewed
  • Assignee changed from Kasper Garnæs to Gitte Barlach

Reviewed og afventer release

#15 Updated by Kasper Garnæs 8 months ago

  • Status changed from Reviewed to Technical test

Merged.

#16 Updated by Gitte Barlach 8 months ago

  • Status changed from Technical test to Resolved (tag version)

Godkendt jvf code review. 

#17 Updated by Gitte Barlach 8 months ago

Under test af 4.6.0-rc3 oplever vi nogle graverende fejl på de interne test-sites:

a) Fejl: Beholdningsoplysninger mangler på materialevisningen. Se screenshot. 

Site: https://upgrade-fbs.ddbcms.dk/ og https://vanilla-fbs.ddbcms.dk/

 

b) Fejl: Min konto og genvejsmenu indlæses ikke. Se screenshot. 

Site: https://upgrade-fbs.ddbcms.dk/

 

c) Fejl: Sider under /user giver TypeError: Argument 1 passed to TingClientObjectRequest::setObjectIds() must be of the type array, null given, called in /var/aegir/platforms/ddb460rc3/profiles/ding2/modules/opensearch/opensearch.client.inc on line 406 i TingClientObjectRequest->setObjectIds() (linje 88 af /var/aegir/platforms/ddb460rc3/profiles/ding2/modules/opensearch/lib/ting-client/lib/request/TingClientObjectRequest.php).

Site: https://vanilla-fbs.ddbcms.dk/
 

d) Fejl: Man kan ikke filtrere via facetterne. Når man vælger en facet, dvs. klikker i den lille boks, sker der ingenting efterfølgende. 
Site: upgrade-fbs

#18 Updated by Gitte Barlach 8 months ago

  • Status changed from Resolved (tag version) to Reviewed - Needs info/rework
  • Assignee changed from Gitte Barlach to Kasper Garnæs

#19 Updated by Simon Holt 8 months ago

Tog lige et kig på den, for tænkte nok det var relateret til de ændringer jeg lavede i #3828. Og ganske rigtigt.

i #3828 går vi fra at bruge et søgerequest til et bruge et object request, når det korrekte namespace skal findes for lokale id'er. Dette for at undgå, at de returnerede værker fra opensearch, med kun et enkelt objekt, caches som ukomplette værker og dermed "skjuler" andre materialetyper fra brugeren. (mener også at det er mere rigtigt at bruge et getObject request, men det var ikke muligt, da funktionen først blev implementeret).

For at vi kan hente objekter baseret på lokale Id'er, er TingObjectRequest blevet udvidet, så man kan sætte lokale id'et via setLocalIds() i stedet for at burge setObjectsIds(), der kun virker med brønd PID'er. Se her for mere info: https://github.com/ding2/ting-client/pull/25

Men det nye cachingkode med special håndtering af objekter, opererer udelukkende med PID og bruger altså getObjectIds(). I de tilfælde hvor vi prøver at hente objekter baseret på lokale id'er, er der ikke noget i getObjectIds() og det resulterer i følgende række af fejl og internal server error:

Fejlmeddelelse

  • Warning: array_combine() expects parameter 1 to be array, null given i opensearch_execute() (linje 386 af /var/www/ddbcms.test/profiles/ding2/modules/opensearch/opensearch.client.inc).
  • Warning: array_map(): Argument #2 should be an array i opensearch_execute() (linje 401 af /var/www/ddbcms.test/profiles/ding2/modules/opensearch/opensearch.client.inc).
  • Warning: array_filter() expects parameter 1 to be array, null given i opensearch_execute() (linje 402 af /var/www/ddbcms.test/profiles/ding2/modules/opensearch/opensearch.client.inc).
  • Warning: array_diff_key(): Argument #1 is not an array i opensearch_execute() (linje 406 af /var/www/ddbcms.test/profiles/ding2/modules/opensearch/opensearch.client.inc).
  • Warning: array_keys() expects parameter 1 to be array, null given i opensearch_execute() (linje 407 af /var/www/ddbcms.test/profiles/ding2/modules/opensearch/opensearch.client.inc).
  • TypeError: Argument 1 passed to TingClientObjectRequest::setObjectIds() must be of the type array, null given, called in /var/www/ddbcms.test/profiles/ding2/modules/opensearch/opensearch.client.inc on line 407 i TingClientObjectRequest->setObjectIds() (linje 88 af /var/www/ddbcms.test/profiles/ding2/modules/opensearch/lib/ting-client/lib/request/TingClientObjectRequest.php

Mulige løsninger

Ved ikke hvordan det lige er bedst at gribe det an. Enten skal TingClientObjectRequest laves om, så det med at den arbejder med forskellige identifiers bag ved abstrakteres væk. Eller også skal cachingkoden gøres endnu mere kompleks og tage højde for både pid og lokale id'er.

Måske kan TingClientObjecRequest udvides med en metode getIdentifiers(), der returnerer de korrekte id-array?

#20 Updated by Kasper Garnæs 8 months ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from Kasper Garnæs to Gitte Barlach

Simon: Jeg er enig i din analyse. Jeg er til en anden ændring, som tager højde for caching af både objekt id'er (pid'er) og lokale id'er (Faust). getIdentifiers() vil ikke være tilstrækkelig da man derudfra ikke ved hvilken slags identifier der er tale om og derfor ikke kan lave tilsvarende cache entries.

PR: https://github.com/ding2/ding2/pull/1284

#21 Updated by Gitte Barlach 8 months ago

  • Assignee changed from Gitte Barlach to Jørgen Nielsen

#22 Updated by Jesper Kristensen 8 months ago

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

Det er godt nok ved at blive noget komplex igen den cache.

 

Review og afventer release.

#23 Updated by Kasper Garnæs 8 months ago

  • Status changed from Reviewed to Technical test

Merged.

#24 Updated by Gitte Barlach 7 months ago

Testet på upgrade-fbs med 4.6.0-rc4
 

a) Fejl: Beholdningsoplysninger mangler på materialevisningen.
Ikke løst 100%
a1) når jeg søger et materiale frem, går på posten via værkvisningen, ja så virker det og der vises beholdning
a2) klikker jeg på et materiale i en karrusel (læs mere-knappen), ja så siger den "Henter beholdningsoplysninger". Efter ca. 60 sekunders ventetid giver jeg op; dette sker i flere tilfælde. Det hænder dog også at der er en titel eller to hvor jeg får vist beholdning.

b) Fejl: Min konto og genvejsmenu indlæses ikke.
Jeg kan nu logge ind og se min konto og genvejsmenu. LØST

c) Fejl: Sider under /user giver TypeError: Argument 1 passed to TingClientObjectRequest::setObjectIds() must be of the type array, null given, called in /var/aegir/platforms/ddb460rc3/profiles/ding2/modules/opensearch/opensearch.client.inc on line 406 i TingClientObjectRequest->setObjectIds() (linje 88 af /var/aegir/platforms/ddb460rc3/profiles/ding2/modules/opensearch/lib/ting-client/lib/request/TingClientObjectRequest.php). LØST
 

d) Fejl: Man kan ikke filtrere via facetterne. IKKE LØST. Når man vælger en facet, dvs. klikker i den lille boks, sker der ingenting efterfølgende. 
denne fejl eksisterer stadig. Denne fejl er også indrapporteret i #3603

e) NY fejl: når jeg skriver et søgeord og klikker på søg, får jeg godt nok et søgeresultat men knapperne i headeren bliver aldrig indlæst. Dette gælder uanset om jeg er anonym eller logget ind. Denne fejl er også indrapporteret i #3603

f) NY fejl: redigering af brugerprofil giver fejl
f1) når jeg redigerer min brugerprofil og gemmer kan jeg fx. ikke gemme en rettelse af mit tlf.nummer uden at skulle ændre min pinkode. 
f2) den nægter også at gemme med en gammel ferieperiode. Det var ellers løst i forrige release..

g) NY fejl: under forsøg på et gemme mine ændringer i brugerprofilen smider sitet (upgrade-fbs) pludselig en fejl - se vedlagte  skærmdump.

 

#25 Updated by Kasper Garnæs 7 months ago

  • Status changed from Reviewed - Needs info/rework to Technical test

a) Dette issue bliver som jeg ser det håndteret i #3970

b-e) Andre/løste issues

f) Dette issue har jeg videreført i #3043, hvor det stammer fra inkl. PR.

g) Dette issue har jeg videreført i #1261, hvor det stammer fra inkl. PR.

#26 Updated by Kasper Garnæs 7 months ago

  • Assignee changed from Kasper Garnæs to Gitte Barlach

#27 Updated by Simon Holt 7 months ago

Vi skal have kigget på denne igen. Det viser sig, at der stadig er nogle problemer med at hente objekter baseret på lokal ID/faust. Opdagede det ifb. med https://platform.dandigbib.org/issues/3739.

Jeg prøver lige at gennemgå hvad der sker med udgangspunkt i følgende fausts: 54940254 og 54953259.

opensearch_get_objects([54940254, 54953259], TRUE);

Dette resultere i føglende $uncached_ids array i https://github.com/ding2/ding2/blob/master/modules/opensearch/opensearch.client.inc#L419:

$uncached_ids[0] = (bool) 0
$uncached_ids[1] = (bool) 0

Det medfører at følgende TingClientObjectRequest executes:

$request = TingClientObjectRequest[14]
    $request->agency = (string) 763000
    $request->allRelations = (bool) 1
    $request->format = <null>
    $request->id = <null>
    $request->localIds = array[2]
        $request->localIds[0] = (string) 54940254
        $request->localIds[1] = (string) 54953259
    $request->relationData = (string) full
    $request->identifiers = array[2]
        $request->identifiers[0] = (int) 0
        $request->identifiers[1] = (int) 1

Hvilket giver følgende SOAP-request:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://oss.dbc.dk/ns/opensearch">
  <SOAP-ENV:Body>
    <ns1:getObjectRequest>
      <ns1:agency>763000</ns1:agency>
      <ns1:profile>opac</ns1:profile>
      <ns1:identifier>0</ns1:identifier>
      <ns1:identifier>1</ns1:identifier>
      <ns1:objectFormat>dkabm</ns1:objectFormat>
    </ns1:getObjectRequest>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Som konsekvens af dette får alle faust standard 870970-basis namespace tildelt, når vi oversætter faust, da requestet selvfølgelig fejler.

En anden uheldig konsekvens er at dette request tilsyneladende tager MEGET lang tid for opensearch at tygge igennem og nogle gange timer den faktisk helt ud.

Jeg kunne godt selv prøve at fikse det, men ville lige poste det her først, så Kasper lige kunne få øjne på det først.

#28 Updated by Gitte Barlach 6 months ago

  • Status changed from Technical test to Reviewed - Needs info/rework
  • Assignee changed from Gitte Barlach to Kasper Garnæs

Hej Kasper 

Har du nogen kommentrer til Simons analyse?

#29 Updated by Jesper Kristensen 6 months ago

  • Status changed from Reviewed - Needs info/rework to Needs code review

Jeg har lavet en meget lille ændring der ser ud til at fix det...

PR: https://github.com/ding2/ding2/pull/1318

@simon kan du bekæfte at dette skulle være nok til at fix det?

#30 Updated by Rolf Madsen 6 months ago

  • Has duplicate Bug #3970: Reserverknapperne vises med forsinkelse added

#31 Updated by Simon Holt 6 months ago

@Jesper Det ser ud til at være det rigtige du har fat i der. Har lige testet din rettelse og det ser ud til at fikse det. Det hele kører også meget bedre :)

#32 Updated by Kasper Garnæs 6 months ago

  • Status changed from Needs code review to Reviewed

Reviewed og godkendt.

Jeg er enig i analyse og ændringsforslag. Tak for arbejdet, Simon og Jesper.

#33 Updated by Kasper Garnæs 6 months ago

  • Status changed from Reviewed to Technical test
  • Assignee changed from Kasper Garnæs to Gitte Barlach

Merged.

#34 Updated by Gitte Barlach 6 months ago

Jeg er usikker på hvordan denne skal testes. 
Jeg har afprøvet søg-vis funktionalitet generelt på upgrade-fbs, og det ser umiddelbart ok ud. Da jeg ikke er stødt på noget graverende, godkender jeg hermed sagen. 

#35 Updated by Gitte Barlach 6 months ago

  • Status changed from Technical test to Resolved (tag version)

Also available in: Atom PDF