Librarians are complaining that displaying the full table of ILL requests is taking a lot of time, even with moderate amounts of requests (on the order of 100-200). I think there are a couple of bottlenecks: 1. Embedding data We are embedding - metadata - patron - capabilities - library - status_alias - comments - requested_partners That's at least 6 additional queries times the number of requests in the table. Not sure what can be done here in general, though. 2. Capabilities/status graph For every request, the whole status graph is included with each request. When I look at the JSON data returned for one request in a sample database, it is about 540 lines of data. But about 400 of those make up the status graph, and since this system only has one active backend, those 400 lines are (as far as I can see) identical for all 200 requests. Could we send the status graph once per backend, and then have some reference/link from the request to the correct status graph? 3. Fetching requests selectively Today, data is fetched for all requests not hidden by ILLHiddenRequestStatuses before the table of requests is displayed. Bug 30200 proposes to add configurable tabs to the ILL requests table. Could it be possible to load the data for the tabs just-in-time, so that only the data for the first tab is loaded initially? Instead of loading everything just-in-case when the page is first shown. And then have the "All" tab to the right, so that "all" data is only loaded if the user asks for it.
Maybe this was fixed by some work from the hackfest?
This is already being worked on bug 22440. With great results. The UI details are looked after by Pedro *** This bug has been marked as a duplicate of bug 22440 ***