Almost all our library consortiums have large amounts of late orders. Smallest amount is around 2000, but largest is over 25000. Even with batch of 2000 orders, lateorders.pl takes over 40 seconds to open. Handling larger batches eventually leads to a Proxy error. One (quite easy imo) way to speed up fetching late orders is to add a syspref to set default value for late order filter "Order date: [] days ago".
Created attachment 144145 [details] [review] Bug 32266: Add new syspref DefaultLateOrderFilterDaysAgo Some libraries might have large amounts of late orders that slow down opening the lateorders.pl. E.g. patch of 2000 orders takes about 40 seconds to open, larger patches lead to a proxy error. This patch adds new syspref DefaultLateOrderFilterDaysAgo. With this libraries can control how many days old late orders should be for them to show in late orders listing. To test: 1. Open browsers console (F12) and from there Network tab. 2. Navigate to Acquisitions -> Late Orders. => Take a note from browsers console how long it takes to open late orders listing. 3. Apply this patch, update you database and restart your services if needed. 4. Set some value to syspref DefaultLateOrderFilterDaysAgo (999 is max). 5. Load Late orders page again. => Loading page should now be significantly faster. => Only orders which Sponsored-by: Koha-Suomi Oy
Created attachment 144165 [details] [review] Bug 32266: Add new syspref DefaultLateOrderFilterDaysAgo To test: 1. Open browsers console (F12) and from there Network tab. 2. Navigate to Acquisitions -> Late Orders. => Take a note from browsers console how long it takes to open late orders listing. 3. Apply this patch, update you database and restart your services if needed. 4. Set some value to syspref DefaultLateOrderFilterDaysAgo (999 is max). 5. Load Late orders page again. Nice enhancement.
Created attachment 144699 [details] [review] Bug 32266: Add new syspref DefaultLateOrderFilterDaysAgo Some libraries might have large amounts of late orders that slow down opening the lateorders.pl. E.g. patch of 2000 orders takes about 40 seconds to open, larger patches lead to a proxy error. This patch adds new syspref DefaultLateOrderFilterDaysAgo. With this libraries can control how many days old late orders should be for them to show in late orders listing. To test: 1. Open browsers console (F12) and from there Network tab. 2. Navigate to Acquisitions -> Late Orders. => Take a note from browsers console how long it takes to open late orders listing. 3. Apply this patch, update you database and restart your services if needed. 4. Set some value to syspref DefaultLateOrderFilterDaysAgo (999 is max). 5. Load Late orders page again. => Loading page should now be significantly faster. => Only orders which Sponsored-by: Koha-Suomi Oy Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
I understand where this is coming from, but we should really just copy and paste the API-based paginated orders table from parcel.tt and change some query parameters to match this use case... I can help if needed.
(In reply to Tomás Cohen Arazi from comment #4) > I understand where this is coming from, but we should really just copy and > paste the API-based paginated orders table from parcel.tt and change some > query parameters to match this use case... > > I can help if needed. That is definitely a better solution in a long run. My plan was to first provide syspref as a simpler solution and then examine if we can optimize code in a different bug. I'll try adding that paginated table here and ask help if there are any problems.
I haven't been able to work with this and probably won't be a long time. Removing myself from assigned so if someone is able to take a look at this feel free to do so.
Created attachment 182041 [details] [review] Bug 32266: Add only_late filters to the endpoint
Created attachment 182042 [details] [review] Bug 32266: Add more embed options to orders and baskets This patch adds the ability to embed: Orders: * basket.vendor * basket.authorizer+strings * claims+count Baskets: * vendor * authorizer+strings
Created attachment 182043 [details] [review] Bug 32266: Make the late orders page use the API This bug makes the late orders page render using the API. Everything should work as usual. To test: 0. Have a bunch of late orders, from different vendors with different dates 1. Check how the page works without the patches 2. Notice it works similar with the patches 3. Sign off :-D
Page opens, but table doesn't load. In browsers console is a message: >Uncaught TypeError: row.basket.authorizer is null Maybe there needs to be a check if fetched row has authorisedby value in place, since it can be sometimes be NULL.
(In reply to Emmi Takkinen from comment #10) > Page opens, but table doesn't load. In browsers console is a message: > > >Uncaught TypeError: row.basket.authorizer is null > Maybe there needs to be a check if fetched row has authorisedby value in > place, since it can be sometimes be NULL. Did you do: ```shell $ ktd --shell k$ yarn build k$ koha-plack --restart kohadev ``` before testing? I will double-check just in case, but it feels like I had that check in place.
Created attachment 182269 [details] [review] Bug 32266: (follow-up) Handle null basket.authorizer gracefully This patch makes the JS code handle the situation of `aqbasket.authorisedby` being NULL. I was only able to reproduce this by manually touching the DB, but existing data might have this situation. To test: 1. Have a few late orders 2. Pick a basket id 3. Run: $ ktd --shell k$ koha-mysql kohadev > UPDATE aqbasket SET authorisedby=NULL WHERE basketno=2; (in this case 2 was my chosen basket). 4. Visit the late orders page => FAIL: The table doesn't render correclty, the browser inspector says something about authorizer being null 5. Apply this patch 6. Repeat 4 => SUCCESS: The table renders correctly, the 'Library' column has an empty string for the affected rows 7. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(In reply to Emmi Takkinen from comment #10) > Page opens, but table doesn't load. In browsers console is a message: > > >Uncaught TypeError: row.basket.authorizer is null > Maybe there needs to be a check if fetched row has authorisedby value in > place, since it can be sometimes be NULL. Fixed!