Commit Graph

13 Commits

Author SHA1 Message Date
Tomas Cohen Arazi ba80c71e63
Bug 33974: (follow-up) biblionumber column needs special handling
This patch makes a particular use case be handled correctly: i.e. no
context is passed (e.g. 'biblio' explicitly) and the query is done
against the `biblio_id` attribute. This results in the following DBIC
error:

[ERROR] GET /api/v1/biblios: unhandled exception (DBIx::Class::Exception)<<DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Column 'biblionumber' in where clause is ambiguous at /kohadevbox/koha/Koha/Objects.pm line 394>>

With this patch, this is no longuer the case :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-07-03 14:51:46 -03:00
Tomas Cohen Arazi 60e8998e91
Bug 33974: Add Koha::Biblios->api_query_fixer
This patch adds the `api_query_fixer` method to the class, and adds
tests to validate its behavior.

To test:
1. Apply this patch
2. Run:
   $ ktd --shell
  k$ prove t/db_dependent/Koha/Biblios.t
=> SUCCESS: Tests pass!
3. Sign off :-D

Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-07-03 14:51:42 -03:00
Tomas Cohen Arazi 981eeff7ef
Bug 33447: Make *->pickup_locations methods throw an exception on missing parameter
This patch fixes the FIXME for making the methods throw an exception.

Tests are added, and POD is adapted as well.

To test:
1. Apply this patch
2. Run:
   $ ktd --shell
  k$ prove t/db_dependent/api/v1/patrons* \
           t/db_dependent/api/v1/holds.t \
           t/db_dependent/Reserves* \
           t/db_dependent/Hold* \
           t/db_dependent/Koha/Hold* \
           t/db_dependent/Items*

=> SUCCESS: Tests pass!
3. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-04-20 15:48:32 -03:00
Nick Clemens ef8adf34fd
Bug 33447: (follow-up) Fix tests and make assumption explicit
The patches made an assumption that patron would always be passed. It is
within Koha, but not in the Biblios tests.

There is no scenario where we can determine pickup locations that are not in
reference to a patron (who is picking it up?) so we should always have
this parameter

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-04-20 15:48:31 -03:00
Tomas Cohen Arazi 79e3fd1640
Bug 32734: (QA follow-up) Remove stray method
On bug 33083 we introduce a better way to implement a reusable method
for the same functionality.

This patch just removes the one in `Koha::Biblios` and the result should
be the same as the one inherited from  `Koha::Objects::Record::Collections` will be picked instead.

To test:
1. Run:
   $ prove t/db_dependent/Koha/Biblios.t \
           t/db_dependent/api/v1/biblios.t
=> SUCCESS: Tests pass!
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests pass!

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-03-13 15:12:09 -03:00
Agustin Moyano a4fb1ca3d1
Bug 32734: Add REST endpoint to list biblios
This patch adds an endpoint to list biblios

To test:
1. apply patch
2. enable basic auth
3. call to GET /api/v1/biblios with the following Accept headers:
 * application/json
 * application/marcxml+xml
 * application/marc-in-json
 * application/marc
 * text/plain
4. notice how data changes with each Accept header
5. prove t/db_dependent/Koha/Biblios.t t/db_dependent/api/v1/biblios.t
6. sign off

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Hammat Wele <hammat.wele@inlibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-03-13 15:12:04 -03:00
Agustin Moyano 2055c84a95
Bug 33083: Add a generic class to handle methods for collections of records
To test:
1. Apply patch
2. prove t/db_dependent/Koha/Objects/Record/Collections.t

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2023-03-13 15:11:59 -03:00
Jonathan Druart 9d6d641d1f Bug 17600: Standardize our EXPORT_OK
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>
2021-07-16 08:58:47 +02:00
Tomas Cohen Arazi bc2aea0df4 Bug 28273: Add Koha::Biblios->pickup_locations
https://bugs.koha-community.org/show_bug.cgi?id=26273

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2021-05-20 08:43:34 +02:00
Jonathan Druart 7d8b96803f
Bug 24545: Fix license statements
Bug 9978 should have fixed them all, but some were missing.
We want all the license statements part of Koha to be identical, and
using the GPLv3 statement.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
2020-02-24 13:31:26 +00:00
Kyle M Hall bf1563e60b Bug 14610 - Add and update modules
Signed-off-by: Jennifer Schmidt <jschmidt@switchinc.org>

Signed-off-by: Katrin Fischer  <katrin.fischer@bsz-bw.de>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-10-26 12:15:13 +00:00
Jonathan Druart de3289506d Bug 15446: Rename Koha::Object[s]->type with _type
In a few case (at least systempreferences and export_format (csv profiles),
the type method of Koha::Object and Koha::Objects can be in conflict with the
column names.
Indeed systempreferences.type exists and so the method will return
'Systempreference' (the name of the module) instead of the value of the row in
DB.

I have found at least 1 place where it can cause issue:
In C4::Context->set_preference:
 601     my $syspref = Koha::Config::SysPrefs->find( $var );
 602     my $type = $syspref ? $syspref->type() : undef;
 603
 604     $value = 0 if ( $type && $type eq 'YesNo' && $value eq '' );

type will always be 'Systempreference' and the YesNo pref will be set to an
empty string '' instead of 0.

I am not sure about the consequences of this, but it is preferable to
fix it ASAP.

To reproduce:
0/ Do not apply this patch
1/ Edit a YesNo prefs, AutoEmailOpacUser for instance
2/ Set it to "Don't sent"
3/ Check the value in DB, it should be set to an empty string, instead
of 0
4/ Apply this patch and try again. Now the value should be 0

Followed test plan, value is now 0 as expected.
Signed-off-by: Marc Véron <veron@veron.ch>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
2016-02-12 12:35:57 -07:00
Kyle M Hall 062f34c55d Bug 13851: Replace waiting holds logic in circulation.pl with Koha Objects
This is the original patch for bug 12892 and replaces the older style of
fetching the holds data with Koha Objects. It will be used as a
foundation for future features.

Test Plan:
1) Apply this patch
2) Create a hold, set to waiting
3) Browse to circulation.pl for that patron
4) Note you see the list of waiting holds
5) Switch your logged in branch to a different branch
6) Note the "Waiting at" line is no longer emphasized.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Cathi Wiggins <CWIGGINS@ci.arcadia.ca.us>

Signed-off-by: Megan Wianecki <mwianecki@mplmain.mtpl.org>

Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2015-07-29 15:47:13 -03:00