Bug 32795 - ILLHiddenRequestStatuses system preference description is wrong
Summary: ILLHiddenRequestStatuses system preference description is wrong
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: ILL (show other bugs)
Version: 22.11
Hardware: All All
: P5 - low trivial (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on: 28641
Blocks:
  Show dependency treegraph
 
Reported: 2023-02-02 14:16 UTC by Pedro Amorim
Modified: 2023-12-28 20:42 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 Pedro Amorim 2023-02-02 14:16:51 UTC
Currently, the ILLHiddenRequestStatuses sys preference reads:
"... The request codes can be found in the ILLSTATUS authorized value category."

But, the request status codes actually come from status_graph of their respective backend, or alternatively from core Koha::Illrequest, not from ILLSTATUS.

ILLSTATUS AV is only used for a request's status_alias, which is an alternate list of statuses that is only used to give the staff member the ability of adding their own statuses by editing a request.

On top of that, bug 28641 refers to the fact that the code that is checking this system preference doesn't even consider the requests' status_alias, only the actual status coming status_graph in code.

I think this label should be updated to reflect that it may use both the status codes from installed ILL backends and the values from ILLSTATUS, once 28641 is fixed.
Comment 1 Katrin Fischer 2023-02-02 14:55:04 UTC
That certainly makes sense. 

If we changed the description we could also update 

Bug 28641 - ILLHiddenRequestStatuses does not consider custom statuses

to be an enhancement instead of a bug.
Comment 2 Katrin Fischer 2023-02-10 22:08:36 UTC
I think if we push bug 28641 and bug 32799, this will no longer be needed.
Comment 3 Pedro Amorim 2023-02-13 09:21:05 UTC
+1
Comment 4 Pedro Amorim 2023-05-04 13:26:07 UTC
Closing this as the problem described has been fixed by bug 28641 and 32799 and both have been pushed.