Bug 9571 [Alternate] Fix width for textareas in Edit Item screen

This alternative patch modifies the script where the input markup is
built and adds an alternative configuration for textareas. This gives
the textareas explicit "cols" and "rows" attributes. I think this
solution is preferable to a style fix because it solves the bug while
eliminating some invalid markup (no "size" or "maxlength" attributes on
textareas, which are invalid without explicit dimensions).

To test, add a nice big chunk of text to an existing item's item field
like "Public note" (952$z), save, and edit again. The field should now
be displayed in a more comfortably-sized textarea.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Bug 9571 - Fix width for textareas in Edit Item screen

This patch adds a style for textareas on the Edit Item screen of addbiblio.pl so that they are roughly the same length as the other input elements around it on the page.

To test:

Before applying patch...

1) Create a new item for any biblio with a URL (subfield u) of over 100 characters (you can use www.lettercount.com to count the number of characters in your URL).
2) In any browser (I've already looked at IE, Firefox, and Chrome on Windows), edit the item (either by clicking "Edit Items" from the Normal view of the bib record then clicking "Edit" next to the applicable item, or clicking on the "Items" view in the bib record and clicking "Edit item" next to the relevant item).
3) Notice that the textarea for the url is absolutely tiny. Difficult to read and difficult to interact with.

Apply patch.

1) Notice that the textarea is roughly the same size as the other input elements on the page.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Merge remote-tracking branch 'kc/3.8.x' into 3.8.x
Bug 9838: fix on 04patron_status.t

Some patron infos were hard coded instead
of using the variables defined in SIPtest.pm

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Bug 9609: Rebuilding zebra reports double number of exported records.

Test plan:
Clear the zebra queue (run rebuild). Update one biblio.
Rebuild zebra (again) with -z. Check zebra log: note 2 exported records.
Now apply patch, and repeat: You will see 1 exported record.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Bug 9947 - Creating item for received serial prefills enumchron subfield

In serial receiving :
When creating an item for an issue, a javascript prefilles the $h subfield with issue number.
This is for MARC21, in UNIMARC serial number is on $v.

This patch replaces hard-coded value with the subfield mapped with "items.enumchron".

Test plan :
- Set "Koha to MARC mapping" of "items.enumchron" on a subfield other than $h, ie $z
- Go to a serial subscription detail with "Serial receipt creates an item record"
- Click on "Receive"
- On an issue, click on "Click to add item"
=> Check that issue number is copied into selected subfield, ie $z
You may test that with no mapping of "items.enumchron" there is no javascript error

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Nice catch! Works as advertised.
All tests pass after fixing tabulation characters in serials-edit.tt.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Bug 9535 - Patron card creator "Remove duplicates" function doesn't work

This bug was due to a difference in field names used in the item data
for items versus patrons. This patch adds a ternary to discern between
the two.

To test:

Before applying patch:

1. Create a batch of patroncards with one duplicate.
2. Run the de-duplication on the batch.
3. Note that all patrons beyond the first in the batch are now
   deleted.

After applying patch:
4. Repeat steps 1-2.
5. Note that only the duplicate patron is removed.

Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Tested successfully with both patron card batches and label batches.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Add indentation for readability
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>