Bug 28641

Summary: ILLHiddenRequestStatuses does not consider custom statuses
Product: Koha Reporter: Andrew Isherwood <bugzilla>
Component: ILLAssignee: Pedro Amorim <pedro.amorim>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P5 - low CC: arthur.suzuki, katrin.fischer, lucas, magnus, martin.renvoize, pedro.amorim, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22440
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32795
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32799
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
23.05.00,22.11.05,22.05.12,21.11.20
Bug Depends on: 23391    
Bug Blocks: 32795    
Attachments: Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses

Description Andrew Isherwood 2021-06-30 14:34:39 UTC
The ILLHiddenRequestStatuses syspref does a good job of filtering out requests that have statuses matching the specified values, but it doesn't take into account custom statuses.

To demonstrate this, create a custom ILL status authorised value, give a request that value, then specify the status code in ILLHiddenRequestStatuses. Then view the list of requests, the list will contain the request with the custom status.

Additional filtering needs to be added to filter out requests with a custom status code matching the specified values.
Comment 1 Katrin Fischer 2022-08-13 23:03:58 UTC
+1
Comment 2 Pedro Amorim 2023-02-02 17:56:02 UTC
Created attachment 146023 [details] [review]
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses

This patch adds the status_alias column to the ILLHiddenRequestStatuses sys pref check.
Because requests will have status_alias NULL by default, we also check for that.

Test plan:
Create multiple ILL requests of different backends and place them in different status (NEW, COMP, REQ, etc)
Create multiple ILLSTATUS entries
Add and remove a mix of both status and status_alias codes in ILLHiddenRequestStatuses and refresh the ILL requests page to confirm the result is according to expectation.
Comment 3 Katrin Fischer 2023-02-10 22:12:35 UTC
Created attachment 146522 [details] [review]
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses

This patch adds the status_alias column to the ILLHiddenRequestStatuses sys pref check.
Because requests will have status_alias NULL by default, we also check for that.

Test plan:
Create multiple ILL requests of different backends and place them in different status (NEW, COMP, REQ, etc)
Create multiple ILLSTATUS entries
Add and remove a mix of both status and status_alias codes in ILLHiddenRequestStatuses and refresh the ILL requests page to confirm the result is according to expectation.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 4 Pedro Amorim 2023-03-17 12:22:16 UTC
Created attachment 148334 [details] [review]
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses

This patch adds the status_alias column to the ILLHiddenRequestStatuses sys pref check.
Because requests will have status_alias NULL by default, we also check for that.

Test plan:
Create multiple ILL requests of different backends and place them in different status (NEW, COMP, REQ, etc)
Create multiple ILLSTATUS entries
Add and remove a mix of both status and status_alias codes in ILLHiddenRequestStatuses and refresh the ILL requests page to confirm the result is according to expectation.

Sponsored-by: PTFS Europe

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 5 Pedro Amorim 2023-03-17 12:22:38 UTC
Added sponsored-by line.
Patch still applies.
Comment 6 Nick Clemens 2023-03-29 07:42:19 UTC
Created attachment 148852 [details] [review]
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses

This patch adds the status_alias column to the ILLHiddenRequestStatuses sys pref check.
Because requests will have status_alias NULL by default, we also check for that.

Test plan:
Create multiple ILL requests of different backends and place them in different status (NEW, COMP, REQ, etc)
Create multiple ILLSTATUS entries
Add and remove a mix of both status and status_alias codes in ILLHiddenRequestStatuses and refresh the ILL requests page to confirm the result is according to expectation.

Sponsored-by: PTFS Europe

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 7 Tomás Cohen Arazi 2023-03-29 17:13:18 UTC
Shouldn't we rename this 'alias' into a 'tag' or similar instead, and stop treating them as aliases?
Comment 8 Pedro Amorim 2023-03-30 14:44:06 UTC
(In reply to Tomás Cohen Arazi from comment #7)
> Shouldn't we rename this 'alias' into a 'tag' or similar instead, and stop
> treating them as aliases?

Any other word for 'alias' could work, but I think we should first understand the problem that status_alias is trying to solve in the first place.
In reality, status_alias is just an alternate status text to show in the UI for its respective request that can be filtered and searched on.

Example:
A request with status (code, name) of "COMP, Completed", that has the status_alias AV (code, description) of "COMP_RET, Item returned", will show "Item returned" in the status column in the ILL list datatable.
So, this feature is really just adding the possibility for the Staff user to change the visible status text of any given request, without actually changing the request status in the database and regardless of the statuses that the request backend provides in the status_graph.

We may want to rethink how we implement this feature, I don't know if just changing alias to a different word is enough, but I don't have any better suggestions right now.
Comment 9 Tomás Cohen Arazi 2023-03-31 10:37:52 UTC
Pushed to master for 23.05.

Nice work everyone, thanks!
Comment 10 Matt Blenkinsop 2023-04-11 11:33:33 UTC
Nice work everyone!

Pushed to stable for 22.11.x
Comment 11 Lucas Gass 2023-04-24 17:26:39 UTC
Backported to 22.05.x for upcoming 22.05.12
Comment 12 Arthur Suzuki 2023-05-03 19:07:34 UTC
applied to 21.11.x for 21.11.20