I'm not sure what we need to test here, besides we get results. I'm
pretty sure we shouldn't allow a plain GET return all objects because it
could cause a DOS very easily. But it certainly belongs to a separate
bug/discussion.
In this case, I put a constraint on the items domain (by using
_per_page=10 in the query params) so it won't happen that under certain
conditions the user agent used by Test::Mojo time outs.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch undoes the move of the JavaScript block to the footer made in
Bug 22734. The item information tab can include embedded JavaScript for
cataloging plugins, and these don't currently work with JS in the
footer.
To test, apply the patch and test the JavaScript driven features of the
"Add to basket from a staged file" page:
- Acquisitions -> Vendor -> Basket -> Add to basket from a staged file
- MARC and Card previews, select all/clear all
- Item information tab: Cataloging plugins for fields like
date acquired, barcode
- Default accounting details tab: Show inactive control
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Well, this is actually the real root of the error!
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It must be NULL/undef, the default from the DB.
The method Koha::Patron::Attribute::Type->categorycode is not covered by tests!
To recreate:
Create a new patron attribute type, don't select a patron's category (and not repeatable or unique)
Go to the batch patron modification tool, enter a cardnumber, next.
=> boom!
Apply the patch, edit the patron attribute, save
Go to the batch patron modification tool, enter a cardnumber, next.
=> success!
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
As we are now removing them from MarkIssueReturned they should not be
removed from AddReturn as well.
Also I think this will fix a regression, if $doreturn is not set (in
case the item is withdrawn and BlockReturnOfWithdrawnItems or the item
is lost and BlockReturnOfLostItems, and other specific cases).
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It's quite hard to know where this need to be fixed.
it can be either MarkIssueReturned or LostItem, depending on the
different cases we want to handle.
This patch picked MarkIssueReturned, but maybe the similar code in
AddReturn needs to be removed then.
== Test plan ==
1. Set MarkLostItemsAsReturned to 'from items tab of the catalog module'
2. Set AutoRemoveOverduesRestrictions to 'Do'
3. Set up an overdues restriction in the notice triggers
4. Check out an item and let the overdues process restrict the account
5. Navigate to the moredetail.pl page (items tab) for the overdue item
6. Mark the item lost
7. Return to the account in question - notice the item has been returned, but the restriction remains
8. Clean state: remove restriction + remove item lost status
9. Apply patch
10. Redo the test but this time in addition to the item being returned,
the restriction will be lifted.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Now that we have the reserve_id PK on the reserves table we should use
it (instead of the couple borrowernumber, biblionumber)
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
ReserveSlip call need to be adjusted in test.
We also add a new reserve (same biblio, same patron) to highlight the problem.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To make sure we are going to display the correct hold's info we need to
pass the reserve_id.
== Test plan ==
1. Add some content to HOLD_SLIP notice, e.g.
<h2>[% branch.branchname %]</h2>
<div>[% biblio.author %]<br>[% biblio.title %]<br>[% item.barcode %]
<ul><li> Reserve ID: [% hold.reserve_id %]</li>
<li>Expiration date: [% hold.expirationdate %]</li></ul>
2. Add 2 holds for 1 patron to a single record
3. Check the reserve IDs in the reserves table - on a clean sandbox, they will be 1 and 2
4. Check in one of the items from the record and print the slip
5. Note that the reserve ID on the slip is 2 and the expiration date is blank
6. Repeated check ins do not change this
7. Check in a second item from the record
8. Note that the reserve ID for this hold is also 2, but this time the expiration date is filled in
9. Check in the first item again - the reserve ID stays as 2, but this time the expiration date is filled in
10. Apply patch
11. cancel the holds to come back to a clean state
(and maybe ensure items aren't in transit)
12. redo the test and see the following differences
13. 1st checkin:
1. expiration date ok
2. the reserve ID is the one of the first hold
14. 2nd checkin:
1. expiration date ok
2. the reserve ID is the one of the second hold
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch modifies the script and template for showing the details of
an authority record so that if the authority subfield is configured to
be a link the link is correctly output in the template.
To test you must have an authority type configured with at least one
subfield designated as a URL:
- Go to Administration -> Authority types
- Select "MARC structure" from the actions menu for the authority type
you want to modify.
- Select "Subfields" from the actions menu for the tag containing
the subfield you want to modify (for instance 856).
- Edit the subfield you want to display as a link (e.g. subfield u).
- In the subfield configuration form under "Advanced constraints" check
the "Is a URL" checkbox and save your changes.
- Apply the patch and go to Authorities in the staff interface.
- Search for or create an authority record which contains URL
information in the right subfield (for instance 856$u).
- View the details for the record. Using the 856 example, the "8" tab
should contain an active link pointing to the correct URL.
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>
Broken since
commit 0ab22e1c7c
Bug 18789: Send Koha::Patron object to the templates
Test plan:
Create or modify a patron, fill the "email" field of the "alternate
address" block (B_email)
Go to the detail view of the patron
=> Without this patch the email is not display
=> With this patch applied you see it!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Perl warning on the "About Koha" page:
Use of uninitialized value in string eq
at /home/vagrant/kohaclone/about.pl line 220.
Fixed by adding additional precheck for
C4::Context->config('zebra_auth_index_mode') being Perl's "true".
To test:
1) Ensure you don't have "<zebra_auth_index_mode>...
</zebra_auth_index_mode>" in your koha-conf.xml so you will have
"C4::Context->config" returning "undef"
2) Go to the "About Koha" page.
3) Observe the warning in the log file.
4) Apply patch.
5) Repeat step 2.
6) Check that previous warning was suppressed.
Signed-off-by: Andreas Roussos <a.roussos@dataly.gr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
On bug 24386 we prevent double form submission using the our own preventDoubleFormSubmit JS function.
The problem is that we are checking some conditions, and prevent the
form submission if something is not filled (for instance no checkbox
checked, or no fund selected).
Technically it means that:
- click the submit button
- it submits the form
- we disable the submit button
- we prevent the form to be submitted before something is wrong
At this stage the button is disabled and the form cannot be longer be
submitted.
This patch replaces the "on submit" event of the form with the "on click" event of the submit button.
Which means we are going to:
- click the submit button
- we prevent the form to be submitted before something is wrong
=> The button will only be disabled if the form is really submitted
Test plan:
- stage a marc record
- acquisitions: have a basket
- click on "Add to basket"
- "From a staged file"
- Don't tick the record
- Save
- You should see an expected error message
- Tick the record
- Save
- You should see an expected error message
- Choose a fund
- Click the "Save" button as many times as you can, to try double submit
it.
=> The order is saved
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch implements the required logic in the API code so plugins are
not affected by the new RESTPublicAnonymousRequests system preference.
It is up to the plugin develpers to handle this
To test:
1. Apply the tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/REST/Plugin/PluginRoutes.t
=> FAIL: Notice the tests fail
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass! Yay! Not bad for a friday evening!
5. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds tests the new RESTPublicAnonymousRequests syspref
doesn't apply to routes added by plugins.
It is up to the plugin developer to handle those conditions.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/REST/Plugin/PluginRoutes.t
=> FAIL: Notice the tests fail
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To prevent Apache to create intranet-error.log and opac-error.log with
root permission we chown them after it has been restarted (and so
created them) when a new Koha instance is created
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch removes the tiny_mce symlink before Koha package installation
using the same method that we used when we removed the YUI symlink
in 2015.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch removes the removal of the following during the
build process:
/usr/share/koha/intranet/htdocs/intranet-tmpl/lib/tiny_mce
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When installing the Debian package of Koha, we install the Debian tinymce package and symlink over our own tinymce libs that are in the Koha codebase. This version of tinymce does not have the same files and because of this, tinymce does not get loaded.
We should remove the use of the tinymce Debian package, and just use our own version of TinyMCE.
Test Plan:
1) Install Koha 19.11 from package
2) Browse to the news editor
4) Note the WYSIWYG editor is missing
5) Build a new Koha package with this patch applied, install it
6) Reload the news editor
7) Note the WYSIWYG editor is back!
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The current grep expression uses -x|--line-regexp, but that causes
the regexp to fail to match since we're not specifying a regexp
that can match a whole line. We can either provide a better regexp,
or remove that --line-regexp option.
This patch removes the --line-regexp (ie -x) option from the grep
in log4perl_component, so that it detects logger components correctly.
To Test:
0) Apply patch
1) Build Koha package
2) Look at /etc/koha/sites/kohadev/log4perl.conf in an existing
Koha instance (e.g. on koha-testing-docker), and note it has
components for z3950, api, and sip
3) Install package
4) Note that /etc/koha/sites/kohadev/log4perl.conf is the same as before
5) Remove the "log4perl.logger.sip and log4perl.appender.SIP lines from
/etc/koha/sites/kohadev/log4perl.conf
6) Reinstall package
7) Note that the missing lines have been appended to the file at
/etc/koha/sites/kohadev/log4perl.conf
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If think this case does not apply to real-life, but the logic needs to
be fixed.
If an item is due now, and AddReturn is called now with a return date in
the future, the issue is overdue and the patron must be debarred.
However it is not as we compare with now and not the return date
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The original development started before the changes we introduced in the guidelines in late 2019, and the major code changes that took place in January 2020.
- Attribute mapping logic is now on the Koha::Object-level (the patches implement that, but are not using it)
- Related to the above, some helper methods like to_api and to_model are kept, the same for the mappings in the controller, they should all go away
- Related to the above, set_from_api and new_from_api should be used instead of using helper to_api and to_model methods in the controller
- $c->objects->search doesn't use the to_model and to_api params
- Response status codes need to be changed, at least for DELETE operations
Those are fixed by this patch.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/advanced_editor_macros.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1. Edit the Koha/REST/V1/Cities.pm 'list' method adding
die("Nada"); before the render step.
2. Restart plack and try the endpoint
=> SUCCESS: The message is generic, but you see something is
logged in /var/log/koha/kohadev/api-error.log
3. Change die("Nada"); for a real exception like:
use Koha::Exceptions;
Koha::Exceptions::DuplicateObject->throw("Nada");
4. Repeat 2.
=> SUCCESS: The message is generic, but a meaningful text is added to
the logs.
5. Point your browser to the /api/v1/hola route from your dev
environment
=> FAIL: Wow, such a weird error
6. Apply this patch
7. Restart plack and repeat 2, 3 and 4
=> SUCCESS: No behaviour change
8. Repeat 5
=> SUCCESS: The regular Mojolicious 404 weird page
9. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1) Verify the error installing translations for any language
2) Apply the patch
3) Repeat 1), check warning is gone
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Since D10, the behaviour of start-stop-daemon changed, see from its
manual:
"""
Warning: using this match option with a world-writable pidfile or using it alone with a daemon that writes the pidfile as an unprivileged (non-root) user will be refused with an error (since
version 1.19.3) as this is a security risk, because either any user can write to it, or if the daemon gets compromised, the contents of the pidfile cannot be trusted, and then a privileged
runner (such as an init script executed as root) would end up acting on any system process. Using /dev/null is exempt from these checks.
"""
Test plan:
koha-plack --restart kohadev
should success with this patch.
Without this patch you get:
start-stop-daemon: matching only on non-root pidfile /var/run/koha/kohadev/plack.pid is insecure
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Software error:
Can't call method "unblessed" on unblessed reference at ../reserve/request.pl line 581.
was caused by recent commit with `wantarray` removal in sub pickup_locations in ‘Item.pm’
and visible on fresher Perls (where experimental feature "autoderef" removed https://www.effectiveperlprogramming.com/2010/11/use-array-references-with-the-array-operators/ )
To test:
1) Get a clean dev environment after "reset_all"
2) Add an empty record for “Default checkout, hold and return policy” on /cgi-bin/koha/admin/smart-rules.pl.
3) Open item record, like /cgi-bin/koha/reserve/request.pl?biblionumber=1&borrowernumber=1
4) Observe the error (Can't call method "unblessed" on unblessed reference at ../reserve/request.pl line 581.)
5) Apply patch.
6) Repeat steps 2 and 3.
7) Observe that the error is gone.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch puts a space between the negation operator ! and
the function name (ie log4perl_component).
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 24735 removed etc/searchengine/queryparser.yml, which removed
the need for koha-common.install to install the following file:
debian/tmp/etc/koha/searchengine
This patch removes that line and causes the Koha packages to build
correctly again.
To test:
0) Apply patch
1) Build a Koha package using one of the following methods:
- https://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way
- https://hub.docker.com/r/koha/koha-dpkg
- https://gitlab.com/minusdavid/koha-deb-builder-docker
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: PTFS Europe
Mentored-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: PTFS Europe
Mentored-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: PTFS Europe
Mentored-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: PTFS Europe
Mentored-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
