Bug 7434 - Display of issue number for serials in overdues
Summary: Display of issue number for serials in overdues
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: 3.8
Hardware: All All
: P3 enhancement (vote)
Assignee: Adrien SAURAT
QA Contact: Ian Walls
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-10 15:39 UTC by Adrien SAURAT
Modified: 2013-12-05 20:04 UTC (History)
4 users (show)

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


Attachments
proposed patch (3.34 KB, patch)
2012-01-13 15:50 UTC, Adrien SAURAT
Details | Diff | Splinter Review
proposed patch #2 with enumchron (2.74 KB, patch)
2012-03-12 15:38 UTC, Adrien SAURAT
Details | Diff | Splinter Review
Bug 7434: Display of issue number for serials in overdues (2.84 KB, patch)
2012-03-17 01:19 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Adrien SAURAT 2012-01-10 15:39:59 UTC
The overdue listing could be enhanced by displaying the issue number for serial results.

For example,
Géo, by Axel Ganz
would become:
Géo, by Axel Ganz, No. 379
Comment 1 Katrin Fischer 2012-01-10 16:35:26 UTC
Hmm, I am surprised that it's not possible - but on the other hand have never tried to do it.

We have 2 different syntax for item information in overdues. 
In theory this should work:

<item><<items.enumchron>></item> 

or

<<items.content>> + Cronjob with enumchron specified in the field list
Comment 2 Adrien SAURAT 2012-01-11 08:35:55 UTC
This patch would not impact the letters but in fact the following page :
Home › Circulation › Overdues
Comment 3 Adrien SAURAT 2012-01-13 15:50:17 UTC Comment hidden (obsolete)
Comment 4 Ian Walls 2012-02-07 15:20:57 UTC
Adrien,


Is the serial value not stored in the enumchron value of the items table?  It would be best to avoid joining on another table if we don't need to.
Comment 5 Adrien SAURAT 2012-02-09 14:13:40 UTC
items.enumchron and serial.serialseq seem to be very close indeed.

Are they supposed to store the same information? (on my test base, dumped from a real base, these infos are close but not exactly the same)

If yes, shouldn't we delete one of them ?
(my database is out of synchro on this)
Comment 6 Katrin Fischer 2012-02-09 14:59:41 UTC
Some differences:

The existence of items.enumchron depends on how you work with serials. If you have subscriptions and decide to not create items, only the field in serials will exist. 

enumchron can have infomration, that is not related to serials. For example you could have volume information there. It's not only available in the serials module, but also in catalguing.

Only the field in items can be indexed for search.

I think we need both - not sure about the differences.
Comment 7 Adrien SAURAT 2012-02-09 15:41:59 UTC
Ok, so if enumchron can be empty or contain other informations, I guess it would be better to stick with serialseq on this patch?
Ian, what do you think?
Comment 8 Katrin Fischer 2012-02-09 16:22:32 UTC
Sorry if I was not clear :( I think it makes sense to display enumchron, we added it to a lot of pages recently. And this is an overdues report - so there has to be an item :)
Comment 9 Jared Camins-Esakov 2012-03-10 17:17:47 UTC
It sounds like the conclusion was that a revised patch which uses items.enumchron is required. Marking Failed QA until the revised patch is provided.
Comment 10 Adrien SAURAT 2012-03-12 15:38:09 UTC Comment hidden (obsolete)
Comment 11 Jared Camins-Esakov 2012-03-17 01:19:03 UTC
Created attachment 8246 [details] [review]
Bug 7434: Display of issue number for serials in overdues

items.enumchron is now displayed when not null

Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Comment 12 Ian Walls 2012-03-19 13:32:38 UTC
Adds enumchron to overdues list.  Simple and straight forward, marking Passed QA.
Comment 13 Jared Camins-Esakov 2012-12-31 00:43:16 UTC
There have been no further reports of problems so I am marking this bug resolved.