GetNormalizedUPC duplicated logic already available via the
MetadataExtractor (Bug 34828) and exposed as $biblio->normalized_upc.
All callers migrated:
- Scripts with $biblio available: use $biblio->normalized_upc
- C4::Search (only MARC::Record): reuses the extractor instance
already created for OCLC
Assisted-by: Sonnet 4.6 (Anthropic)
Test plan:
1. Apply patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha.t \
t/db_dependent/Koha/Biblio.t
=> SUCCESS: Tests pass
3. Verify UPC numbers still display in OPAC and staff detail pages
(Syndetics cover images)
4. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Replaces all calls to GetNormalizedOCLCNumber() and
Koha::Util::MARC::oclc_number() with the extractor pattern.
OPAC scripts pass their already ViewPolicy-filtered $record directly
to the extractor. This preserves the existing filtering behavior
without introducing new abstraction layers:
Koha::Biblio::Metadata::Extractor->new( { metadata => $record } )->get_normalized_oclc
Intranet scripts and the Koha::Biblio convenience method use the
raw cached extractor (035 visibility is not affected by ViewPolicy
in practice, and intranet doesn't filter):
$biblio->normalized_oclc
Test plan:
1. Verify OCLC numbers display on OPAC detail, ISBD, MARC detail
2. Verify staff catalogue detail and search results
3. prove t/db_dependent/Koha/Biblio.t
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Assisted-by: Sonnet 4.6 (Anthropic)
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
1. Create a list
2. Sort this list by: title
3. Save
4. Edit the list, changing the the "Sort this list by:" to copyrightdate
5. Try to edit it again to any other type of sort. Save
6. Look again, it is reverted to copyrightdate
7. APPLY PATCH, restart_all
8. Now when you edit the list any value you use in "Sort this list by:" should be retained.
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
TEST PLAN (on an UNIMARC machine):
1 - Create a list with items with different publicationyear if you do not have one.
2 - Edit the list and select "copyrightdate as date"
3 - See they are not sorted by date
4 - Apply patch
5 - See they are now sorted by date.
Note: The transformation of copyrightdate before loading the template is
only useful if the list is sorted by copyrightdate, which is quite
inconsistent but is actual for every Kohas at the moment.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a new notice, TRANSFER_OWNERSHIP, under a new module,
Lists. When a list is transferred to a new owner, this notice is
triggered, containing a short paragraph detailing the list name.
TO TEST:
a) log in as a koha superlibrarian
b) go to the lists module, create a public list, and make a note of the
title used
c) on the lists module, transfer the list to some other user, and make
a note of the user used
d) go to the patron notices page for the user in step c
e) ensure that a notice has been generated
1) check the contents of the notice, it should contain
- the new owner's name
- the list's title
- the old owner's name & (if set) email
f) under tools > notices, modify the notice for TRANSFER_OWNERSHIP
g) repeat steps c-e
1) ensure the modifications you've made are now visible in the notice
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
GIVEN koha in a version later than 22.11, a list with more than ten entries
WHEN the user tries to print the list
THEN only the ten first results are printed
EXPECTED THEN all results are printed
It looks like it is an undesired effect of BZ36858. Page remains set
even while printing, therefore, however the number of rows is not set,
default value (10) is used.
TEST PLAN
1 - create a list with more than 10 items
2 - print the list -> there is a pagination and that only 10 items
are printed
Apply patch
3 - print the list again -> every items are being printed
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds two new system preferences, use public lists, and create public
lists. Use public lists determines if a librarian is permitted to see public
lists, whilst create public lists determines if a librarian can create new public
lists.
It also fixes erroneously allowing staff to add items to existing lists, by
honouring the existing edit_public_list_contents
To test:
a) notice the new my lists link on the account pulldown
1) ensure it goes to the lists module
b) create new public list, add at least one item, make it editable by everyone
1) note the name of the list
c) create a new patron with full access to the staff client minus lists permissions
d) log in as the newly created patron
e) notice the lists button is missing from the staff client mainpage
f) set any of the lists permissions except create public lists, use public lists, edit public list contents
g) notice how the lists button is no longer missing from the staff client mainpage
h) go to the lists module
1) notice that public lists are now missing from the datatable
i) click add list
1) notice that the public drop-down is now a fixed label set to private
j) create list and confirm it is not public
k) turn use public lists permission on
l) return to the lists module
1) notice that the datatable now shows private and public lists tabs
m) turn create public lists permission on
n) repeat steps h-i
1) notice that the public drop-down is now visible again
o) create list and confirm it is public
p) go to the list you created in step b
q) notice that add items button, and remove selected button, is missing
r) turn edit public list contents permission on
s) repeat steps p-q
1) notice that add items button is now visible
t) click add items
u) enter an item barcode or biblio number, click save
1) notice that the items are now added to the list
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Argument "" isn't numeric in int
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
Try passing page=x now and verify different behavior (no 500).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Same fix as Bug 28561: Remove DBIC warning in opac-shelves
But for staff
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The 'delete_confirm' op leads to a confirmation page, so it's GET.
The patch also consolidates JS for handling deletions, using the same
class for both the delete button in the toolbar and in the table of
lists.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The op "edit_form" doesn't change state. It just renders the edit
form. Therefore, it doesn't need a CSRF token/check.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Public lists with 'Allow changes to contents from' = 'Permitted staff only'
can have their contents managed by Koha patrons with either of the
permissions below:
- superlibrarian permission
- catalogue permission + 'edit_public_list_contents' sub-permission
Test plan:
1. Apply patches, update database, restart services
2. In the staff client go to: Lists > New List
3. Create a list, choose 'Allow changes to contents from' => 'Permitted
staff only'
4. Log into the OPAC as a patron with no permissions.
5. Confirm you CANNOT add a biblio to the list from the OPAC search result page and
OPAC biblio detail pages
6. Log into the OPAC as a patron with only the 'catalogue' permissions
enabled
7. Confirm you CANNOT add a biblio to the list from OPAC search result
or biblio detail pages
8. Log into the OPAC as a patron with the 'catalogue' and
'edit_public_list_contents' permissions enabled
9. Confirm you CAN add/remove biblios from the OPAC search result and
biblio detail pages
10. Log into the OPAC as a patron with superlibrarian permissions
11. Confirm you CAN add a biblio to the list from the OPAC search result
page and OPAC biblio detail pages
12. Log into the staff client as a patron with only the
'catalogue' permission and confirm you CANNOT add/remove records from the
list
13. Log into the staff client as a patron with the 'catalogue' and
'edit_public_list_contents' sub-permission (found under 'Lists' parent
permission)
14. Confirm you CAN add/remove records from the list
15. Login into thestaff client as a patron with 'superlibrarian'
permissions and confirm you CAN add/remove records from the list
Sponsored-by: Catalyst IT, New Zealand
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patchset adds an 'interface' parameter to XSLTParseForDisplay to avoid fetching
coins when not needed
Additionally we move some logic from the scripts to searchResults to avoid an extra fetch fo the biblio object
To test:
1 - Enable COinSinOPACResults syspref
2 - Also enable OPACShowOpenURL and OPACOpenURLItemTypes - adding an itemtype that you can find
3 - Perform a search on the OPAC and confirm coins are included and openurl shown
4 - Perform a search on staff client and confirm openurls do not show
5 - Apply patch
6 - Results should be the same
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
And GetItemsLocationInfo from shelves.pl
Bug 27272 is going to remove C4::Items::GetItemsInfo in favour of Koha::Items->search_ordered.
Here we are going to deal with virtualshelves/sendshelf.pl
Test plan:
List items on the modified view and confirm that all the info is
displayed correctly
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
JD Amended patch:
-# FIXME Special case here
- print "Biblio not found\n,";
+ print "Biblio not found\n";
- my $biblio = Koha::Biblio->find($hostbiblionumber);
+ my $biblio = Koha::Biblios->find($hostbiblionumber);
Rebased-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Verify if transfer shared list on OPAC still works as expected.
Same for intranet counterpart for public lists.
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: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
[1] Valid transfer:
Log in with staff patron C having edit_public_lists.
Pick a public list. Choose Transfer. Select a patron.
Submit and check if transfer was successful.
[2] Permission problem:
Pick a staff user D. Temporary enable edit_public_lists.
Add another private tab. Login with D.
Pick a public list. Transfer. Choose another patron. Wait.
Switch tab: remove added permission from D.
Switch tab again: Submit transfer form. Error? Close tab.
[3] Bonus test - Shelf disappeared:
Pick a public list. Transfer. Choose another patron. Wait.
Open another tab. Delete the selected public list.
Close tab. Submit the transfer. Not exist error?
[4] Bonus test - Patron not found:
Pick a public list. Transfer. Choose another patron. Wait.
Open another tab. Delete selected patron.
Close tab. Submit transfer. Patron not found error?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Note: Adjusting shelves_results template too for not allowing delete
when you do not have delete_public_lists (or higher). If you are the
owner, you are allowed to edit or delete. But transfer specifically
needs edit_public_lists (or higher).
Note: Removed a few useless POD lines to make qa tools happy.
Test plan:
Check if you see the transfer button on public lists only when having
permission edit_public_lists (or higher). And never on private lists.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The solution was to add regexp that trims all whitespaces.
How to test:
1. Go to the koha/virtualshelves/shelves.pl;
2. Add new list or edit existing one;
3. Start adding new items;
4. In the "Barcode" field add barcode(s) with whitespaces before them;
5. Observe that it wasn't added as the barcode isn't recognized because of whitespaces;
6. Apply the patch;
7. Repeat step 4;
8. Observe that the item was successfully added;
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If a staff member has access to the staff client (either because
'catalogue' permission is enabled or they're a superlibrarian
then that user can add items (from OPAC or staff client) to a list
marked 'Staff only'
Test plan:
1. In the staff client go to: Lists > 'New list'. Notice under 'Allow changes to contents
from' there are three options: Nobody, Owner only, Anyone seeing this
list
2. Apply first 3 patches and run updatedatabase.pl
cd installer/data/mysql
sudo koha-shell <instance>
./updatedatabase.pl
3. Restart memcached and plack
4. Create 4 patron accounts:
- User A : Superlibrarian permissions
- User B : 'Staff access, allows viewing of catalogue in staff interface
(catalogue)'
- User C : No permissions
- User D : 'Staff access, allows viewing of catalogue in staff
interface' and 'Lists' > Edit public lists (edit_public_lists)' sub-permission
5. Login to staff client as User A.
Create a public list and select the new 'Staff only' option under 'Allow changes to contents from'
6. Log into the staff client as User B.
Confirm you can add items to the list from the following staff client pages:
- Individual list page using the 'Add items' button
- Staff client search result page
- Staff client biblio detail page
7. Confirm you can remove items from the list
8. Confirm you can perform an OPAC search when not logged in
9. Log into the OPAC as User B. Confirm you can add items to the list
from the following OPAC pages:
- OPAC search result page
- OPAC biblio detail page
10. Log into the OPAC as User C. Do an OPAC search and confirm you
can view the list, but not add items to it
11. Login to the staff client as User B. Create a new list with the
following settings:
- 'Category'='Private',
- 'Allow changes to contents from'='Staff only'
Notice a red hint message is displayed.
Change 'Category'='Public' and notice the hint is removed
12. Log into the OPAC as User C. Notice the 'Staff only' option is not
available when creating a list
13. Log into the OPAC as User B. Repeat step 11. Confirm the same
outcome
14. Log into the staff client as User A. Create a list with the
following settings:
- Public = 'Public'
- Allow changes to contents from = 'owner only'
15. Log into the staff client as User D. Edit the list from step 14
confirm you can edit the list to have 'Allow changes to contents from' =
'Staff only'
16. Run Patron.t and Virtualshelves.t unit tests:
sudo koha-shell <instance>
prove t/db_dependent/Koha/Patron.t
prove t/db_dependent/Virtualshelves.t
Sponsored-by: Horowhenua District Council, New Zealand
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Wrong key 'xsl_filename' is present in opac-tags.pl and shelves.pl
(the only places where it is used in the code even) instead of
'xsl_syspref' that is actually used and this is the cause of those
warnings.
Also added honeypot to check if other calls in same way happens.
Honeypot probably not needed, review when QA in the Community.
To reproduce (shelves.pl):
1) Prepare some test list with items or use existing one.
2) Go to the lists page (koha/virtualshelves/shelves.pl),
notice multitude of new warnings in the "intranet-error.log" log file
that mostly have to do with "Use of uninitialized value $xslsyspref".
3) Apply the patch.
4) Go back to same page and check it again, warns like that should not
appear in the log file anymore.
To reproduce (opac-tags.pl):
1) Go to the "my tags" page in OPAC and open "tag cloud".
2) Notice a bunch of new warnings in the log file that mostly have to
do with "Use of uninitialized value $xslsyspref".
3) Apply the patch.
4) Reload the page and check the log file again.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patchset moves the 'category' attribute for virtual shelves, that
takes values of 1 and 2 (private and public respectively) into a boolean
for public.
The DBRev is trivial, and the changes to the code are as well.
To test:
1. have some known public and private lists
2. Apply this patches
3. Run:
$ updatedatabase
=> SUCCESS: Public lists have public=1, private have public=0
4. Run:
$ kshell
k$ prove t/db_dependent/Utils/Datatables_Virtualshelves.t \
t/db_dependent/Virtualshelves.t
=> SUCCESS: Tests pass!
5. Try the feature in staff and OPAC
=> SUCCESS: All good
6. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Use a hash for better readability and reusability.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We certainly faced 3 similar bugs due to this syntax: bug 23006, bug
22941 and bug 17526.
To prevent other issues related to this syntax this patch suggests to
replace them all in one go.
Test plan:
Confirm that the 2 syntaxes are similar
Eyeball the patch and confirm that there is no typo!
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
Hit /virtualshelves/shelves.pl?op=view&shelfnumber=1&sortfield=author(
You must not get:
Unmatched ( in regex; marked by <-- HERE in m/^author( <-- HERE $/ at /home/vagrant/kohaclone/virtualshelves/shelves.pl line 236
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This reverts commit 375dd35d53.
https://bugs.koha-community.org/show_bug.cgi?id=22836
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The category parameter should be restricted to 1 or 2 (private/public). In
order to keep same behavior, no parameter means 1 (private).
Note: Adding the same line in intranet counterpart.
Test plan
[1] Check for category empty, '1a', '11' etc. And with script ;)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
1) Ensure the COinS span tag is still included on this pages. You need
to look into html source and search for span tag with class 'Z3988',
which has COinS string in title.
Staff client:
catalogue -> ISBDdetail
catalogue -> MARCdetail
catalogue -> detail
virtualshelves -> shelves
OPAC (you should have COinSinOPACResults system preference enabled):
opac detail
opac search
opac shelves
2) Run tests:
prove t/Biblio.t t/db_dependent/Biblio.t t/db_dependent/Koha/Biblio.t
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Tested with all 9 current patches. Works as advertised, including
OPACURLOpenInNewWindow. If a record has no items, no OpenURL link
is displayed. All the suggested tests pass. I did not test with
XSLT turned off.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Note: This is here for information purpose, feel free to test it if you
wan to play with it.
TODO: C4::Reserves::_get_itype is not longer in use
No more GetItem must be returned by:
git grep GetItem|grep -v GetItemsAvailableToFillHoldRequestsForBib|grep
-v GetItemsForInventory|grep -v GetItemsInfo|grep -v
GetItemsLocationInfo|grep -v GetItemsInCollection|grep -v
GetItemCourseReservesInfo|grep -v GetItemnumbersFromOrder|grep -v
GetItemSearchField|grep -v GetItemTypesCategorized|grep -v
GetItemNumbersFromImportBatch|cut -d':' -f1|sort|uniq
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
DBMS can sort callnumbers correctly using cn_sort. We should use it
showing a list's content.
Test plan:
- Add items with callnumber to a list
- Display the list
- List the content by callnumbers
=> Confirm that the records are correctly sorted by callnumber
Signed-off-by: Myka Kennedy Stephens <mkstephens@lancasterseminary.edu>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
In the staff client, when viewing the content of a list, it can be sorted by 'title', 'author' or 'call number' but not by 'date added'.
This patch adds 'date added' as an option for default sorting of lists. It also makes it available as a sorting option while viewing lists.
Test plan:
In the staff client and the opac:
1) View a list containing several items
=> Notice that you can't sort by 'date added'
2) Try to edit the list or create a new one
=> Notice you can't choose date added as the default sort order
3) Apply the patch
4) When viewing the list you should now be able to sort by date added
=> Make sure it orders correctly
5) Edit or create a list and choose date added as default sorting order
=> Make sure it uses date added as default
=> On the staff client: test that the filter for 'sort by' works for date added
=> On the opac: test that, while viewing the contents, choosing 'default sorting' in the dropdown menu sorts correctly
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>