Add RecordedBooks to the users page in the public interface
To Test:
1/ Apply all 3 patches
2/ Set the sysprefs to valid values (you will need a test account with RecordedBooks)
3/ Try a search
4/ Login to the OPAC, try to place a hold, or check an item out
5/ Check the opac-user page, see if your items are showing on the oneclickdigital tab
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
As requested by QA, we should move may_article_request out of Biblio.
For reasons of performance removed the wrapper layer of may_article_request
in opac-search. No need to look up all item types. For readability kept
the routine in the detail scripts.
Note for running ArticleRequests.t: A possible failure on the subtest
'search_limited' is addressed on bug 20866. So you can ignore that one.
As long as the subtest for may_article_request passes.
Test plan:
See previous patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
If you enable pref ArticleRequests, until now all search results got the
'Request article' link. This patch tries to improve the situation by
using the new sub with the itemtype of the search result.
In most cases the number of links will drastically decrease. It may still
be possible sometimes that a link is shown while it effectively is not
possible, but we do not get the performance burden of determining that and
going through all items.
Test plan:
[1] Look for two borrowers P1 and P2 within categories C1 resp. C2.
[2] Look for two biblios B1 and B2 with default item types I1 resp. I2.
(See 942c in case of MARC21.)
[3] Make sure that no circ rules allow article requests. Enable the pref.
[4] Add/modify circ rule category=C1, itemtype=I1, art_req=yes.
Log out. Search for B1 and B2, verify that only B1 has AR link.
Log in as P1. Verify that only B1 has AR link.
Log in as P2. Verify that no biblio has AR link.
[5] Add/modify circ rule category=C2, itemtype=I2, art_req=item_only.
Log out. Search for B1 and B2, verify that both have AR links.
Log in as P1. Verify that only B1 has AR link.
Log in as P2. Verify that only B2 has AR link.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This avoid hardcoding '10000' in two different places and allow users to
adjust this setting.
Also, this patch fixes a bug when the search return less than 10000
results
Test plan:
1. Do a search that returns 10000+ records.
2. Note the warning above the pagination buttons
3. Go to the last page, no error
4. Change the ES setting:
curl -XPUT http://elasticsearch/koha_master_biblios/_settings -d \
'{"index": {"max_result_window": 20000}}'
5. Do another search that returns more than 10000 but less than 20000
6. Note that the warning does not show up
7. Go to the last page, still no error
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
https://bugs.koha-community.org/show_bug.cgi?id=19502
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch is to avoid hitting an error page. We should eventually make the
max number returned configurable for ES.
To test:
1 - Have Koha running ES with 10,000+ records
2 - Search for '*'
3 - Click 'Last' to view last page of results
4 - 'Cannot perform search' error
5 - Apply patch
6 - Search again
7 - View 'Last' page
8 - No error, you go to the last of 10000
9 - Note the warning above the pagination buttons
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
In the last patches of bug 16735, we completely broke the feature!
The limit is using library_groups.id instead of branches.branchcode.
Test plan:
Create a group of library with the search feature
Search (OPAC and staff interfaces) using this limit
=> Without this patch you will see that the generated search query does
not contain branchcodes
=> With this patch applied you will see the branchcodes
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
- Create an entry for the ITEMTYPECAT authorised value category.
Make sure to fill in the OPAC description.
- Go to administration > itemtypes and add the new category to 2 item types.
- Go to the OPAC and check that the advanced search shows your new itemtype
group instead of the individual itemtypes.
- Check the checkbox and Search.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Case
1) Check that the following files have been changed properly.
opac/opac-search.pl
opac/opac-main.pl
koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-advsearch.tt
2)Apply bug
3) Check that there are no differences in behaviour as a result of the patch.
Signed-off-by: Roch D'Amour <roch.damour@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
ITEMTYPECAT permits to group and hide item types at the OPAC (see bug
10937 for a complete description).
Since commit 091d6c513b
Bug 17843: Replace C4::Koha::getitemtypeinfo with Koha::ItemTypes
the code assume that they are item types. Before it just assigned undef
to the description.
Test plan:
Create ITEMTYPECAT authorised values
Assign an item type to this authorised value group
Search for a item using this item type at the OPAC
Without this patch applied you get:
Can't call method "translated_description" on an undefined value at
/home/vagrant/kohaclone/opac/opac-search.pl line 231.
With this patch applied the search result is displayed.
Make sure the original feature still works.
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Instead of basing the group searches on the group name, which is an
inherently touchy system, we should use the same checkbox style that
Jonathan introduced for the patron limits by group feature.
Test Plan:
1) Check to ensure existing group searches still show as they used to
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1) Apply this patch set
2) Note your existing search groups have been ported over to the new
__SEARCH_GROUPS__ group if you had any
3) Create the group __SEARCH_GROUPS__ if one does not already exist
4) Add some first level subgroups to this group, add libraries to those groups
5) Search the library group searching in the intranet and opac
6) Note you get the same results as pre-patch
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This bug has certainly be caused by
commit 091d6c513b
Bug 17843: Replace C4::Koha::getitemtypeinfo with Koha::ItemTypes
The reason is quite simple, in Koha::ItemType->translated_description
(called in opac-search.pl l.229) there is an eval to know if we have
access to the translated description of the item type, to avoid
retrieving it again.
The evaluation of $@ later in opac-search.pl is supposed to test the 2
eval made few lines before (a "normal" search, without tags), but
$@ contains the error message from the *last* eval command.
So we are raising an error that have been correctly handled in
Koha::ItemType.
Test plan:
At the OPAC, click Tag cloud, then click any of the tags
=> Without the patch you get
Koha::ItemType::get_column generated this error: DBIx::Class::Row::get_column(): No such column 'translated_description' on Koha::Schema::Result::Itemtype at /usr/share/koha/lib/Koha/Object.pm line 307
=> With the patch applied the page is correctly displayed
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
OPAC: Both SearchEngine "Elasticsearch" and "Zebra" should work with
OpacSuppression set to "yes"
NB: OPAC suppression is not implemented for Elasticsearch
Signed-off-by: David Bourgault <david.bourgault@inlibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Have changed
my $last_page = $pages * ( $results_per_page - 1 );
to
my $last_page = ( $pages - 1) * $results_per_page;
which seems to fix the 'last' button offset! (Comment 10)
Will add the box to jump to a page in a separate patch.
Adding the pagination to the top on the staff client will be dealt with
in Bug 18916 as it is slightly out of the scope of this bug.
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
See Comment 8.
Test:
When on first page of results, confirm that the 'First' and 'Previous'
buttons do not show. Confirm they come back on the second page and every
page after.
When on last page of results, confirm that the 'Last' and 'Next' buttons
do not show. Confirm they come back on all previous pages.
Check on both staff side and OPAC.
Sponsored-by: Catalyst IT
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Same fix but on OPAC side. Same test plan
Sponsored-by: Catalyst IT
Signed-off-by: Dilan Johnpulle <dilan@calyx.net.au>
Signed-off-by: Your Full Name <your_email>
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Change parameters to a hashref.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Looks good to me.
Two calls in migration_tools/22_to_30 still in old style.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Most of the time C4::Biblio::GetBiblioData is used to retrieve the title
and/or the author of a bibliographic record.
This patch replaces the easy occurrences of GetBiblioData, the ones
where the 2 joins are needed, but only data from biblio and biblioitems
table are.
Test plan:
It will be hard to test everything, I'd suggest a QAer to review this
patch and confirm that the difference occurrences of GetBiblioData have
been correctly replaced by calling Koha::Biblios->find or
$biblio->bibioitem
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There was a bug that meant a very large offset in the search params
will cause the search script to run forever (or long enough to crash
the machine)
To test
1/ Get ready with sudo top so you can kill the thread before it causes
your machine to OOM
2/ Hit a page like yourdomain.com/cgi-bin/koha/opac-search.pl?q=1&offset=-9999999999999999999
3/ Notice the process runs for a long time
4/ Kill the process
5/ Apply the patch
6/ Hit the page again, notice the it loads (offset is set to zero)
7/ Do the same to search in the staff client
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: changed -2 to 0 in opac-search.pl.
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The C4::Koha::getitemtypeinfo subroutine did the almost same job as
GetItemTypes. On top of that it returned the imageurl value processed by
C4::Koha::getitemtypeimagelocation.
This value is only used from the 2 [opac-]shelves.pl scripts. Then it's
better not retrieve it only when we need it.
Test plan:
Play with the different scripts touched by this patch and focus on item
types. The same description as prior to this patch must be displayed.
Note that sometimes it is not the translated description which is
displayed, but that should be fixed on another bug report. Indeed we do
not expect this patch to change any behaviors.
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
GetItemTypesCategorized can return descriptions that are still undef since
Authorized values does not enforce a description in lib and lib_opac.
When I add one ITEMTYPECAT auth value without descriptions, I can still
generate the string comparison warnings on the itemtypes sort.
In order to prevent the warning, we should add an empty string in the
assignment on line 229.
We do not need to copy the itemtypes hash if we move the sort outside the
@advanced_search_types foreach. There is no need to sort it more than once.
Note that I did not see any reasons btw for corruption of the structure
inside this loop.
Note: If we use ITEMTYPECAT without descriptions, we should probably leave
them out. No need to show a checkbox without description on Advanced Search,
but I would recommend to solve that on its own report. The whole ITEMTYPECAT
functionality has imo not been designed properly.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To fix the warns we use a copy of itemtypes which is not touched by
other code
To test:
Apply patches
Ensure search still works
Followed test plan, search works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Resolves:
Global symbol "$itemtypes_nocategory" requires explicit package name.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested the added line with a debug statement. See itemtype facets in the
search results.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::Koha::GetItemTypesByCategory can be easily replaced with
Koha::ItemTypes->search({ searchcategory => ? });
So let's replace it where it is used.
Test plan:
Make sure this patch does not break the test plan of bug 10937
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
-Search in OPAC for two or more items
-Note that item types display category codes rather than names
-Make change to file and test in OPAC
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Two discussions on koha-devel lead to the same conclusion:
biblioitems.marcxml should be moved out this table
- biblio and biblioitems
http://lists.koha-community.org/pipermail/koha-devel/2013-April/039239.html
- biblioitems.marcxml & biblioitems.marc / HUGE performance issue !
http://lists.koha-community.org/pipermail/koha-devel/2016-July/042821.html
There are several goals to do it:
- Performance
As Paul Poulain wrote, a simple query like
SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP BY publicationyear;
takes more than 10min on a DB with more than 1M bibliographic records
but only 3sec (!) on the same DB without the biblioitems.marcxml field
Note that priori to this patch set, the biblioitems.marcxml was not
retrieved systematically, but was, at least, in
C4::Acquisition::GetOrdersByBiblionumber and C4::Acquisition::GetOrders
- Flexibility
Storing the marcxml in a specific table would allow use to store several
kind of metadata (USMARC, MARCXML, MIJ, etc.) and different formats (marcflavour)
- Clean code
It would be a first step toward Koha::MetadataRecord for bibliographic
records (not done in this patch set).
Test plan:
- Update the DBIC Schema
- Add / Edit / Delete / Import / Export bibliographic records
- Add items
- Reindex records using ES
- Confirm that the following scripts still work:
* misc/cronjobs/delete_records_via_leader.pl
* misc/migration_tools/build_oai_sets.pl
- Look at the reading history at the OPAC (opac-readingrecord.pl)
- At the OPAC, click on a tag, you must see the result
Note: Changes in Koha/OAI/Server/ListRecords.pm is planned on bug 15108.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Zeno Tajoli <z.tajoli@cineca.it>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If the period is entered without spaces wrapping the hyphen
You can't get any result
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
I can't reproduce the error, search still works after applying the patch
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This new enhancement will allow to add the name of lists containing a
biblio to the search results at the OPAC.
Test plan:
0/ Regenerate the css file to get the style change:
% lessc --clean-css="--s0 --advanced --compatibility=ie7"
koha-tmpl/opac-tmpl/bootstrap/less/opac.less >
koha-tmpl/opac-tmpl/bootstrap/css/opac.css
1/ Create some lists and add items to them
2/ On the search results you should see the name of the lists which
contains the record.
Note that we could add a syspref to make this new behavior optional.
Sponsored-by: University of the Arts London
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
By default ES returns the facet terms ordered by most used, which makes
sense.
This patch removes resort done in the scripts (catalogue/search.pl and
opac/opac-search.pl) and moves it to the module.
For Zebra it's now done in C4::Search::getRecords, and there is no
change to expect (still alphabetically).
On the Elastic search side, we could imagine to let the library define
the order of the facets. The facet terms are now sorted by most used.
To test easily this change, turn on the displayFacetCount pref.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This reverts commit cd4905c2969b067476881016d0b03271f0bcc7c8.
This commit caused an error in C4::Search::GetFacets when running in
zebra mode.
Conflicts:
Koha/SearchEngine/Elasticsearch/Search.pm
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
The system preference FacetMaxCount should work as expected with ES.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
By default ES returns the facet terms ordered by most used, which makes
sense.
This patch removes resort done in the scripts (catalogue/search.pl and
opac/opac-search.pl) and moves it to the module.
For Zebra it's now done in C4::Search::getRecords, and there is no
change to expect (still alphabetically).
On the Elastic search side, we could imagine to let the library define
the order of the facets. The facet terms are now sorted by most used.
To test easily this change, turn on the displayFacetCount pref.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This allows sorting to be configured within a field. For example, while
many values are included for search on author, sorting should only be
done on the main entry values. This permits that by have a sort value,
which can be true, false, or null. true and null are pretty much the
same, but false means that a field isn't available for sorting on. By
default (null), fields can be sorted on.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
(Not fetched yet though.)
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
From C4::Koha::GetAuthorisedValues
# TODO: the "selected" feature should be replaced by a utility function
# somewhere else, it doesn't belong in here. For starters it makes
# caching much more complicated. Or just let the UI logic handle it, it's
# what it's for.
Indeed, it's not a job for a subroutine, the template should take care of that.
Note that a perf gain could be won with this patch \o/
Test plan:
- Edit an itemtype and check the value of the "Search category" dropdown list
- Edit a patron attribute type and check the value of the "Class" dropdown list
- Detail for a catalogue record, the Status column should be correctly
populated if items are damaged and/or lost
- Item details for a catalogue record, the lost, damaged and withdrawn
value should be correctly displayed
- Edit a patron, the "street type" should be correctly selected
- Create a patron attribute type linked to an authorised value list.
- Edit a patron, set a value for this attribute, edit it again. The
correct value should be selected.
- Search for subscriptions. The 'Location' dropdown list should behave
correctly (select the entry you have choosen before, etc.)
- Edit a subscription, the location dropdown list should select the
correct value.
- Edit and view a suggestion with a 'reason for suggestion' set (you
should have at least 1 OPAC_SUG AV defined)
Followed test plan, works as expected
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
* Use ->id instead of ->branchcode when possible to eliminate use of that nomenclature
* Fix bad use of ->branchcode to ->{branchcode} for unblessed hashref version of Koha::Library
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
C4::Branch::GetBranchesInCategory can be replaced with
Koha::LibraryCategory->libraries
Test plan:
1/ Define some 1+ group of libraries with 1+ libraries each
2/ Go on the advanced search (OPAC and Staff) and select a group of
libraries
3/ The result should be consistent and only include record from these
libraries
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
When searching for something in OPAC which doesn't result in any results but have utf-8
characters in search string we get following encoding error:
Cannot decode string with wide characters at /usr/lib/i386-linux-gnu/perl5/5.20/Encode.pm line 215.
This is because we are trying to decode string which is allready correctly
marked as utf-8.
Test scenario:
1) enter search string with utf-8 characters in opac which doesn't
return any results
2) verify that you get application error
3) apply this patch
4) re-run query and verify that errror is gone
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Step 0: Define "OPACNoResultsFound" with '{QUERY_KW}'
Note that I don't get the error (Encode 2.60) but the search terms are
not display correctly.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
The variable to be decoded comes from already decoded vars (via
the -utf8 flag from CGI), following the trail in Search.pm.
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
