Bug 11682 - serials.status is too dependent on magic numbers
Summary: serials.status is too dependent on magic numbers
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Serials (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-04 17:57 UTC by Galen Charlton
Modified: 2023-09-13 21:03 UTC (History)
8 users (show)

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


Attachments
Bug 11687: statecollection.pl is no longer in use (4.48 KB, patch)
2014-02-05 09:40 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Galen Charlton 2014-02-04 17:57:39 UTC
The status column in the serials table, which represents the receipt status of a serial issue, uses a slew of magic numbers.  This can make it difficult to maintain the code and add new statuses.

Ways to address this, ranging from simple to more complex, include:

[1] Use named constants.

[2] Changing serials.status from an integer to a varchar and using self-describing values, possibly in conjunction with a new authorized value list.

[3] Create a new serial_issue_status column to manage the statuses.  It might look like this:

id INTEGER -- status ID
name VARCHAR(255) -- label of status
missing BOOLEAN -- whether or not the status should be considered to represent an issue that was never received

[4] As with option 3, but allowing staff users to define new statuses.
Comment 1 Katrin Fischer 2014-02-04 21:38:33 UTC
The problem with authorized values is that there is currently no way to have multiple translations. The standard statuses right now are located in the tepmlates and are therefore translated into any installed lanugage.
Comment 2 Katrin Fischer 2014-02-04 21:42:58 UTC
Hm,  might be misunderstanding.
Comment 3 Katrin Fischer 2014-02-05 06:24:22 UTC
Ok, no more commenting in the late evenings? :) Maybe we could allow to define custom statuses and still keep a few standard ones, similar to the suggestion status.
Comment 4 Jonathan Druart 2014-02-05 09:21:36 UTC
(In reply to Galen Charlton from comment #0)
> [3] Create a new serial_issue_status column to manage the statuses.  It
> might look like this:
> 
> id INTEGER -- status ID
> name VARCHAR(255) -- label of status
> missing BOOLEAN -- whether or not the status should be considered to
> represent an issue that was never received

I'm not sure it is enough.
The status value is checked at several places in the code:

 1/ (planneddate < now() AND serial.status=1) OR serial.STATUS IN (3, 4, 41, 42, 43, 44)

 2/ WHERE ((planneddate < now() AND serial.STATUS =1) OR serial.STATUS = 3)

and some others.

The "missing" boolean won't permit to write a SQL query doing the same thing.
Comment 5 Jonathan Druart 2014-02-05 09:40:50 UTC Comment hidden (obsolete)
Comment 6 Jonathan Druart 2014-02-05 09:42:13 UTC
Comment on attachment 25045 [details] [review]
Bug 11687: statecollection.pl is no longer in use

Arg, bad bz number.
Comment 7 Galen Charlton 2014-02-05 15:51:13 UTC
(In reply to Jonathan Druart from comment #4)
> (In reply to Galen Charlton from comment #0)
> > [3] Create a new serial_issue_status column to manage the statuses.  It
> > might look like this:
> > 
> > id INTEGER -- status ID
> > name VARCHAR(255) -- label of status
> > missing BOOLEAN -- whether or not the status should be considered to
> > represent an issue that was never received
> 
> I'm not sure it is enough.
> The status value is checked at several places in the code:
> 
>  1/ (planneddate < now() AND serial.status=1) OR serial.STATUS IN (3, 4, 41,
> 42, 43, 44)
> 
>  2/ WHERE ((planneddate < now() AND serial.STATUS =1) OR serial.STATUS = 3)
> 
> and some others.
> 
> The "missing" boolean won't permit to write a SQL query doing the same thing.

Good point.  Additional flags would cover the cases you've listed, e.g.,

is_expected_status
is_late_status
is_claimed_status

However, we could also pin the IDs for those statuses and use named constants in the code for those, and use an deletable flag in the serial_issue_status to control whether the user can remove that status.
Comment 8 Caroline Cyr La Rose 2018-08-23 18:45:41 UTC
Are authorized values translatable now? I feel like we should be able to customized the serial statuses like we do regular statuses.
Comment 9 Katrin Fischer 2018-08-23 20:12:57 UTC
(In reply to Caroline Cyr La Rose from comment #8)
> Are authorized values translatable now? I feel like we should be able to
> customized the serial statuses like we do regular statuses.

You can translate them, but they are not multi-lingual - you can not have them in English and German for example. And we don't have installers for a lot of different languages, so it's manual work to translate them often.
Comment 10 Esther Melander 2023-09-13 20:33:34 UTC
It would be nice to change serial statuses to authorized values so that custom statuses can be added with added functionality.

One example is to have a status that says "bindery" to indicate a serial which is temporarily unavailable. It is not currently possible to do this. And in general there is no way to edit the serial status in the serial collection after it has been received.
Comment 11 Katrin Fischer 2023-09-13 21:03:14 UTC
(In reply to Esther Melander from comment #10)
> It would be nice to change serial statuses to authorized values so that
> custom statuses can be added with added functionality.
> 
> One example is to have a status that says "bindery" to indicate a serial
> which is temporarily unavailable. It is not currently possible to do this.
> And in general there is no way to edit the serial status in the serial
> collection after it has been received.

Hi Esther, 23.05 has a bindery status :) 

The magic numbers here refer to the fact that numbers are used internally instead of codes, which would make reporting etc. easier. As the AV are shown to the users in the OPAC I am not too fond of the AV idea yet, because AV are not multi-lingual (yet). I hope someday they will be :)
Comment 12 Katrin Fischer 2023-09-13 21:03:44 UTC
(In reply to Katrin Fischer from comment #11)
> (In reply to Esther Melander from comment #10)
> > It would be nice to change serial statuses to authorized values so that
> > custom statuses can be added with added functionality.
> > 
> > One example is to have a status that says "bindery" to indicate a serial
> > which is temporarily unavailable. It is not currently possible to do this.
> > And in general there is no way to edit the serial status in the serial
> > collection after it has been received.
> 
> Hi Esther, 23.05 has a bindery status :) 
> 
> The magic numbers here refer to the fact that numbers are used internally
> instead of codes, which would make reporting etc. easier. As the AV are
> shown to the users in the OPAC I am not too fond of the AV idea yet, because
> AV are not multi-lingual (yet). I hope someday they will be :)

Bug 32752