To test:
1. apply patch
2. enable housebound module
3. go to a patron and look at the housebound tab
4. Edit the detials.
5. The preferred materials, subjects, authors, referral, and note inputs should be replace with much larger textareas.
6. You should now be able to added line breaks, so fill out each of the fields adding some line breaks. I added something like:
Fiction authors: Frank Herbert
Non-fiction authors: Malcolm Gladwell
7. Save changes
8. Now when you look at the housebound details those line breaks should be preserved and much easier to read.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1. have some overdues
2. go to the overdue report on the circulation page (overdue.tt)
3. no shelving location
4. apply patch and restart the things
5. look at the overdue report again and there should be a Shelving location column
6. make sure it is accurate
7. go to table settings and make sure you can properly hide the column. test other columns in the table and make sure they are still hiding correctly as well
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
RSS feeds are now generated using opac/opac-search.pl (format=rss).
But prior to
commit 09df0de35f
Removing obsolete RSS <link> tags and the scripts
it was using opac/opac-rss.pl, which used opac/rss
The directory should have been removed by this commit.
Test plan:
Confirm that this directory is useless and can be removed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We always had some mapping because of the DB vs. API object definition discrepancies. But bug 25260 revamps the reserves table, and it is a perfect match. It highlights this edge case: if no mapping defined, then and undef from_api_mapping is generated (as opposed to an empty hashref) and this leads to errors in the query translation from the API.
This patch makes a small change so this method always returns an empty
hashref.
To test:
1. Apply the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object.t
=> FAIL: Test fail!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
JD amended patch: remove uneeded commented lines
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds tests for the following cases:
- to_api_mapping not defined
- to_api_mapping returning an empty hashref
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object.t
=> FAIL: Tests fail :-(
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
JD amended patch: remove uneeded commented lines
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch modifies the holds template so that during the
multi-hold process, titles with no items attached are treated the same
way as titles with no items available (items exist but cannot be place
don hold):
- The row showing such a record will say "No items are available to be
placed on hold."
- The pickup location dropdown will be hidden.
To test, follow the previous test plan and confirm that these change are
reflected. Now that the pickup location field isn't present for titles
without items you should be able to complete the holds process.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Revised test plan from Owen:
This patch modifies the hold process so that if one of the titles in a
multi-hold process has no items the process doesn't abort completely.
To test, apply the patch and perform a search in the catalog which will
return one or more records with no items attached.
- Check checkboxes for multiple results, some of which have items and
at least one of which has no items.
- Click "Place hold."
- You should be taken to the page for placing multiple holds, with a
heading, "Cannot place hold on some items."
- Note: You will not be able to complete the holds process without the
next patch.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If you select multiple titles on the search results page in order to
place a bulk hold and some of those titles have no items you get a
JavaScript alert warning you can some cannot be placed on hold. You are
blocked from completing the action until you deselect the invalid hold.
This is unnecessary because the bulk hold process will safely refuse to
place a hold on these titles later in the process.
This patch removes the check that prevents submitting a multi-hold if
one or more records in the multi-hold have no items.
Test plan:
1) Apply patch
2) On the staff interface, do a search
3) On the search results, select at least one record with items and one
record with no items.
4) Click the 'Place hold' button.
5) You should be redirected to reserve/request.pl with the message
"Cannot place hold: this record has no items attached."
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Actually looking at a record search or details, we see a black label
(for example "Author:") and a grey metadata (for example "J.R.R Tolkien").
Seems bad for accessibility.
In my opinion the most important to see is the metadata not the label.
It is possible to change with a custom CSS but I open this report to
propose to change default display.
Test plan :
1) Apply patch and build CSS in OPAC and staff interface
2) Search for any record in OPAC/Staff interface
3) You see grey label and black metadata
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Fixes where sort on lib breaks the test.
Also removes useless params in search_by_koha_field()
Run prove t/db_dependent/AuthorisedValues.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In itemsearch form, the item types filter should be sorted by description.
Test plan :
1) Create several values and descriptions in item types
2) Go to itemsearch
3) See filter by item types sorts on description and not on value
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In itemsearch form, there are several filters build with authorized values.
There values should be sorted by description.
Test plan :
1) Create several values and descriptions in authorized values LOC
2) Go to itemsearch
3) See filter by location sorts on description and not on value
Seems change in search_by_marc_field can not be tested in interface
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1- Create a notice with a 700$a and 700$d
2- Click on 700 $a field Tag Editor
3- Only 700$a is copied in search windows eg /authorities/auth_finder.pl pop up
4- Apply patch
5- Redo 2
6- 700$a is copied in 'Search main heading ($a only)' and $d is copied in 'Search main heading'
Signed-off-by: George Veranis <gveranis@dataly.gr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
'Can't locate object method "_new_from_dbic" via package "Koha::Linktracker" (perhaps you forgot to load "Koha::Linktracker"?) at /kohadevbox/koha/Koha/Object.pm line 334.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Potentially we could have logged a change when no date was passed.
This patch moves the test before logging and updates POD
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Abbey Holt <aholt@dubuque.lib.ia.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are times when an item that is waiting for pickup needs to have the expiration date extended. This would give staff the ability to modify one by one, as needed, the reserves.expirationdate for a given item awaiting pickup.
Test Plan:
1) Place a hold, trap an item for it such that is is waiting
2) Attempt to update the expiration date
3) Note the new date is not saved
4) Apply this patch, restart all the things!
5) Attempt to update the expiration date
6) The new date should be saved!
Signed-off-by: Abbey Holt <aholt@dubuque.lib.ia.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
* C4/Items.pm
- Koha::Biblios not used
* Koha/Item.pm
- Koha::Item->orders must return an empty set if no order attached
- no_triggers should be passed to other update calls
* Item.t
- No need to build a fund
- Add new test to test Koha::Item->orders when no order attached
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds tests and handling for calling move_to_biblio on a
Koha::Items set that contains items from more than one source biblio.
Test plan
1/ Inspect the changes to t/db_dependent/Koha/SearchEngine/Indexer.t
2/ Run t/db_dependent/Koha/SearchEngine/Indexer.t and confirm it passes
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The $from_biblio variable name doesn't exists after a refactoring that
happened. Here we need to re-index both the $self biblio and $to_biblio
biblio.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds Koha::TrackedLink(s) classes based on Koha::Object(s)
and then adds the relationship accessor to Koha::Item and uses it within
the move_to_biblio method.
Tests for new relationship also added to t/db_dependent/Koha/Item.t
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
With the addition of foreign key relationships to the linktracker table
we now get a DBIC relationship accessor we can use. This clarifies the
code slightly by using the _result->relationship form to get the DBIC
resultset. We should still introduce a Koha::Object based class for
this table at some point.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch moves the Koha::Biblio->adopt_items_from_biblio method to the
Koha::Items set class and updates all calls from
Biblio2->adopt_items_from_biblio(Biblio1) to Biblio->items->move_to_biblio(Biblio2)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We need to pass undef itemnumber to build_object() to actually have a
hold without an item tied to it. Otherwise build_object() will create
automatically an item for us (thus making it an item-level hold)
To test:
$ prove t/db_dependent/Koha/Item.t
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We need to update the search index record for the old biblio where the
item was moved from to keep the item info in search index up-to-date.
To test:
1) $ prove t/db_dependent/Koha/SearchEngine/Indexer.t
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In our test setup we mock the index_records() to produce warnings like
this:
Koha::Item at t/db_dependent/Koha/SearchEngine/Indexer.t line
93.
By wrapping all our item creations to warnings_are{} we can silence them.
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
- Tests for adopt_items_from_biblio
- Tests for the relationship between items and acquisition orders
- Tests for indexer calls in adopt_items_from_biblio
Signed-off-by: Michal Denar <black23@gmail.com>
Rebased-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch allows merging of records with many items without the web server timing out.
Test plan:
Without the patch:
- Create 2 records (one with e.g. 1000 items).
- Do a cataloguing search that displays both records, select them and click "Merge selected".
- Choose the record with many items as the one to be eliminated.
- Start the merging.
- After a while the web server should give you a timeout error (the merging process may still continue)
With the patch:
- Do the same as above
- This time verify that the records are merged without timeout
- Create a new biblio with an item
- Add with the item:
* acquisition order
* hold (reserve)
- Merge the biblio to another one
- Verify that the item and its related data was moved
- Verify that tests pass:
prove -v t/db_dependent/Koha/Biblio.t
prove -v t/db_dependent/Koha/Item.t
prove -v t/db_dependent/Koha/SearchEngine/Indexer.t
Signed-off-by: Michal Denar <black23@gmail.com>
Rebased-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The ISBD view in the OPAC interface does not display item information.
This patch fixes that.
Test plan:
0) Have a biblio with at least one item attached to it and include one
of the following snippets in the OPACISBD system preference,
depending on your MARC flavour:
MARC21:
#952|<br/><h2>Items</h2><table><th>Copy number</th><th>Shelving
location</th><th>Koha item type</th><th>Barcode</th><th>Call number
(Full call number)</th><th>Materials specified (bound volume or
other part)</th>|<tr><td>{952t} </td><td> {952c} </td><td> {952y}
</td><td> {952p} </td><td> {952o} </td><td> {9523}</td></tr>|</table>
UNIMARC:
#995|<br/><h2>Items</h2><table><th>Copy number</th><th>Shelving
location</th><th>Koha collection</th><th>Barcode</th><th>Call number
(Full call number)</th><th>Numbering (volume or other part)</th>|
<tr><td>{9956} </td><td> {995e} </td><td> {995h} </td><td> {995f}
</td><td> {995k} </td><td> {995l}</td></tr>|</table>
Switch to the OPAC ISBD view for your biblio; notice how it does
not display item information.
1) Apply the patch, and restart Plack/memcached if necessary.
2) Refresh the OPAC ISBD view page, this time you should see item
information as per the OPACISBD system preference setting.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 23376 we replaced $order, from hashref Koha::Acq::Order, but 2
occurrences have not been corrected.
It causes a bug on the order receive page when the bib is linked with a
suggestion.
Test plan:
Create an order from bib A, create a suggestion for purchase on bib A
(OPAC)
Receive the order.
Without the patch: Notice the "Suggested by: (suggestion #)"
With the patch you see the info of the suggester
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Still found in opac-bottom.inc.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The previous patch removed search_boxes_loop - that's okay, it was always
getting the same three values.
If we don't do something in the template though, we get no boxes
Ultimately this should be a include, and not a hardcoded loop, but keeping changes
small for backporting
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It could lead to server freeze if set to a big value (we are pushing
into an array and so RAM is being fulfilled, and CPU is looping).
I don't understand the point of this cookie.
var numPar = $("#booleansearch fieldset p").size();
if (numPar > [% search_boxes_count | html %]){
jQuery.cookie("num_paragraph", numPar,{ path: '/'});
}else{
jQuery.removeCookie("num_paragraph", { path: '/'});
}
But "#booleansearch fieldset p" does not exist, it's not 'p' but 'div'
elements.
I've removed the code related to num_paragraph and the "Return to the
last advanced search" feature still works as before.
From this comment:
# determine what to display next to the search boxes (ie, boolean option
# shouldn't appear on the first one, scan indexes should, adding a new
# box should only appear on the last, etc.
The only bit that is not working as described is "adding a new box
should only appear on the last", but it has been working this way for
a long time already I think, and I don't see it as a bug.
Test plan:
Read the code, check that the above is correct.
Search for regression in this "return to last adv search" feature added
by bug 13307.
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>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
