[Bug 11682] New: serials.status is too dependent on magic numbers
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 Bug ID: 11682 Summary: serials.status is too dependent on magic numbers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs@lists.koha-community.org Reporter: gmcharlt@gmail.com QA Contact: testopia@bugs.koha-community.org CC: colin.campbell@ptfs-europe.com 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hm, might be misunderstanding. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@biblibre.co | |m --- Comment #4 from Jonathan Druart <jonathan.druart@biblibre.com> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=10851 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 --- Comment #5 from Jonathan Druart <jonathan.druart@biblibre.com> --- Created attachment 25045 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25045&action=edit Bug 11687: statecollection.pl is no longer in use It can be removed. Test plan: git grep statecollection returns no occurrence. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25045|0 |1 is obsolete| | --- Comment #6 from Jonathan Druart <jonathan.druart@biblibre.com> --- Comment on attachment 25045 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25045 Bug 11687: statecollection.pl is no longer in use Arg, bad bz number. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |ASSIGNED -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11682 --- Comment #7 from Galen Charlton <gmcharlt@gmail.com> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org