Bug 30271 - Allow distinct ILLHiddenRequestStatuses config for view from patron record
Summary: Allow distinct ILLHiddenRequestStatuses config for view from patron record
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: ILL (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-10 16:27 UTC by Andrew Fuerste-Henry
Modified: 2023-10-09 14:16 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2022-03-10 16:27:39 UTC
The system preference ILLHiddenRequestStatuses is great for hiding completed ILL requests from the main ILL request page (/cgi-bin/koha/ill/ill-requests.pl). It also applies to the view of ILL requests within a patron record (/cgi-bin/koha/members/ill-requests.pl). It'd be helpful if those two views could have distinct settings so one could easily hide completed requests from the full view but see them in a specific patron's history.
Comment 1 Katrin Fischer 2023-01-13 13:14:17 UTC
+1
Comment 2 Pedro Amorim 2023-10-09 08:38:05 UTC
ILLHiddenRequestStatuses was designed as a work around to the performance issue on the ILL table, was it not?

The table no longer has performance issues. It is no longer asking for all existing requests and paginating on the front-end.

Is this still needed?
We don't have a similar feature for any other table in Koha, do we?
I would suggest removing the ILLHiddenRequestStatuses sys pref.
Comment 3 Katrin Fischer 2023-10-09 13:30:50 UTC
We started the libraries without any status in the ILLHiddenRequestStatuses, but quickly got asked to remove the completed requests from the view as they cluttered up result lists. Libraries still want to keep them for statistics. If something was ordered multiple times they might want to buy it etc.

I think what would be nice too is having the option to define status you want to see when going to the ILL start page. Basically giving you a TODO list. As the status can vary between backends, that would have to be a setting too.

Right now we load everything and there is no good sorting, so there is lots of 'clutter'. As the status are pretty individual to the backends, I think we cannot find THE perfect defaults either.

We also have bug 26030 - Allow to explicitly search for a hidden ILL status
Comment 4 Pedro Amorim 2023-10-09 13:52:00 UTC
See bug 34431

This is already implementing the "search for a status without having to pick a backend", among other things related to status_alias.

> Right now we load everything and there is no good sorting,
It sorts on most recently created first, but you can also click on the column headers including status, backend, library. There's plenty of sorting options.

I think ILLHiddenRequestStatuses is feature bloat from the past and does not bring value. Or a different way of saying it, the problem it tries to resolve would better be resolved in a different way. Just my opinion!
Comment 5 Katrin Fischer 2023-10-09 13:57:15 UTC
> This is already implementing the "search for a status without having to pick
> a backend", among other things related to status_alias.

Our backend doesn't use status_alias and I never understood how and why to use them.

> > Right now we load everything and there is no good sorting,
> It sorts on most recently created first, but you can also click on the
> column headers including status, backend, library. There's plenty of sorting
> options.

Yes, you can click. But ideally we'd want to save the user clicks. The most recent might already have been processed. The question was if the default filtering makes sense and if it should be removed. We found it made a lost of sense for the completed requests. - is there a technical reason you'd like to remove it?

> I think ILLHiddenRequestStatuses is feature bloat from the past and does not
> bring value. Or a different way of saying it, the problem it tries to
> resolve would better be resolved in a different way. Just my opinion!

I am open to a different way, my arguments were about workflows. As I said, we started out with it empty, but quickly were asked to filter by default. It helped with performance, but there are also other reasons to break down the table to more manageable chunks. If there is another better way to achieve this, I am ok with it.
Comment 6 Pedro Amorim 2023-10-09 14:06:21 UTC
I think the ideal solution for this would be to solve it at the datatables level.
ILL currently does not have this, for several reasons, but for ERM agreements for example you have filters on top of each column.

Create a new agreement, see the agreements list.
You can filter for status directly from the status column.

We could consider implementing an option for "negative filtering" where one would select a list of statuses to not show, instead of show. This could also work for every column.

This would mean that all of Koha where datatables are being used would benefit from this enhancement.

I'd like to remove the system preference because it's a work around for something that should be fixed in a different way and it's anti-pattern (no other table in Koha has this).
I don't feel strongly about it, if people are using and happy with it, it should stay of course.
Comment 7 Katrin Fischer 2023-10-09 14:16:49 UTC
(In reply to Pedro Amorim from comment #6)
> I think the ideal solution for this would be to solve it at the datatables
> level.
> ILL currently does not have this, for several reasons, but for ERM
> agreements for example you have filters on top of each column.

Of course you can, but you can't filter for say "anything but completed". 

> Create a new agreement, see the agreements list.
> You can filter for status directly from the status column.
> 
> We could consider implementing an option for "negative filtering" where one
> would select a list of statuses to not show, instead of show. This could
> also work for every column.

This is what IllHiddenRequestSttauses does.

As a thought: I know the datatable for transactions (accounting) filters out the paid fines/fees by default. Then we have a button to make them visible on demand. Something like this maybe?

> This would mean that all of Koha where datatables are being used would
> benefit from this enhancement.
> 
> I'd like to remove the system preference because it's a work around for
> something that should be fixed in a different way and it's anti-pattern (no
> other table in Koha has this).
> I don't feel strongly about it, if people are using and happy with it, it
> should stay of course.

We have no other table doing this, because it doesn't make sense on other tables or things are solved differently. Take suggestions as an example. We have a tabbed status display where every status has their own tab and a standardized option to archive suggestions. And then a search option so you can still search them on demand.

The problem I see is that for "Complete" which might be the most common to hide - is the status standardized in ILL? ILL is very flexible in how you define things and that's I think why it's configurable right now.