Bug 14987 - patron card creator not displaying correct cardnumber
Summary: patron card creator not displaying correct cardnumber
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-08 23:33 UTC by Liz Rea
Modified: 2018-12-03 20:04 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Liz Rea 2015-10-08 23:33:44 UTC
Actually, I'm not entirely sure what the context of "cardnumber" is on edit-batch - is it the number of the card being printed? Is it supposed to be the cardnumber of the borrower? I admit to not having the chance to really dig up what it's supposed to be but it doesn't really make sense to me as it stands.

I think it should either be the cardnumber of the borrower (i.e. the barcode that would be printed) or explicitly labelled something that is not "cardnumber" if it's something else.
Comment 1 Marc Véron 2015-10-09 03:57:13 UTC
Card number is the position number in the batch.

It comes from:

koha-tmpl/intranet-tmpl/prog/en/modules/patroncards/edit-batch.tt Line 215
[% SWITCH header_field.field_label -%]
   [% CASE "Card Number" -%]
      <th>Card number</th>
^-----------------------
patroncards/edit-batch.pl Line 50
my $display_columns = [ {_card_number   => {label => 'Card Number', (...)

^----------------------
Line 138 get_card_summary
^----------------------
C4/Creators/Lib.pm
get_card_summary:
This function returns an arrayref whose elements are hashes containing the label_ids of current cards along with the item count
Line 367 :  
my $card_number = 0;  
(...)
    foreach my $item (@{$params{'items'}}) {
        $card_number++;
(...)
      my $card_summary->{'_card_number'} = $card_number;

Fazit:
Quick string fix would be to change edit-batch.cc
More comprensible / sustainable fix would be to change edit-batch.pl and Lib.pm as well.
Comment 2 Marc Véron 2015-10-09 04:29:18 UTC
Typo:
Quick string fix would be to change edit-batch.cc
                                               ^^
                                     edit-bach.tt
Comment 3 Liz Rea 2015-10-09 04:38:19 UTC
Ah right. Well that's still a little silly. I'm doing heaps of stuff in there atm, maybe I'll fix it. :)
Comment 4 Marc Véron 2015-10-09 06:32:39 UTC
Some more findings:

In label batches, the column is called 'Label number', I think the internals are similar to patron cards.

The patron cards and labels are printed in this order.

It would be a good idea to have the same column name for both. Maybe something like 'Item Number'. 

'Position' or 'Batch position' would collide with the meaning of 'Position' while exporting labels: "Enter starting label position (PDF)" i.e. the position where the first batch item will be printed on the paper / printing form (see Bug 8796).
Comment 5 Liz Rea 2015-10-09 06:37:55 UTC
Hm, but you can't change it, and it is basically the order the items are added... Idk, I suppose I'm questioning why we need to display it at all. 

It would, in fact, be good to make it consistent between the label creator and patron card creator. That is if we don't remove the display entirely.
Comment 6 Marc Véron 2015-10-09 07:19:04 UTC
I also was thinking about not displaying this column. Hmm, we can sort the colums e.g. alphabetically by name (in the table only, not for printing), so it might be needed to switch back to the order 'how I added items'.

It would be a big enhancement (and quite a task) 
- to have te possibility to print in different orders
- to be able to move an item inside the 'added' batch position

Hmm, at the moment I propose to change the template files only (string change for the headers to avoid user confusion) and to postpone the rest.
Comment 7 Marc Véron 2016-02-10 14:24:45 UTC
This bug seems no longer to be valid. 
Liz, can you confirm?