C4::Reserves:
* Added OnShelfHoldsAllowed() to check issuingrules
* Added OPACItemHoldsAllowed() to check issuingrules
* IsAvailableForItemLevelRequest() changed interface, now takes
$item_record,$borrower_record; calls OnShelfHoldsAllowed()
opac/opac-reserve.pl and opac/opac-search.pl:
* rewrote hold allowed rule to use OPACItemHoldsAllowed()
* also use OnShelfHoldsAllowed() through
* IsAvailableForItemLevelRequest()
templates:
* Removed AllowOnShelfHolds and OPACItemHolds global flags, they now
only have meaning per item type
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
I have tested this patch left, right and upside down for the last
several months. All tests have passed.
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@gmail.com>
Test plan:
1. Add 4 item search fields (in Administration › Items search fields):
a. 1 biblio field linked to a DB field
b. 1 biblio field not linked to a DB field
c. 1 item field linked to a DB field
d. 1 item field not linked to a DB field
2. Make sure you have some data in those fields to search on.
3. Go to item search page and do a search using these new fields, make
sure the result is correct.
Signed-off-by: Nick <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This is introduced by Bug 12874.
Without this patch, it's not possible to clear (set to an empty string)
an item field.
This appended for field linked to an AV list but even if it's not.
The regex tried to prefix 'my_field' with 'items.' to have
'items.my_field'. It wanted to take care of the case where the prefix
already exists (Actually only 1: 'items.cn_source').
The regex is changed to: "add the prefix only if the string does not
contain a dot".
Moreover an ambiguity existed on the prefix: in marc_subfield_structure,
the kohafield is prefixed, but not in the key of the hash sent to
ModItemFromMarc.
Test plan:
- edit an item, set a status that is controlled by an authorized value
examples tested: damaged, not for loan
- check the status saved correctly
- edit the item again, reset the status to empty
- check the status saved correctly
- edit the item again, reset fields, edit fields
- check the fields saved correctly
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
These 2 bugs are in conflict.
The first one always join the issue table, the second one join on this
table too if the OnSiteCheckouts pref is enable.
So DBI raises an error if the pref is enabled (2 joins on the same
table).
This patch removes the conditional join.
Test plan:
Go on a detail record page with items and verify that items are list and
that the error no more appears in the log file.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Reproduced the problem, the patch fixes it, no noticeable regression found.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, items are visible again.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No commit message
No test plan.
No regressions found on opac/staff item display
No improvements either, but could be just my test data
No koha-qa errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Passes tests and QA script.
Tested detail and item pages in OPAC and staff, no regressions found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In inventory results, CSV or screen, the item withdrawn information is missing.
This information can be usefull to understand why an item was not scanned.
Test plan :
- Check you have in default framework an item subfield mapped with items.withdrawn
- Create a biblio with default framework
- Create an item with barcode='000AAA1', callnumber='ZZZAAA1' and withdrawn=0
- Create an item with barcode='000AAA2', callnumber='ZZZAAA2' and withdrawn=1
- Go to inventory tool : /cgi-bin/koha/tools/inventory.pl
- Enter item callnumber between 'ZZZ' and 'ZZZZ'
- Submit
=> You see a column 'Withdrawn' with withdrawn value
- Go to inventory tool : /cgi-bin/koha/tools/inventory.pl
- Enter item callnumber between 'ZZZ' and 'ZZZZ'
- Check 'Export to CSV file'
- Submit
- Open exported file
=> You see a column 'Withdrawn' with withdrawn value
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
package Koha::Item::Search::Field
function C4::SQLHelper::GetColumns
function C4::Items::SearchItems
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Tests run without error
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Item search is available at catalogue/itemsearch.pl (link is in
catalogue/search.pl)
It only uses SQL (not Zebra)
* Use DataTables and server-side processing to be able to filter on
individual columns after the first search is done.
* Allow to export results in CSV
* With Javascript disabled, search form still works (and CSV export too)
There is the possibility to define "Custom search fields" in a new admin
page admin/items_search_fields.pl (link is in admin/admin-home.pl)
A custom item search field is defined by:
* a name: its unique identifier
* a label: the text displayed to the user
* a MARC field/subfield: the field/subfield to query (it uses
ExtractValue)
* an authorised values list (optional): if defined the list is displayed
in the search form
New Perl dependency: Template::Plugin::JSON::Escape
Test plan:
1/ Apply the patch and run updatedatabase.pl
2/ Go to advanced search (staff interface), then click on "Go to item
search"
3/ Play with the search form! :)
In the 3rd fieldset you can add as many fields as you want and combine them with
boolean operators (AND, OR). You can use SQL jokers characters (%, _)
You can output to screen (in a DataTables table) or to a CSV file.
4/ In the DataTables table, play with filters and try sorting columns.
5/ Disable Javascript (with Firefox: extensions NoScript or YesScript,
or in about:config 'javascript.enabled' = false
6/ Reload the search page and do some searches on screen output. (there
is no sorting or filtering features, but there is still pagination)
7/ Try again CSV output.
8/ You can re-enable Javascript.
9/ Go to Administration > Items search fields
10/ Add a new field. Example for title (in UNIMARC):
Name: title
Label: Title
MARC field: 200
MARC subfield: a
Authorised values category: None
(add another field with an authorised values category to see the
difference).
11/ As you are there try to update and delete some fields.
12/ Go back to items search form. You can see in the 3rd fieldset that
your fields have appeared in the selects.
13/ Try searching on them.
14/ I think you're done :)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. Good new option.
No koha-qa errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
- capitalization fix "Checked out"
- display new tabs only when feature is activated
- fixes a qa script complaint about POD in Items.pm
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch implements the In-House Use feature for Koha.
It adds:
- 2 new sysprefs:
'In-House Use' to enable/disable this feature
'In-House Use Forced' to enable/disable the feature for *all* users.
- 2 new columns issues.inhouse_use and old_issues.inhouse_use
- Datatable on the circulation history pages (readingrec) at the OPAC
and the intranet.
A new checkbox in the Circulation tab. If checked, the issue become a
in-house use (in the statistics and issues tables).
When you check it, the due date changes to the today date.
The syspref "In-House Use Force" allows to force the in-house use to
permit the checkout even if the borrower is debarred or others problems.
In the issue table, a new string (in red) marks the issue as "in-house use".
The circulation history contains 3 tabs : "all", "checkout" and
"in-house use" (OPAC and intranet).
The cronjob script:
If AutomaticItemReturn if off, a library would like not to do a transit
operation manually. This script (to launch each night) do returns
for a specific branches.
Test plan:
1/ Execute the updatedatabase entry
2/ Enable the 'In-House Use' pref.
3/ Checkout a biblio for a patron and check the 'in-house use' checkbox.
4/ Check that the due date is the today date (with 23:59) and is not modifiable.
5/ Click on the check out button and check that the new check out
appears in the table bellow with the "(In-house use)" string.
6/ Go on the circulation history pages (readingrec and opac-readingrec)
and try the 3 tabs. In the last one, your last checkout should appear.
7/ Check in.
8/ Check readingrec pages.
9/ Choose a debarred patron and check that you cannot checkout a biblio
for him.
10/ Switch on the 'In-House Use Forced' pref
11/ You are now allowed to checkout a biblio for the debarred patron.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If an item is edited and a field is not mapped to Koha, it is to 0 or
NULL (depending on the default value defined).
This patch adds a check on the mapping before editing the item. It there
is no mapping, the DB value is not erased.
Test plan:
1/ Edit an item and fill a value for a field
2/ Unmap this field
3/ Edit the item
4/ Verify that the value is not erased (using the MySQL CLI)
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes the commented line for permanent_location.
It adds a more general comment.
Adjusts the exists check on permanent_location.
Adds a reference to bug 12817 that will deal with paidfor similarly.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
A quick fix to prevent more damages.
No perceived side-effects so far.
Signed-off-by: David Cook <dcook@prosentient.com.au>
This is actually a perfectly good fix for this issue. I've changed
the explanatory comment to explain why.
Another option would be to remove the 'exists' check in the sub
_do_column_fixes_for_mod(), but this is just as functional.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Detailed comment on Bugzilla.
Adding a small follow-up.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The cronjob longoverdue.pl does not require that an item marked as lost
be returned automatically, but there is a line in ModItem that
automatically marks the item's onloan as false if itemlost is set!
Test Plan:
1) Mark an item as lost with longoverdue.pl, without --mark-returned
2) Inspect the db, note that items.onloan is now 0
3) Apply this patch
4) Mark repeat step 1
5) Inspect the db, noe that items.onloan is still 1
6) Test marking an item as lost from staff interface,
ensure there are no regressions.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patch works according to test plan and fixes a data loss bug.
Some notes:
- This patch would be nicer with a regression test.
- Also checked that returning the item removes lost status and onloan still.
- Tried to test with --mark-returned, but couldn't get it to
return my item neither with nor without the patch. (see comment on
bug report)
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes only instance in this file
To test:
1. Apply the patch
2. (Esay way) Put on staff URL
/cgi-bin/koha/services/itemrecorddisplay.pl?biblionumber=N&itemnumber=M
3. Code replaced corresponds to pulldowns, verify information
is correct (check with another item edit view)
PrepareItemrecordDisplay() in Items.pm is filled with chunks of
HTML code that must be put on TT file. For now scrolling_list
is the only removed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested different item edit displays and the URL given above,
no regressions found. Also passes all tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
DelItem should return 1 if the item has been deleted, otherwise 0.
Test plan:
Verify that t/db_dependent/Items/DelItem.t returns green
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To delete an item, only the itemnumber should be mandatory. The DelItem
routine can retrieve the biblionumber from the itemnumber.
Test plan:
Verify that t/db_dependent/Items/DelItem.t passes
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since C4::Context->dbh shares the DB handler, it's useless to pass it to
routines.
Test plan:
Try to remove an item from the Koha interface.
Verify that unit tests pass.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch fixes some potential SQL syntax errors, which can cause
fatal software errors in Koha when the environmental variable DEBUG
is on.
_TEST PLAN_
Before applying:
0) Ensure that you don't have "SetEnv DEBUG 1" in your Apache config
1) Create a new bib record
2) Click on the "Holds" tab before creating any items
3) Note the message "Cannot place hold: this record has no
items attached."
4) Add "SetEnv DEBUG 1" to your Apache config
5) Restart Apache
6) Refresh your page
7) Note the following Software Error: "DBD::mysql::st execute failed:
You have an error in your SQL syntax; check the manual that
corresponds to your MariaDB server version for the right syntax to
use near ')' at line 3 at /koha/lib/C4/Koha.pm line 835.
8) Apply the patch
9) Refresh your page
10) Note the message from Step 3
Thorough tester:
11) Remove "SetEnv DEBUG 1" from your Apache config, restart Apache,
and refresh your page. You should see the message from Step 3.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Error reproduced, patch fixes it.
Tested following test plan, no koha-qa errors.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The changes made by Bug 7720 ("Ambiguity in OPAC Details location")
broke the display of OPAC branch information tooltips by making changes
to the markup which the tooltip plugin needs to function.
This patch corrects the markup to enable tooltips to work again. This
patch also makes changes to Items.pm so that branch information tooltips
can be shown for both home and holding branches (which are optionally
displayed now via the changes by Bug 7720). Before this patch the
tooltip would always display the information for the holding branch
regardless of the OpacLocationBranchToDisplay setting.
This patch also changes the footer include, adding an alias for the
jQueryUI tooltip function to prevent conflict with Bootstrap's function
of the same name.
To test, you must have at least two libraries configured with "OPAC
info" for display in the OPAC.
Modify the holdings of a title so that there is at least one item which
has different holding and home branches matching your library configured
above.
View the detail page for that record under various values of the
OpacLocationBranchToDisplay system preference:
- "holding library" : The table of holdings should show a column for
only the holding library. Hovering your cursor over the library name
should display the branch information you configured for that library
in a tooltip .
- "home and holding library" : The table of holdings should show columns
for both home and holding library. Hovering your cursor over each
should show the corresponding library information tooltips.
- "home library" : The table of holdings should show a column for
only the home library. Hovering your cursor over the library name
should display the branch information you configured for that library
in a tooltip.
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes QA script and tests.
Works with all settings of OpacLocationBranchToDisplay.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The QA follow-up which adds GetURL to the TT branches
plugin means that GetItemsInfo no longer needs to be changed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
[1] Fix capitalization
[2] Move logic for getting the home library name URL to the
Branches TT plugin
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Currently, in opac-detail.pl, there exists a column named 'Location'.
This column lists the name of the holding branch, and the item's
location description. This can cause confusion to borrowers, as
they may assume that the holding branch is the *owning* branch
(homebranch) of an item.
This could cause a situation where a borrower waits for an
item to be returned to his or her library, only to find that
the library never owned that item, and it was transferred back
to its homebranch. It could also lead a borrower to falsely
assume that his or her home library does not own a copy of a
particular item because the borrower does not see an his or her
home library listed for any of the items on the record.
In addition, even when the holding branch is different
than the home branch, the item's shelving location is displayed,
even though that branch may not use that location.
This commit makes the item details table equivalent to the intranet
details page by adding a "Home Library" column, which displays the
item's home library, as well as the shelving location.
If singleBranchMode is enabled, this column disappears and the
"Location" column displays the shelving location only.
This commit adds two new system preferences:
OpacLocationBranchToDisplay, which defines whether
to display the holding library, the home library,
or both for the opac details page.
OpacLocationBranchToDisplayShelving, which defines
where the shelving location should be displayed,
under the home library, the holding library, or both.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described. Tested all variations.
No koha-qa errors.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In serials/serials-edit.pl, if an item field is hidden from the OPAC,
it will not display in the editor, even if the field is marked as
visible in the staff intranet and editor. However, the field is still
displayed correctly in the items editor ( additem.pl ).:
Test Plan:
1) Select an item-level field ( e.g. non-public note )
2) Create a serial using the default framework ( or one of your choice )
3) For that framework, mark the chosen field as visible from the
intranet and editor, but not the opac.
4) Receive an item for this serial, note your field does not display
5) Use the biblio item editor to add an item ( additem.pl ), not the
field displayes
6) Apply this patch
7) Repeat step 4, not the field displayes
Signed-off-by: Kim Schwant <kim.schwant@courts.in.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
PrepareItemrecordDisplay is only used for editor (-4 < hidden < 4)
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This is just some code cleanup, no behavior change expected.
Also replacing errstr with err in testing the results. (See DBI.)
Test plan:
Modify an item and save it.
Followed test plan. No problems found.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds the words 'biblio' and 'item' to the 'info'
of the cataloguing logs which were missing them (such as biblio
delete, biblio mod, item mod, upload cover image).
This patch also adds 'authority' for authority mod.
_TEST PLAN_
Before applying:
1) Create/view mods for items, biblios, and authorities.
2) Create/view biblio deletion
3) Create/view upload cover image log
4) Note that none of these contain the words 'biblio','item',or
'authority' in their "Info" columns.
Apply patch.
5) Repeat steps 1-3
6) Note that the new logs contain 'biblio','item', and 'authority'
in their "Info" column, while the past ones don't.
7) Note also that 'biblio' and 'item' will have 'Biblio' and 'Item'
appear in their "Object" column for the new logs
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The method of checking the logged in user for superlibrarian privileges
is obtuse ( $userenv && $userenv->{flags} % 2 != 1 ) to say the least.
The codebase is littered with these lines, with no explanation given. It
would be much better if we had one subroutine that returned a boolean
value to tell us if the logged in user is a superlibrarian or not.
Test Plan:
1) Apply this patch
2) Verify superlibrarian behavior remains unchanged
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on second patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In C4::Items::DelItemCheck, there are two SQL queries: one to check
if item is on loan, the other if item is reserved.
Those two queries use "SELECT * FROM table", fetch the data with
"$var = $sth->fetchrow", and use "$var" as a boolean condition.
This is not correct, SQL query should be "SELECT COUNT(*) FROM table".
As a consequence, it was possible to delete an item without warning to
the operator even if it was waiting on the hold shelf or in transit to
fill a hold.
This patch corrects the SQL queries and sets my ($var) to show that
fetchrow returns an array.
Test plan :
- Set an item A onloan
- Set an item B reserved and the reserve waiting
- Go to items cataloguing : cgi-bin/koha/cataloguing/additem.pl?biblionumber=XXX
- Try to delete item A
=> You get an alert and item is not deleted
- Try to delete item B
=> You get an alert and item is not deleted
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Works, and has the added bonus of being a tiny bit faster.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes t, xt and QA script tests.
Also tried deleting via batch delete - correct warnings are displayed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When item is transfered from items table to deleted items, all fields
must be copies but "timestamp".
This value must be updated to know when the item was deleted.
Test plan:
- Look a an item timestamp :
mysql> select timestamp from items where itemnumber = 2690;
+---------------------+
| timestamp |
+---------------------+
| 2011-09-09 15:30:21 |
+---------------------+
1 row in set (0.00 sec)
- Delete this item in cataloguing module
- Check it is not in items table anymore :
mysql> select timestamp from items where itemnumber = 2690;
Empty set (0.00 sec)
- Look in deleteditems table :
mysql> select timestamp from deleteditems where itemnumber = 2690;
+---------------------+
| timestamp |
+---------------------+
| 2013-12-05 15:33:20 |
+---------------------+
1 row in set (0.00 sec)
=> timestamp as been set to actual date/time
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Patch set passes koha-qa.pl, works as advertised!
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This is supplementary to the main patch for
bug 6331. Having removed the attribute marc from
items DelItem, we should not try to populate it.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Add date fields to track when an item was marked as lost or withdrawn.
Display those fields on catalogue/moredetail.pl
Test Plan:
1) Apply patch
2) Run updatedatabase.pl
3) Pick a record with items, browse to the 'items' tab ( moredetail.pl )
4) Mark an item as lost, verify the field "Lost on:" displays below
the "Lost status" field with todays date.
5) Mark the item as not lost, verify the field no longer displays
6) Repeat steps 4 and 5 with the Withdrawn field.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Mandatory item fields are not indicated the same way in all places. This
patch corrects two places where required fields were shown in bold
rather than using the standard "required" class: When adding an order
from a staged file and when adding an item for a new issue of a serial.
This patch also normalizes the text input size on item entry forms: In
some places it was 50, others 67. I have changed the latter to 50.
Unrelated changes: Added $KohaDates formatting of date and time and
corrected capitalization on a heading on the add order from staged file
page.
It would be nice to be able to use the same method for displaying the
item form as we use on neworderentry.tt -- pulling in the form from a
separate include. However that system is designed for handling multiple
items and would need to be adapted for these cases.
To test, you must have a staged file from which to add an order. Open an
existing basket or create a new one and choose to add an order "From a
staged file." Choose a staged file from which to order. The item entry
form under the "Import all" heading should show required fields in red.
To test in serials: Begin the process for receiving an item from an
existing subscription. On the serials-edit page, find the "Click to add
item" links and click to open the item edit forms. There should be one
under the numbered issue and the supplemental issue forms. In both cases
the item edit screen should show the mandatory item fields in red.
Confirm that the cataloging add item form looks correct and works
correctly.
Revision: Left out the "required" note which should appear after each
required field.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The clear js function parses input text, but input filled to a plugin
does not contain the type attribute.
Test plan:
- fill the barcode field to the barcode plugin
- go on the new order page
- verify the barcode plugin works as before
- verify the clear link clears the barcode field and all others fields.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as expected, passes all tests and QA script.
Template change only.
Barcode and date acquired are now also cleared with the
'clear' link.
But: it only works when you enter a barcode manually currently,
because the AutoBarcode functionality is broken on master (bug 11273).
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This followup fixes some QA issues:
- replace the MySQLism SQL_CALC_FOUND_ROWS
- use Koha::DateUtils instead of C4::Dates
- replace "branch" and "location" with "library"
- fixe wrong capitalisation on "Clear all" and "Select all"
and fixes some behaviors:
- the inventory tools can be used without barcode file (fixed for the
csv export too).
- mark as not scanned a non scanned item.
- update the datelastseen 1 time per biblio (and fixes the displayed
count)
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Koha Team Amu <koha.aixmarseille@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
* when a file was uploaded and the comparison with catalogue range
requested, the comparison was wrong: the logic was wrong
* items that were not supposed to be scanned (ie: supposed to be on another shelf)
didn't had the author and title, it was hard to retrieve them on the shelved
* some useful fields were missing, like homebranch, location, status
* the CSV export contained all the item information. It should contain the same
informations as the screen
Behaviour now:
* scan a list of barcode & select a range of location
* if a barcode has been scanned and should not be (misplaced item),
the information is displayed
* if you choose "compare barcodes list to result option", the
resulting list contains all items that have been scanned and those
that were supposed to be. Any item not in both list appears with a
specific message on the last column
Signed-off-by: Leila <koha.aixmarseille@gmail.com>
Signed-off-by: Koha Team Amu <koha.aixmarseille@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
A lot of tests were just a call to a funtion without any arguments,
whereas the function expect at least one argument.
These tests were kept, but all return values are now undef when a
mandatory argument is missing, so return values are consistent.
The part where subscription periodicity is changed could not work
because of ',' appended to each key in ModSubscription call. So it's
rewritten, taking into account the new API for subscription frequencies.
This script should leave your database intact because it revert any
modification made.
Also fix some warnings in C4::Serials and in C4::Items.
And fix a typo in koha-tmpl/.../subscription-numberpatterns.tt
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described. No errors
Tested, again, without trouble.
With a suscription, tests successful.
No koha-qa errors
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a renewal tool that functions similar to the returns where a
librarian can continuously scan items for renewal. This script blocks
renewals that are impossible, and allow the same renewal overrides
as circulation.pl
Test plan:
1) Apply the patches for bug 8798
2) Apply this patch
3) Browse to /cgi-bin/koha/circ/renew.pl
4) Enter an invalid barcode, you should get an error message
5) Enter a valid, but not checked out barcode, you should get an error
message.
6) Enter a valid barcode that is checkout out and should be renewable,
you should get a success message.
7) Enable AllowRenewalLimitOverride
8) Enter a barcode for an item that has been renewed too many times
9) You should get a warning which you can override.
10) Disable AllowRenewalLimitOverride
11) Repeat steap 8
12) You should get a blocking error message
11) Enter a barcode for an item with unfilled holds on it,
you should get an overridable warning
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Passes all tests and QA script, some issues have been
addressed in follow-ups.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds several unit tests for GetHiddenItemnumbers and fixes the POD for it.
It also wraps the tests for rollback, modernizes and adds a license text to it.
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
There should be a:
"require YAML;"
or
"use YAML qw/Load/;"
as the GetHiddenItems routine has a reference to YAML::Load.
This was discovered while adding a GetHiddenItems() call into
opac/opac-MARCdetail.pl. I believe this problem dates back to
bug 6488 or bug 5984.
I also added an optimization to GetHiddenItems to prevent
processing if there is nothing in the system preference. Test
by searching for a biblio which has some or all of its items
hidden.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Maybe
return () unless $yaml =~ /\S/;
or
return () if $yaml =~ /^\s*$/;
would have been easier to read.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch updates the wthdrawn field in items and deleteditems to be
withdrawn instead. No functional changes are made.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Save for translation files (that will be fixed on next release),
only occurrence of wthdrawn is on updatedatabase.pl
No koha-qa errors.
This touch many files, and I did not test everything,
but all seems normal. I think that any problem could
be fixed later.
Perhaps both entries in updatedatabase.pl could be joined
into one, but thats for QA.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch updates the example template syntax in the POD for
C4::Items::GetItemStatus() to use Template Toolkit syntax.
To test, view the POD for C4::Items::GetItemStatus() and confirm that it
looks correct.
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
This patch works as advertised (verified with "perldoc C4::Items"),
for GetItemStatus, but it does not fix a a similar example for
GetItemLocation in the same file, which still has the old template
syntax. So a followup or separate bug for that is called for.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
It seems the default option is not in used in templates.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test Plan:
1) Enable IndependantBranches
2) Apply this patch
3) Run updatedatabase.pl
4) Verify that the system preference still functions correctly
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Simply revert order of 2 lines in Items.pm. Previous line write to
variable used in next line as function argument.
To Test:
Give an item a special restricted value, define one if you have to
in the authorised values.
Observe that, without this patch, statuses are not shown in the
OPAC in parentheses. My example was an item that had a restricted
value of "Library Staff Only"
It should have been shown under status on the detail page of the
OPAC, but was not.
Apply the patch, observe that restricted values are now shown
for your item, for example:
Available (Library Staff Only) in the status column.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and test plan.
Simple change fixing a display problem, no string changes.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test Plan:
1) Enable IndependantBranches
2) Set HomeOrHoldingBranch to holding branch
3) Delete an item whose holding branch is your logged in branch, and
whose home branch is not
4) Apply this patch
5) Repeat step 3, it should fail
6) Try to delete another items whose home branch is your logged in
branch, and whose holding branch is a different branch. This
deletetion should succeed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Change is logical, only homebranch should determine if the item
can be deleted.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The SQL query build in C4::Items::_koha_modify_item performs an update on a row of items table identified by itemnumber.
Actually the query is build using a hash of datas :
for my $key ( keys %$item ) {
$query.="$key=?,";
push @bind, $item->{$key};
}
But this hash contains 'itemnumber' key, so you get an update including the primary key.
It is actually harmless but may be dangerous.
This patch simply skips itemnumber key in above loop.
Test plan :
Check you can create and modify items.
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>
Bug 9902 introduced an issue in the C4::Items::PrepareItemrecordDisplay
routine. The existence of $defaulvalue hashref should be tested before
getting to the branchcode key.
Test plan:
Before applying the patch, an error occurred when you try to create an
order from a staged file.
After applying the patch, the error does not appear anymore.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test Plan:
1) Create a new serial with a default location, call number, and library
( the library will need to be any but the one you are logged in as )
2) Click the "Recieve" button for this serial
3) Click "Click to add item"
4) Note those values are not populated
5) Apply the patch
6) Reload the page
7) Click "Click to add item"
8) Note those values are now populated
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
All tests pass!
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This seems to restore the former behaviour.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>