The global variables needs to be assigned with a default value, or the
value from the previous request will be used.
Global variables are persistent from one request to another, in memory.
This patch:
* groups default value for global variables together
* removes $authorised_values_sth from this list (it is not a global var)
* set $changed_framework to 0 (which fix the issue)
Test plan:
1. Open an existing biblio (detail.pl)
2. Click "Edit record"
3. Change the framework (no need to change any details)
4. Change the framework back to the original one (no need to save anything)
5. Go back to the biblio overview page (detail.pl)
=> The form is populated
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1. Apply patch, restart_all
2. System preferences -> EnableItemGroups, set to 'Enable'.
3. Find a record and create at least 1 item group.
4. Go to Add item
5. Scroll to the bottom and look for 'Options' underneath 'Add to item group'
6. In the dropdown select 'Create new item group'
7. There should be fields for 'Name' and 'Display order'.
8. Make sure you can add a new item group with and without a display order set. If no display order is set it should default to 0.
9. Try to add a non numerical display order, you should not be able to.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
It happens that librarians, by mistake, open a biblio editor putting in the
URL, by hand, the biblionumber prefixed with a blank (e.g.
.../addbiblio.pl?biblionumber= 123 -- mind the space before 123).
In such a case the editor opens with the right biblio record (i.e. 123)
but, after saving the record, the content of the biblionumber MARC
field (999 $c for a standard MARC 21 installation) results modified and
contains additional initial blanks.
Moreover, while using ES and making a search for the record (with title,
author etc.) we get two records on the result list (instead of one).
This is because in the addbiblio.pl script $biblionumber is taken (and
continuously used) directly from CGI parameter, without any
validation and/or correction.
Test plan:
==========
0. Have a test installation with ES.
1. Open a biblio record in the editor with an added space before
biblionumber value, e.g.:
http://ktd:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber= 123
Save the record.
2. From the Normal view choose Save -> MARCXML. Open the saved file in
your favourite editor. You should see, at the end, something like:
<datafield tag="999" ind1=" " ind2=" ">
<subfield code="c"> 123</subfield>
(mind the space before 123).
This is not right.
3. Make a search with the title or author's name from the record (e.g.
Henning Mankell for the record 123 from the default ktd data set).
You should get two records instead of one (while using ES).
4. Apply the patch, restart_all. Repeat p. 1 and 2 with a different
biblionumber. Notice the unchanged (i.e. without spaces) value
of 999 $c subfield in the exported record and only one record
as a result of a search.
WNC amended patch - rebased, added conditional in case no bib, moved comments to their own lines
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
After changes made to addbiblio with the bug 31791, when trying to open the
editor with biblionumber=<invalid_number> (e.g. a deleted biblionumber)
Koha explodes with a message << Can't call method "can_be_edited" on
an undefined value at /kohadevbox/koha/cataloguing/addbiblio.pl line 555 >>
Test plan:
==========
1. Try to edit a biblio giving as a biblionumber (in URL) a non-existing
biblionumber, e.g. in ktd, with standard ktd test data:
http://your_ktd:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=1234567
Koha should explode with the message:
Can't call method "can_be_edited" on an undefined value at
/kohadevbox/koha/cataloguing/addbiblio.pl line 555
2. Apply the patch; restart_all.
3. Repeat p.1. You should get a page with the info: "The record you are trying
to edit doesn't exist...".
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
A Marcel's QA patch to Bug 36552 added use POSIX; in two spots.
In https://metacpan.org/pod/POSIX we read:
CAVEATS
Everything is exported by default (with a handful of exceptions). This is
an unfortunate backwards compatibility feature and its use is strongly
discouraged. You should either prevent the exporting (by saying use
POSIX ();, as usual) and then use fully qualified names (e.g.
POSIX::SEEK_END), or give an explicit import list. If you
do neither and opt for the default (as in use POSIX;), you will
import hundreds and hundreds of symbols into your namespace.
This patch fixes this.
No test plan.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Sponsored-by: ByWater Solutions
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Removed the results[0] test too in addbiblio, since there
can be warnings without effectively cancelled order lines.
Also reworded the warn (cancelled, not deleted).
Test plan:
Run t/db_dependent/Koha/Acquisition/Orders.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When the user confirms removal although we have linked orders,
we should cancel them.
Test plan:
Add order line to a basket.
Goto newly added biblio record, remove items, remove biblio.
Notice the warning about attached order lines.
Confirm. Check the basket again after deletion took place (cancelled line).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
After applying "Bug 34478: op =~ ^cud- everywhere" the plugin
marc21_linking_section.pl stopped working properly. Since the plugin
does not perform a CUD operation, the GET request can be used, and so
the use of CSRF token is not needed.
The patch fixes also problems with result page numbers display.
Test plan
=========
1. Configure a MARC bibliographic framework to use the plugin
marc21_linking_section.pl (e.g. in 773 $t).
2. Start creating a new record and go to 773 $t. Activate the plugin to find
the any record to become the host record (perform a search for any
common word, like 'and').
3. You will get no results.
4. Apply the patch, restart plack etc.
5. Repeat p. 2 - you should now see some results, possibly more than one
page. You should be able to change page with Next/Previous arrows and
also with the page numbers.
BTW, QA people - maybe it would pay to remove the commented code present there
since the very beginning (2012).
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The 'date entered on file' (MARC21: 008/0-5, UNIMARC: 100a/0=7) of a record created
by duplication of an existing record should be set to the current date instead of
having the value of the original record.
Test plan
=========
1. Check the 'date entered on file' of an existing biblio / authotiry record
(MARC21: 008/0-5, UNIMARC: 100a/0=7).
2. Duplicate the record by Edit > Edit as new (duplicate)
3. Control the 'date entered on file' value - it will equal to that of the
original record.
4. Apply the patch (restart plack).
5. Repeat step 2.
6. Check the date - it should be the current date.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This can certainly be improved to adjust the permissions, but at least
they are no longer opened to the world..
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
+ attached items, subscriptions etc via the API as an alternative to the web interface: cgi-bin/koha/cataloguing/merge.pl
This is a slightly improved version of Zenos patch: I (domm) have converted the code in Koha::Biblio to a more DBICy style and packed it into a transaction (as requested in Comment 23)
Even the QA script is happy now!
To test:
1) you need an API user with the permissions "editcatalogue"
2) two records: one to be merged into (with biblio_id, eg 262) and another one from
which to merge (with biblio_id_to_merge, eg 9) which will be deleted!
both records may/should have items, subscription, subscriptionhistory, serial, suggestions
orders and holds
3) check both records via the web
4) Apply patch
5) Write a JSON file with inside the field 'biblio_id_to_merge' and the biblionumber from wihich to merge.
As example:
{
"biblio_id_to_merge" : 9
}
6) Execute an API call with correct headers and location. For example:
curl -s -u koha:koha --header "Content-Type: application/json" --header "Accept: application/marc-in-json"
--request POST "http://127.0.0.1:8080/api/v1/biblios/262/merge" -d @file.json
You must to setup the headers and to use a json file with parameters
7) The record with the id 9 is deleted now, the record with 262 has all items, etc attached,
the return is: return code 200 and the changed record 262 in marc-in-json format
8) It is possible to override biblio data with an external bib record. You need to put external bib record
into the json file in marc-in-json format. To write use the json file uploaded as example
You need to fill the fields 'rules' and 'datarecord'. The field 'rules' must contains 'override_ext'
To do the call:
curl -s -u koha:koha --header "Content-Type: application/json" --header "Accept: application/marc-in-json"
--request POST "http://127.0.0.1:8080/api/v1/biblios/XXX/merge" -d @file_with_recod.json
9) The record in 'biblio_id_to_merge' is deleted now, in biblio XXX now there are the bibliographic data
of field 'datarecord' of json file, the return is: return code 200 and the changed record XXX in marc-in-json format
10) Go into intranet and do a search. Select two or (better) more record.
11) Merge them; merge must be a success.
12) Test with prove -v t/db_dependent/Koha/Biblio.t
13) Test with prove -v t/db_dependent/api/v1/biblios.t
To test with curl the step 8 you can customize the json file attached in bugzilla.
The marc-in-json record inside follows the MAR21 standard
Sponsored-by: Technische Hochschule Wildau
Co-authored-by: Zeno Tajoli <ztajoli@gmail.com>
Co-authored-by: Thomas Klausner <domm@plix.at>
Co-authored-by: Mark Hofstetter <<mark@hofstetter.at>>
Signed-off-by: Jan Kissig <jkissig@th-wildau.de>
Bug 33036: Update of test number.
File ../biblios.t was update with a new subutest.
So we need this update to have a 'OK' after test running.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
With Bug 33639 already pushed to master there should be NO change in behavior.
To test:
1. APPLY PATCH
2. Create one or more item groups for a bib if needed
3. Create a new item, and at the bottom of the 'Add item' screen, select the item group to which you want this item added. Save.
4. The item should succesffuly be added to the item group.
5. Add a new item and to the same record and this time try the 'Create a new item group' from the dropdown.
6. Name the new item group.
7. Make sure it is correctly added to the item group.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1, Create one or more item groups for a bib if needed
2. Create a new item, and at the bottom of the 'Add item' screen, select the item group to which you want this item added. Save.
3. On the Normal tab, see that the item has not been added to the item group you selected.
4. APPLY PATCH, restart_all
5. Try 1-3 again but this time the item should succesffuly be added to the item group.
6. Add a new item and to the same record and this time try the 'Create a new item group' from the dropdown.
7. Name the new item group.
8. Make sure it is correctly added to the item group.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test in ktd:
- Tail the logs with "sudo tail -f /var/log/koha/kohadev/plack*.log"
- Find a record in the staff client
- Add an item to the record
- Observe "[WARN] Argument "" isn't numeric in subroutine entry ..."
in /var/log/koha/kohadev/plack-intranet-error.log
- Apply this patch
- restart_all
- Tail the logs again
- Add another item
- Observe the absence of the earlier warning
Thanks to Jonathan Druart for suggesting this particular solution!
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This change sanitizies the field input on cataloguing/ysearch.pl
Test plan:
0. Apply the patch and restart/reload Koha
1a. "Add marc21_field_260b.pl plugin to 260$b in the Default framework"
1b. Go to http://localhost:8081/cgi-bin/koha/admin/marc_subfields_structure.pl?
op=add_form&tagfield=260&frameworkcode=#subbfield
1c. Choose "marc21_field_260b.pl" from the dropdown next to "Plugin"
1d. Click "Save changes"
2a. "Add new record"
2b. Go to http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?frameworkcode=
3. Click on tab "2" and scroll down to 260 "b"
4. Type in "Ori" into 260 subfield b
5. Some autocomplete suggestions should appear
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Verify that setting focus to date acquired field in items editor
fills date of today when field is empty but does not replace existing
date.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Pass necessary parameters from the UI to ensure that the basic
MARC editor can correctly identify when a framework is changed,
a bib is being duplicated, or a bib is being imported with Z39.50 -
for purposes of filling in default values according to the settings
of ApplyFrameworkDefaults.
To test:
1. Set the system preference ApplyFrameworkDefaults - Select All
2. Create or edit a MARC bibliographic framework with a default value in
one of the fields (such as 500$a)
3. Go to the Cataloguing module and create a new record using the
framework from step 2
--> Confirm that the default value is filled in
4. Search for an existing bib record
5. Click Edit > Edit record to open the basic editor
6. If the field from step 2 already has data, clear it
7. Switch the framework to the framework from step 2
--> Confirm that the default value is filled in
8. Clear the field again, and save the edit
9. Click Edit > Edit as new (duplicate)
--> Confirm that the default value is filled in
10. Go to the cataloguing module and do a Z39.50 search
11. Find a record that does not have a value for the subfield from step 2
12. Import the record using the framework from step 2
--> Confirm that the default value is filled in
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Simplest fix; bail out with output_error.
Test plan:
Try /cgi-bin/koha/cataloguing/additem.pl?biblionumber=1&op=saveitem&itemnumber=999999
Note: Replace 1 by existing biblionumber, and iitem 999999 should not exist.
You should get the 404 screen now.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Use event parameter
This is part of the refactoring happening in bug 30975
Test plan:
1. Verify that the plugin continues to work as before
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Use event parameter
This is part of the refactoring happening in bug 30975
Test plan:
1. Verify that the plugin continues to work as before
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 26351 added barcodecode that transforms scanned barcodes either
by using itemBarcodeInputFilter or via a plugin to various pages in
Koha, including checkout and checkin. But the feature for attaching
items to a new record was missed.
To test:
* Add an item with barcode "ab" to any record
* Set itemBarcodeInputFilter to "Remove spaces from"
* Search for another record in the catalog
* Edit > attach item > "a b"
* The item is not found.
* Apply patch, restart_all
* Try again with "a b"
* Verify that the item is found and attached to the record
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an eval to the call for the record form metadata
If there is an error we catch it, display it, and attempt to strip bad characters from the record
To test:
1 - In koha testing docker attempt to view record 369 in the staff interface
2 - You see a warning about degraded view
3 - Attempt to edit the record
4 - Internal server error
5 - Apply patch, restart all
6 - Reload the editor
7 - Record successfully loads!
8 - You have a warning about encoding issues!
9 - Save the record
10 - No more warning!
11 - Edit again, no more warning!
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Set 'autoBarcode' to something other than 'don't generate automatically'
2. If the a framwwork make sure some 952 fields have the barcode.pl plugin enabled
3. Add a new item and click the '...' next to the 952 field with the barcode.pl plugin enabled.
4. The screen jumps back to the top, annoying.
5. Apply patch
6. Try again, it should not jump anymore!
Signed-off-by: Barbara Johnson <barbara.johnson@swbell.net>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
I tried translating it, found it not working and replaced
by the qualif authorised value list with relator terms/codes.
To test:
* Make sure the unimarc_field_700-4.pl is no longer listed in
frameworks.
* Make sure it's not used in the standard frameworks.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes some UNIMARC cataloging plugins which were
essentially duplicates of each other and renaming the remaining version
to reflect that it's for use with multiple subfields.
UNIMARC 123$d, e, f, and g can all be filled with
unimarc_field_123defg.pl
It's easiest to test if you have UNIMARC sample data. In KTD, run
'reset_all_unimarc'
- Apply the patch and run the database update process.
- Go to Cataloging and create or edit a bibliographic record.
- Under tab 1, look for tag 123.
- Test the plugin link for subfields d, e, f, and g
- In each case the popup window should have the heading "UNIMARC field
123d/e/f/g builder"
- Fill out the form each time and confirm that the values are copied
to the correct field in the MARC editor window.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
A primary key error can be thrown when an item number is included in a new title hash. We need the item creation to ignore an itemnumber even if it is included in a MARC Framework
Test plan:
1) Edit the MARC framework relating to books (BKS in KTD)
2) In the 952$9 field (Koha itemnumber (autogenerated)), change the value of "Managed in tab" to "items (10)"
3) In the catalog, find a record that uses that MARC framework
4) Click "New" and choose to add a new item
5) Enter a barcode and click the "Add & duplicate" button
6) The page will refresh and an item will have been added
7) Enter a new barcode and click the same button again
8) An error will be thrown
9) Click the back button in the browser
10) Apply patch and restart_all
11) Click the add and duplicate button again
12) This time no error will be thrown and the page will refresh with another new item added
13) Sign off!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 31162 moved the cataloguing tools to a new cataloguing module home
page. This prevents people without cataloguing permissions, but with
some tools permissions to access things like the labels creator tool.
I tracked all permissions on the cataloging-home.tt template, including
the Stock Rotation ones which I initially missed because I was focusing
on tools.
This patch makes the cataloging-home.pl page require either
'cataloguing' or any relevant 'tools' permission to allow access. the
page.
The staff interface main page and the top bar dropdown are updated using
the same logic to display the cataloguing module link.
For that purpose, I wrapped the permissions on a sub in `C4::Auth`.
To test:
1. Have a patron with only 'catalogue' and some of this permissions:
* inventory
* items_batchdel
* items_batchmod
* items_batchmod
* label_creator
* manage_staged_marc
* marc_modification_templates
* records_batchdel
* records_batchmod
* stage_marc_import
* upload_cover_images
* stockrotation => manage_rotas
2. Log in
=> FAIL: No link to the cataloguing module, neither in the dropdown
3. Apply this patch
4. Repeat 2
=> SUCCESS: You have the link!
5. Play with the different combinations and notice things are sound and
correct
6. Sign off :-D
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. EnableItemGroups
2. Find a record and add some new item groups with different display orders
3. Now edit an item on the record and scroll down to the dropdown underneath "+ Add to item group"
4. Notice that the values in the dropdown do not respect the display order.
5. Apply patch and restart_all
6. The display order should now be respected
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Find a record with several items (in ktd "MacLaren's Gaelic
self-taught" will do nicely
2. Click the Edit button next to one of the items
3. Click the "..." to the right of "d - Date acquired" and verify that the
page doesn't scroll up to the top, and that the current date is
inserted in the field
4. Click the "..." to the right of "w - Price effective from" and verify
that the page doesn't scroll up and the current date is inserted
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Currently hardcoded to 1000.
Can be refined later. Let's first prevent this kind of accidents.
Test plan:
Add additem.pl. Edit the 1000 to 2. Restart all.
Add 3 multiple copies. Notice that you got 2.
Revert your code change.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test Plan:
1) Enable autobarcode
2) Create a new item template, leave the barcode field blank
3) Apply that item template
4) Note the template prefills the barcode field
5) Delete that item template
6) Apply this patch
7) Restart all the things!
8) Repeat steps 2-4
9) Note the barcode field remains empty!
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Go to MARC bibliographic framework, pick a framework and go to 952, subfield "o". Turn the cn_browser plugin on.
2. Pick or create an item in that framework, edit that item.
3. TO the right of the 952$o notice the "...". Click that start the call number browser.
4. Notice there is no column for item type.
5. Apply patch, restart_all
6. Notice there is now a column for item type.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the form to pass through values formthe form when searching, and
to use record values if nothing is passed in.
TO test:
1 - Without the patch, edit a personal name authority record
2 - Replace 100 subfield a (200 subfield a for UNIMARC) with your own name
3 - Click "Replace record via Z39.50/SRU search"
4 - Note that prefilled search field contains the original value, not your name.
5 - Replace the Author (personal) field with your name in the search form
6 - choose a search target, and click Search.
7 - Note that the results of the search are for the original value, not your name
8 - From the details page of a record, click 'Edit -> Replace record via Z3950'
9 - Note form is prefilled
10 - Change value as in 5 and search
11 - Note original term was searched
12 - Apply patch, restart all
13 - Repeat searches as before
14 - Confirm that form is prefilled with record or the updated value
15 - Confirm your entered search terms are always searched
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
