Bug 33932 - Why multiple statuses on item record
Summary: Why multiple statuses on item record
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-06-06 22:51 UTC by Christopher Brannon
Modified: 2023-07-19 21:09 UTC (History)
5 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2023-06-06 22:51:20 UTC
Is there a reason we need to have multiple status fields?  I'm wondering why we don't consolidate the statuses to a single field that you can set multiple statuses on.  Is it because each status has a timestamp?
Comment 1 David Cook 2023-06-06 23:14:30 UTC
Could you provide a screenshot of what you mean?
Comment 2 Jonathan Druart 2023-06-07 08:02:00 UTC
Talking about damaged, withdrawn, lost?

Yes, there is one date field per status, and we also want a MARC mapping (so it has to be a DB column).
Comment 3 Christopher Brannon 2023-06-07 14:15:20 UTC
(In reply to Jonathan Druart from comment #2)
> Talking about damaged, withdrawn, lost?
> 
> Yes, there is one date field per status, and we also want a MARC mapping (so
> it has to be a DB column).

Yes.  It just seems like this model might be a bit limiting.  So you're saying that MARC mapping could not work at all if status was structured any differently?
Comment 4 Jonathan Druart 2023-06-07 14:42:12 UTC
Look at cgi-bin/koha/admin/koha2marclinks.pl: 1 DB column is mapped to 1 MARC subfield.

Everything is always possible, but that would be really hard to change :)
Comment 5 Christopher Brannon 2023-06-07 15:01:32 UTC
(In reply to Jonathan Druart from comment #4)
> Look at cgi-bin/koha/admin/koha2marclinks.pl: 1 DB column is mapped to 1
> MARC subfield.
> 
> Everything is always possible, but that would be really hard to change :)

Everything is hard to change from my perspective, especially mechanisms that have been in place for years, but there is a community of programmers out there that put together a brilliant ILS from nothing.  Complexity should not be the deciding factor.  I'm sure that answer could be given to most of the things the community programmers have contributed to Koha over the last 23 years.

The question is, does the current setup tie our hands, and is it something that libraries would benefit from if it were changed?  That's really why this is a discussion at this point.  I am curious why the statuses are compartmentalized the way they are, and does this layout limit setup or functionality?  Could consolidation improve system administration or item workflow?
Comment 6 Katrin Fischer 2023-06-07 15:17:24 UTC
(In reply to Christopher Brannon from comment #0)
> Is there a reason we need to have multiple status fields?  I'm wondering why
> we don't consolidate the statuses to a single field that you can set
> multiple statuses on.  Is it because each status has a timestamp?

Because an item can be checked out, lost and damaged, usage restricted at the same time. I believe having multiple status for separate things is indeed a strength of Koha, not a weakness. If we tried to simplify this we'd end up with a long list of possible status and would make things ultimately less flexible and more complicated.

I believe changing it would tie our hands - keeping it gives us all the flexibility.
Comment 7 David Cook 2023-06-08 00:23:58 UTC
(In reply to Christopher Brannon from comment #5)
> (In reply to Jonathan Druart from comment #4)
> > Everything is always possible, but that would be really hard to change :)
> 
> Everything is hard to change from my perspective, especially mechanisms that
> have been in place for years, but there is a community of programmers out
> there that put together a brilliant ILS from nothing.  Complexity should not
> be the deciding factor.  I'm sure that answer could be given to most of the
> things the community programmers have contributed to Koha over the last 23
> years.

Considering that Jonathan Druart is the number 1 top contributor to Koha by a landslide, you can trust his authority on the feasibility of changes. 

Koha also doesn't come from nothing. While many of us community programmers have volunteered our own time at times out of the goodness of our hearts, a lot of the work we do is paid for by our employers or our clients. Someone has decided that the change was valuable enough to pay for our time. 

A contribution isn't just writing code either. It's also seeing it through an additional 3 step process of testing, quality assurance, and merging/pushing. At that point, it's not just 1 person's time, but 4 people's time involved in making just 1 contribution go into Koha. 

Small contributions are easy to get through the process, but complex ones are more challenging. Jonathan has contributed quite a few complex changes to Koha, and helped other people with theirs.

Something like item "status" is complicated even further than many complex changes, because that's something that gets shared beyond Koha via APIs to discovery systems like VuFind, Aspen, EBSCO's EDS, Ovid's ODS, etc. 

--

That said, there is more than one way to look at a problem as well. Perhaps what you have in mind is more of a change to how the data is "viewed" rather than how the data is "modelled".
Comment 8 David Cook 2023-06-08 00:36:48 UTC
(In reply to Christopher Brannon from comment #0)
> Is there a reason we need to have multiple status fields?  I'm wondering why
> we don't consolidate the statuses to a single field that you can set
> multiple statuses on.  Is it because each status has a timestamp?

I've re-read your description, and I'm wondering are you talking about a screen that has a "Status" label and then a number of checkboxes for things like "Withdrawn", "Damaged", "Lost", etc?
Comment 9 Christopher Brannon 2023-07-10 15:57:22 UTC
(In reply to David Cook from comment #8)
> (In reply to Christopher Brannon from comment #0)
> > Is there a reason we need to have multiple status fields?  I'm wondering why
> > we don't consolidate the statuses to a single field that you can set
> > multiple statuses on.  Is it because each status has a timestamp?
> 
> I've re-read your description, and I'm wondering are you talking about a
> screen that has a "Status" label and then a number of checkboxes for things
> like "Withdrawn", "Damaged", "Lost", etc?

I guess, if it helps to have it all separated out, then that isn't really the issue.  It probably has more to do with how staff interact with it.  IMO, as status is a status.  I shouldn't have to look in 4 different places to address an item status.  Maybe the way it is displayed in the item editing could be changed to checkboxes with a date next to each, and a single update button?  That would seem a little less clunky.

However, it still makes reporting more complicated - You simply need a status, and you are having to get information from multiple fields.
Comment 10 David Cook 2023-07-11 00:09:11 UTC
(In reply to Christopher Brannon from comment #9)
> I guess, if it helps to have it all separated out, then that isn't really
> the issue.  It probably has more to do with how staff interact with it. 
> IMO, as status is a status.  I shouldn't have to look in 4 different places
> to address an item status.  Maybe the way it is displayed in the item
> editing could be changed to checkboxes with a date next to each, and a
> single update button?  That would seem a little less clunky.

I think that I hear what you're saying. It would be nice just to have one field that can be either "withdrawn", "lost", "damaged", "restricted", or "not for loan". 

One of the tricky things is there can be multiple user-defined statuses for each of those categories. Uniting those together into one would be quite problematic in a number of ways.

Another thing about those statuses is that they're not all treated equally. While most of those categories cause an item to no longer be "available", the item is still "available" when it's restricted. 

There's also "Not for loan" at the item type level, which is something you won't see in the item editor, and isn't obvious when doing SQL reports.

If all the possible statuses were in one 1 database column, you'd also need to take into account all possible codes when writing your SQL reports. That would either mean a lot of maintenance, or eliminating user-entered codes for statuses, which many would see as a feature regression.

That said, perhaps "Status" could just be "withdrawn", "lost", "damaged", "restricted", or "not for loan" and then there could be a second column with the more precise code. But that would probably take a fair bit of UI refactoring.

There are also recalls, holds, on order, and in transit statuses, although perhaps those should be marked under "Availability".

> However, it still makes reporting more complicated - You simply need a
> status, and you are having to get information from multiple fields.

In theory, we or your Koha support folk could add a database "view" that unites the different columns into 1 status field to simplify your reporting.
Comment 11 Katrin Fischer 2023-07-11 08:09:39 UTC
If we had only one status field, we'd have to prioritize the different status as only one would apply. So it can be either lost, or withdrawn, or not for loan, or damaged... only one thing applies at a time, leading to less exact reporting.

But maybe I misunderstood and you only meant one calculated status or a display status and the other fields remain as they are?
Comment 12 David Cook 2023-07-11 23:35:36 UTC
(In reply to Katrin Fischer from comment #11)
> If we had only one status field, we'd have to prioritize the different
> status as only one would apply. So it can be either lost, or withdrawn, or
> not for loan, or damaged... only one thing applies at a time, leading to
> less exact reporting.

I was thinking the same thing. While there might be more convenience, there'd be less granularity. 

> But maybe I misunderstood and you only meant one calculated status or a
> display status and the other fields remain as they are?

Not sure which "you" you mean here hehe.
Comment 13 Katrin Fischer 2023-07-12 08:43:12 UTC
(In reply to David Cook from comment #12)
> (In reply to Katrin Fischer from comment #11)
> > If we had only one status field, we'd have to prioritize the different
> > status as only one would apply. So it can be either lost, or withdrawn, or
> > not for loan, or damaged... only one thing applies at a time, leading to
> > less exact reporting.
> 
> I was thinking the same thing. While there might be more convenience,
> there'd be less granularity. 
> 
> > But maybe I misunderstood and you only meant one calculated status or a
> > display status and the other fields remain as they are?
> 
> Not sure which "you" you mean here hehe.

Christopher, but always good to check if one is talking about the same thing/idea :)