Bug 28641 - ILLHiddenRequestStatuses does not consider custom statuses
Summary: ILLHiddenRequestStatuses does not consider custom statuses
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: ILL (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Pedro Amorim
QA Contact:
URL:
Keywords:
Depends on: 23391
Blocks: 32795
  Show dependency treegraph
 
Reported: 2021-06-30 14:34 UTC by Andrew Isherwood
Modified: 2023-12-28 20:44 UTC (History)
7 users (show)

See Also:
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


Attachments
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses (1.59 KB, patch)
2023-02-02 17:56 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses (1.65 KB, patch)
2023-02-10 22:12 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses (1.67 KB, patch)
2023-03-17 12:22 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 28641: ILLHiddenRequestStatuses does not consider custom statuses (1.73 KB, patch)
2023-03-29 07:42 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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