[Koha-bugs] [Bug 20581] Allow manual selection of custom ILL request statuses

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20581

--- Comment #167 from Andrew Isherwood <andrew.isherwood at ptfs-europe.com> ---
Hi Katrin

Thanks very much for the info. A bit of context might be in order.

An ILL request has, at any given time, a single "status". The workflow the
request passes through is dictated by those statuses. The ILL module has the
idea of a "status graph", which essentially says "if you're at this status, you
can have come from this/these status(es) and you can go to this/these
status(es)." This is how we can determine what actions the user can take on any
given request.

This bug adds the concept of status aliases, which are user defined as
authorised values. These have no bearing on any of the above, the request's
status is still used in the same way. The status alias is purely used for
display. The display logic says "if a request has a status alias, display that,
otherwise display the request's status". This enables the user to select one of
their user defined status aliases, which will be displayed in favour of the
request's "actual" status. This allows the user to assign a more locally
meaningful status to a request, rather than rely on those provided by ILL.

I mentioned above that the status alias has no bearing on the actual status.
The request's status is still there, and still determines, say, which action
buttons are displayed for a request, but it is not displayed if an alias is
also assigned to that request. However, if a request that has a status alias is
moved forward through the workflow by clicking one of the action buttons (e.g.
Confirm request), we assume that the status alias is no longer applicable and
nullify it in the request, causing the request's actual status to now display,
until such a time as the user selects a new status alias.

So, to address what you're seeing above with -1 being assigned. In the "Edit
request" screen, the status dropdown contains all of the status aliases PLUS an
option for the request's actual status, which effectively allows the user to
nullify the request's status alias and revert the request to the actual status.
You said you selected "New request", which will have been the request's actual
status. But it sounds like, rather than nullifying the status alias, it set it
to -1. Which is odd.

I'll investigate and get back to you. Thanks again for your ongoing efforts on
getting this one through!

-- 
You are receiving this mail because:
You are watching all bug changes.