The QA tools flag all methods without POD in any touched file.
This patch adds the missing POD for pre-existing methods that were
flagged:
- Koha::Item::_add_statistic
- Koha::Object::_date_or_datetime_column_type
- Koha::Object::_datetime_column_type
- Koha::Object::_numeric_column_type
- Koha::Object::_decimal_column_type
- Koha::Object::_recursive_fixup
- Koha::Object::_get_object_class
- Koha::Object::DESTROY
- Koha::Patron::Modification::_type (also fixes heading mismatch)
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Complete the migration of enum data truncation exception handling from
Koha::Object to the centralized ExceptionTranslator utility. This eliminates
the last remaining manual DBIx::Class exception handling in Object code.
Changes:
- Add optional object parameter to ExceptionTranslator->translate_exception()
- Update Schema wrapper methods to accept and pass object parameter
- Enhance enum truncation handling to extract actual property values when object is available
- Remove manual enum exception handling from Koha::Object::store()
- Add comprehensive test coverage for enum handling with and without object context
- Maintain contextual warning behavior for store() operations
The centralized system now handles ALL DBIx::Class exception scenarios:
- FK constraint failures (add/update and delete operations)
- Duplicate key violations
- Invalid data type values
- Enum data truncation with actual property values
This completes the centralization effort while providing better error reporting
than the previous manual approach.
Sponsored-by: OpenFifth <https://openfifth.co.uk>
Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Move the FK constraint deletion exception handling from Koha::Object::delete
to the centralized ExceptionTranslator utility. This consolidates all
DBIx::Class exception translation logic in one place and simplifies the
Object delete method.
Changes:
- Add FK constraint deletion pattern matching to ExceptionTranslator
- Remove manual exception handling from Koha::Object::delete
- Add test coverage for FK constraint deletion translation
- Simplify Object delete method to use centralized translation
The centralized system now handles both FK constraint scenarios:
- Child row constraint failures (add/update operations)
- Parent row constraint failures (delete operations)
Sponsored-by: OpenFifth <https://openfifth.co.uk>
Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This introduces a reusable exception translation utility that eliminates
code duplication and provides consistent handling of DBIx::Class exceptions
throughout the codebase.
New Components:
- Koha::Schema::Util::ExceptionTranslator: Core utility class for translating
DBIx::Class exceptions to Koha-specific exceptions
- Koha::Schema: Enhanced with safe_do() and translate_exception() methods
for convenient access to centralized exception handling
- Comprehensive unit tests covering all translation scenarios
Benefits:
- Eliminates ~90 lines of duplicated exception handling code
- Centralizes maintenance of exception translation logic
- Provides consistent error messages and exception types
- Makes it easier to extend support for additional database engines
- Follows the pattern suggested in existing FIXME comments
Exception Types Handled:
- Foreign key constraint violations → Koha::Exceptions::Object::FKConstraint
- Duplicate key violations → Koha::Exceptions::Object::DuplicateID
- Invalid data type values → Koha::Exceptions::Object::BadValue
- Enum data truncation → Koha::Exceptions::Object::BadValue
Sponsored-by: OpenFifth <https://openfifth.co.uk>
Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This has the same goals of bug 24975 but with a different approach.
Bug 24975 tried the "POT/PO files as database tables" approach but
it appeared that is not what best fits our needs.
Instead of a "source text / translated text" mapping, we need
translations to be attached to a specific "object" (or table row), which
has the added benefit of keeping translations unaffected when the
original string changes. It may or may not be what you want but at least
this avoids the problem where fixing an error in the original string
forces users to re-translate everything.
We also need to be able to translate all translatable properties of a
particular entity.
The solution proposed here is to add a DBIC component that will add
several DBIC relations to the `localization` table:
* a relation named `localizations` that will return all translations for
all translatable properties for all languages.
* for each translatable property:
* a relation named `{$property}_localizations` that will return all
translations for a given property, for all languages
* a relation named `{$property}_localization` that will return the
translation for a given property, for the current language
To enable translations for a particular entity, we will need to:
* add two method calls in the "result class" corresponding to the
localizable object type
* in the admin interface, add a link to the the translation popup.
Unlike bug 24975 there is not a page where you can translate
everything. I don't know if it is really useful (probably better to
translate itemtypes when you are on the itemtype page). It can be
added later if needed.
To give an example, this is what needs to be added manually in
Koha/Schema/Result/Itemtype.pm:
__PACKAGE__->load_components('+Koha::DBIx::Class::Localization');
__PACKAGE__->localization_add_relationships(
'itemtype', # the PK column
'description' # a list of translatable columns
);
(see POD in Koha/Schema/Component/Localization.pm for more information)
Final notes:
* I wanted this patch to have as few changes as possible so I kept
methods like `search_with_localization`, `children_with_localization`
even if I believe they can be removed (replaced by search/children)
Localizations do not need to be prefetched/joined unless you want to
sort on them.
For the same reason, $itemtype->unblessed now always return a
`translated_description` key.
This can be fixed in followup patches
* There is cache involved (see
Koha::Schema::Component::Localization::localization).
Localizations in cache are grouped by object type and language (keys
look like 'KOHA:localization:Itemtype:en')
* By keeping a single table for all translations of all entities, we
cannot have data integrity at the RDBMS level, but automatic deletion
of translations is handled by the DBIC `cascade_delete` feature, so
integrity should be fine as long as no raw SQL update/delete operation
is involved.
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.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>
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 makes the exception on bad enum values in Koha::Object->store
not print a warning in the event of stringifying the exception.
To test:
1. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha/Booking.t
=> FAIL: You get this warnings:
```
Use of uninitialized value in sprintf at /kohadevbox/koha/Koha/Exceptions/Object.pm line 84.
```
2. Apply this patch
3. Repeat 1
=> SUCCESS: No more uninitialized values warnings
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a test to make sure the same object is returned. A code
change is also added to make sure the tests pass.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We were repeating some code for the PATCH endpoint instead of using the
existing update handling code. This lead to two issues:
1) We weren't catching status updates on standard updates, only the
patch.
2) We were limiting the PATCH endpoint to just status updates when it
could happily be used for other fields too.
This patch removes the introduction of the 'edit' method from both the
REST controller and the corresponding object and moves the logic into
the store method of the object where it's easily testable.
We also DRY out the notice sending code a little for re-use.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If we pass a datetime parameter we are adding "like" operator and % at
the beginning and ending of the attribute value.
For instance:
attributes=2024-09-16 10:11:12
attributes:{ like => '%2024-09-16 10:11:12%' }
We do not want to reach the fixup code and raise an exception.
However I don't think we should add the like for datetime attributes
actually. But can we modify this behaviour now?
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We didn't take into account the server's timezone.
This does not feel right, we are not supposed to deal with time zone
outside of Koha::DateUtils.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There are still different structures we won't handle properly.
This patch adds conditionals to prevent failures or warnings.
Should be done, but later.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch makes Koha::Object->delete wrap DBIC exceptions on FK
constraints and throw a Koha::Exception::Object::FKConstraint exception
instead. This will allow us better handling it from the callers.
To test:
1. Apply the unit tests patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha/Object.t
=> FAIL: A DBIC exception is thrown instead, tests fail
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Koha::Object depends on Koha::DateUtils, which depends on C4::Context,
which depends on Koha::Config::SysPref, which depends on... Koha::Object
Apart from the circular dependency, the dependency on C4::Context alone
is problematic as it loads a bunch of modules that are not needed at all
in Koha::Object (YAML::XS and ZOOM for instance).
As Koha::Object is used as a base for a lot of modules, we should take
care to only load the minimum required.
This patch moves some date parsing code to specific modules:
- Koha::DateTime::Format::RFC3339
- Koha::DateTime::Format::SQL
and it uses them in Koha::Object and Koha::DateUtils where it is
possible.
Test plan:
1. Do not apply the patch yet and run the following command:
`perl -cw Koha/Object.pm`
It should print several warnings about redefined subroutines, meaning
there is a circular dependency.
2. Apply the patch
3. Run `perl -cw Koha/Object.pm`. It should only say:
"Koha/Object.pm syntax OK"
4. Run the following command:
prove \
t/DateUtils.t \
t/Koha/DateTime/Format/RFC3339.t \
t/db_dependent/Koha/Object.t
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) Apply Bug 32476
2) Run tests in t/db_dependent/Patrons.t
3) This should produce multiple "Subroutine Koha::Patron::SUPER::dateexpiry redefined at ..." warnings
4) Apply patch
5) Run tests in t/db_dependent/Patrons.t again
6) The warnings in 3) should now no longer appear
Signed-off-by: matthias le gac <matthias@babel.inlibro.net>
Signed-off-by: Phan Tung Bui <phan-tung.bui@inlibro.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch switches from removing inaccessible items from the responses
to instead redacting fields in innaccessible responses.
This allows for embed traversal and keeps counts etc correct but also
hides the data we want to hide.
We add support for an 'unredact_list' method at the Koha::* class level
allowing for individual classes to specify which fields they wish to
expose to restricted users regardless of their restriction.
It is to be used in combination with the is_accessible method introduced
earlier in this patchset which is used to denote whether the current
user should be allowed to see the full record or only a subset of it as
defined in the unredacted_list.
We undefine any fields not listed in the unredact_list for the API
response. This has the effect of still returning the full object of
keys, but setting most fields to a JSON null.
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: Tomas Cohen Arazi <tomascohen@theke.io>
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: Tomas Cohen Arazi <tomascohen@theke.io>
In this patch I add 'user', containing the Koha::Patron object for the
logged in user in the params hash we pass around in to_api. I then use
that in a new 'is_accessible' method added to Koha::Patron.
The new method is really the equivilent of 'search_limited' in the plural
class and could perhaps be renamed 'is_limited' or something clearer for
the singular form 'is_filtered' or 'fitler_for_api' or something?
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes the *to_api* method honour the accessibility check for
the object. This is relevant in the context of embedding single objects.
The Koha::Patron->to_api method is adjusted to reflect this behavior as
well (it does some manipulation after the ->to_api call and we need to
prevent it).
To test:
1. Apply up to the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object.t
=> FAIL: A patron, that shouldn't be accessed, is returned by ->to_api
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
6. Pick Henry Acevedo from the sample data, assign him 'catalogue'
permissions and a know user/password combination
7. Enable basic authentication
8. Point your favourite tool (Postman?) to
GET http://kohadev-intra.myDNSname.org:8081/api/v1/biblio/245/checkouts
Set the following header: x-koha-embed: patron
Pick whatever biblio you want, actually.
=> SUCCESS: No checkouts
9. Perform a couple checkouts on the chosen biblio. Make sure one
checkout is for a patron on the same library as Henry, and the other
on a different one.
10. Repeat 8
=> SUCCESS: You see two checkouts. One of them has an attribute 'patron'
containing the patron from Henry's library. The other, has the
attribute set to 'null'.
11. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
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: Tomas Cohen Arazi <tomascohen@theke.io>
This patch introduces a method for checking if an object can be
retrieved by the current user. It depends on the plural class
implementation of the ->search_limited method.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
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: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Prove t/db_dependent/Koha
Run the benchmark (on BZ) again
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Lazily create accessor methods when getting or setting an Koha::Object
attribute resulting in a significant speed up.
To test:
1) Run the benchmark.pl script
2) Apply the patch
3) Run the script again, Koha::Object accessors should be about 7 times faster
5) Ensure tests in t/db_dependent/Item.t still pass
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: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The api_strings_mapping method isn't really only about api strings.. we
deal with database fields in and out.. we just happen to then use those
in to_api to map in the api.
This patch simply renames the standard method whilst we're still early.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We should stick to DB field names as long as possible to allow re-use
and only convert to api field names via to_api_mapping at the last
moment inside the parent to_api function.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the `av_expand` occurences to `strings` to match the
change of the return structure of `_strings`.
We replace `+av_expand` in the headers with `+strings`, the expected
object method name from `api_av_mapping` to `api_strings_mapping` and
the internal hash key from `av_expand` to `strings`.
Test plan
1) Run the included unit tests.. all should still pass.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Instead of a global av-expand flag (through a header) this patch
proposes to allow specifying +av_expand at the x-koha-embed header
level. This allows a more fine-grained control on what objects get avs
expanded. e.g.:
GET /patrons/123
x-koha-expand: +av_expand,checkouts.item+av_expand
=>
{
"_str": {
"city": { "str": "Córdoba", ... }
},
...
"checkouts": [
{
...,
"item": {
"_str": {
"not_for_loan_status": { "str": "Reference material", ... },
...
},
...
}
}
]
}
To test:
1. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object.t \
t/Koha/REST/Plugin/Query.t \
t/db_dependent/Koha/REST/Plugin/Objects.t
=> SUCCESS: Tests pass!
2. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes the returned data structure be simpler:
_str => {
attribute_1 => {
category => 'some_category_name',
str => 'description',
type => 'av'
},
...
}
The description is sensible to context, so if public => 1 is passed,
then lib_opac is passed, and lib is returned otherwise. Whenever we add
language to the combo, we will add it to the implementation.
Tests are adjusted accordingly, also to reflect the public => 1 use
case.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object.t \
t/db_dependent/Koha/REST/Plugin/Objects.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch simplifies the original implementation so it is more
readable, removing extra loops and methods and just dealing with the
coded values inline on the existing loops.
It also adds non-public attributes removal from the original list, to
address the changes introduced by bug 28948.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object.t \
t/db_dependent/Koha/REST/Plugin/Objects.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the posibility to expand authorised values when to_api
method is called.
The classes where authorised values should expand must implememnt the
_fetch_authorised_values method, and must return a hash like the
following
{
column_name => Koha::AuthorisedValue->unblessed
...
}
This patch will be used in bug 8179, so please test there.
Sponsored-by: Virginia Polytechnic Institute and State University
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
It will conflict with other ->messages methods, it's too generic.
Bug 29230 needs Koha::Patron->messages to return Koha::Patron::Messages for instance.
Test plan:
Confirm that the tests modified by this patch still pass
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We removed the fallback on 'Bug 24850: Don't fallback when date_format
is passed', and the dates passed for date only (YYYY-MM-DD) are not
RFC3339 formatted but ISO8601.
We must assume that all dates will be YYYY-MM-DD, without fallback.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch reproduces what we did for `to_api_mapping`: make it always
present on Koha::Object classes. This has the side-effect of... making
things more secure!
Before this patch, if undefined, all attributes were returned.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch converts the code to use an allow-list as aposed to a
deny-list. This is more 'fail safe' than requireing maintanence of a
deny-list.
We also switch to using db fields names for the list as aposed to api
mapped names. This way, the list can be re-used for non-api related
sanitising if required.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch introduces a way for Koha::Object(s)->to_api to filter out
attributes that require privileged access. It is done in a way that the
'public' parameter is recursively passed to nested objects in recursive
to_api() calls.
This way, Koha::Object-based classes can determine how they will render
depending on this parameter. For example, for implementing a
route for fetching an library looks like:
GET /libraries
The controller will look like:
my $library = Koha::Libraries->find( $c->validation->param('library_id') );
return $c->render(
status => 200,
openapi => $library->to_api
);
Implementing an unprivileged (public) route would look like:
GET /public/libraries/:library_id
The controller will look like:
my $library = Koha::Libraries->find( $c->validation->param('library_id') );
return $c->render(
status => 200,
openapi => $library->to_api({ public => 1 })
);
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object*.t
=> SUCCESS: Tests pass (i.e. current behaviour is kept, new behaviour
passes the tests)
3. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patchset takes the GET /patrons route as a sample usage for filtering
on date and date-time (including timestamp) fields.
It then makes Koha::Object->attributes_from_api use the DB storage
datetime parser for format the parameters correctly.
To test:
1. Apply the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/patrons.t
=> FAIL: It doesn't find the patron when filtering by date
3. Apply this patch
4. Repeat 2
=> SUCCESS: It works now!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes Koha::Object->attribute_from_api allow setting
attributes the undef value. The original implementation passed the value
directly to dt_from_string, which made the attribute be set the current
date.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object.t \
t/db_dependent/api/v1/patrons.t
=> FAIL: Tests fail! Our code is buggy!
3. Apply this patch
4. Repeat 2
=> SUCCESS! Fix fixed this thing!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Eric Phetteplace <phette23@gmail.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
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>
Revert "Bug 28585: (follow-up) Tests for q= supporting date/date-time parameters"
This reverts commit 89d9dd6d5d.
Revert "Bug 28585: Use the datetime_parser for handling API dates"
This reverts commit 2e266f35f9.
Revert "Bug 28585: Regression tests"
This reverts commit 8d74d3226a.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patchset takes the GET /patrons route as a sample usage for filtering
on date and date-time (including timestamp) fields.
It then makes Koha::Object->attributes_from_api use the DB storage
datetime parser for format the parameters correctly.
To test:
1. Apply the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/patrons.t
=> FAIL: It doesn't find the patron when filtering by date
3. Apply this patch
4. Repeat 2
=> SUCCESS: It works now!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@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: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>