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.
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.
Hm, might be misunderstanding.
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.
(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.
Created attachment 25045 [details] [review] Bug 11687: statecollection.pl is no longer in use It can be removed. Test plan: git grep statecollection returns no occurrence.
Comment on attachment 25045 [details] [review] Bug 11687: statecollection.pl is no longer in use Arg, bad bz number.
(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.
Are authorized values translatable now? I feel like we should be able to customized the serial statuses like we do regular statuses.
(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.
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.
(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 :)
(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
I agree with Esther's suggestion of authorized values. Our serials vendor has some pretty specific statuses and it would help our staff if we could match those up in Koha and the claims lists we export.