Removes the deprecated _GetCircControlBranch function and its export
from C4::Circulation. Removes the corresponding tests from
Circulation.t (now covered by t/db_dependent/Koha/Policy/Circulation.t).
Test plan:
1. Apply patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/Circulation.t \
t/db_dependent/Koha/Policy/Circulation.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Alex Carver [Acerock7] <alex@rcls.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
(cherry picked from commit 8e784622815a2db2ce6f558987d7c0b0951ceec0)
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
# Conflicts:
# C4/Circulation.pm
# t/db_dependent/Circulation.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
CanBookBeRenewed checked bookings by asking Koha::Item->find_booking
for the first booking that clashes with the renewal period. When the
renewing patron's own booking satisfies this checkout, that booking is
returned first and renewal is allowed - subsequent bookings for the
item were never considered. A patron could therefore renew a booked
item straight through the start of the next patron's booking.
Additionally, when staff renew with an explicit due date (the renewal
due date input on the checkouts screen, or the hard due date on
circ/renew.pl), CanBookBeRenewed validated a *calculated* due date
whilst AddRenewal then applied the *requested* one, so the requested
date was never checked against bookings at all.
This patch:
* repeats the booking lookup with the patron's own booking excluded,
refusing the renewal ('booked') when it would run into the next
booking for the item
* adds an optional $date_due parameter to CanBookBeRenewed, used in
place of the calculated due date for the bookings check, and threads
the requested date through from svc/renew and circ/renew.pl
Test plan:
1) Run t/db_dependent/Circulation.t - the extended
'CanBookBeRenewed | bookings' subtest covers both the calculated
and requested due date cases
2) Check out a booked item to its patron, add a subsequent booking for
another patron, and attempt to renew past the second booking's
start date from the checkouts screen; confirm the renewal is
refused as 'booked'
Sponsored-by: OpenFifth <https://openfifth.co.uk/\>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/\>
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Since this is an intranet svc script (called in intranet js), there
is no need to check the session.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The log viewer displays the OPAC interface for system preference changes. Since system preferences cannot be modified from the OPAC, the interface displayed in the logs appears to be incorrect.
To reproduce:
1- Disables plack
1- sudo koha-plack --disable kohadev
2- sudo koha-plack --stop kohadev
3- sudo service apache2 restart
2- Change a system preference from the staff interface.
1- Go to Administration -> System preferences.
2- Search for a preference such as AcqCreateItem (any system preference will reproduce the issue).
3- Change the value of the preference.
4- Click Save all Acquisitions preferences (or save the preference).
3- Go to the log viewer:
1- Navigate to Tools -> Log viewer.
2- Fill the form as follows:
Librarian: leave empty
Modules: uncheck everything except System preferences
Actions: keep All actions selected
Object: leave empty
Info: leave empty
Interface: keep All interfaces
Display from: choose yesterday
Display to: leave empty
3- Click Submit.
==>The log entry shows the OPAC interface.
4- Apply the patch
5- Repeat step 1,2,3
==>The log entry shows the Staff interface.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Building on bug 41918, it would be good to limit the number of reports
a given user can run at a time. This control is config-file based as
it is tied to the server resources provided by the administrator.
Adds a new koha-conf.xml option total_running_reports_per_user_limit
(0 = disabled). When the configured limit is reached, the user is told
"You have too many reports running at the moment. Please wait for some
of them to finish before running this report again."
Note on implementation: the original patch on bz (attachment 198034)
performed a second pre-flight Koha::Reports->running call in
reports/guided_reports.pl. The bug 41918 QA follow-ups already pushed
the duplicate-running guard into Koha::Report::prep_report so it would
fire across the staff UI, svc/report and opac/svc/report. This patch
extends that same model-layer architecture rather than reintroducing
controller-layer enforcement:
- New Koha::Exceptions::Report::TotalRunning subclass of
Koha::Exceptions::Report.
- prep_report now performs a second check after the duplicate one and
throws TotalRunning when the user has total_running_reports_per_user_limit
reports of any kind already in flight.
- All three callers (guided_reports.pl, svc/report, opac/svc/report)
catch the new exception alongside DuplicateRunning, mapping it to a
new template error key total_running_reports_limit_exceeded for the
staff UI and a JSON {error: total_running_reports_limit_exceeded}
with HTTP 429 for the JSON endpoints.
Test Plan:
1) Set total_running_reports_per_user_limit to 3 in your koha-conf.xml.
2) Create 3 long-running reports like:
SELECT COUNT(*) FROM items i1 JOIN items i2 JOIN items i3 JOIN items i4 JOIN items i5 JOIN items i6
3) Run each report in turn by opening a new tab, browsing to the
reports module, and choosing to run that report.
4) Note the first three continue to run, but a fourth attempt gives
the new "too many reports running" alert in the staff UI.
5) Repeat against /cgi-bin/koha/svc/report?id=N and confirm an HTTP
429 response with JSON {error: total_running_reports_limit_exceeded}.
6) Set total_running_reports_per_user_limit back to 0 and confirm
normal behaviour resumes.
7) prove t/db_dependent/Koha/Reports.t -> 13 tests pass, including a
new subtest for TotalRunning.
Signed-off-by: Alex Carver [Acerock7] <alex@rcls.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The previous patches enforced duplicate_running_reports_per_user_limit
only in reports/guided_reports.pl. Two other code paths run saved SQL
reports for an authenticated user and bypassed the guard entirely:
- svc/report (staff JSON endpoint, eg. used for chart widgets and any
caller hitting /cgi-bin/koha/svc/report?id=N directly)
- opac/svc/report (OPAC JSON endpoint)
A user who hit their staff-UI limit could still spawn additional copies
of the same long-running report via either svc endpoint, defeating the
guard.
Push the check into Koha::Report::prep_report itself, which is the one
function all three callers go through. When the limit is reached
prep_report now throws a new Koha::Exceptions::Report::DuplicateRunning
(carrying report_id, user_id and the configured limit). The guided
reports CGI catches it and re-renders the existing "report is already
running" alert; both svc/report endpoints catch it and return HTTP 429
Too Many Requests with a JSON { error: "duplicate_running_report" }
payload.
Notes:
- The pre-flight Koha::Reports->running call is removed from the
guided-reports CGI; the model now owns that policy and the
controller is just rendering. The TOCTOU window remains identical
in size and is the same intentional trade-off as before.
- Limit=0 (the default) and absent userenv both bypass the check, so
CLI cronjobs (misc/cronjobs/runreport.pl) and direct DB users are
unaffected.
Test plan:
1) prove t/db_dependent/Koha/Reports.t - now includes a new subtest
covering limit=0 (lives), under limit (lives) and at limit (throws
Koha::Exceptions::Report::DuplicateRunning).
2) Set duplicate_running_reports_per_user_limit=1 in koha-conf.xml,
restart_all.
3) Open a long-running report in two staff tabs - second tab shows
the "report is already running" alert (unchanged behaviour).
4) While one run is in flight, hit /cgi-bin/koha/svc/report?id=N as
the same user - now returns HTTP 429 with the JSON error payload
(previously: ran a second copy of the query).
5) Same check on /cgi-bin/koha/opac/svc/report?id=N.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
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>
This patch implements fine override functionality for the checkouts
table on the circulation page (circ/circulation.pl), completing the
debt override feature for all renewal workflows.
Changes:
- Added override_debt checkbox to checkouts-table.inc when
AllowFineOverrideRenewing preference is enabled
- Updated /svc/renew to accept and process override_debt parameter,
matching the pattern used for override_limit
- Enhanced circulation-api-client.js to pass override_debt parameter
through the renewal API call
- Implemented specific CSS classes for renewal error types
(renewals-allowed-too_many, renewals-allowed-too_much_owing, etc.)
to enable selective checkbox control
- Modified override checkbox handlers to selectively enable only
relevant renewal checkboxes based on the specific blocking error:
* override_limit enables checkboxes for 'too_many' and 'on_reserve'
* override_debt enables checkboxes for 'too_much_owing' and
'auto_too_much_owing'
- Added AllowFineOverrideRenewing JavaScript variable to circulation.tt
This provides clear visual feedback to staff about which renewals will
be affected by each override option, improving usability and reducing
confusion when multiple items have different blocking reasons.
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This change makes the "Scheduled for automatic renewal" text appear
in the staff interface and OPAC only if both the issue has auto_renew
and the borrower has autorenew_checkouts set. These are the criteria that
automatic_renewals.pl uses for processing automatic renewals.
Test plan:
0. Apply the patch
1. koha-plack --restart kohadev
2. Checkout an item as an automatic renewal
(ie either set it as Automatic renewal using the checkout option or have
the circ and fines rules set to use Automatic renewals)
3. View the checkout in both the staff interface and the OPAC
4. Note that they both show "Scheduled for automatic renewal" or
"This item is scheduled for auto renewal" for the OPAC
5. In the patron record change "Allow auto-renewal of items" from
"Yes" to "No"
6. Note that the text talking about the item being scheduled
for automatic renewal no longer displays
Bonus points:
1. Run 'perl ./misc/cronjobs/automatic_renewals.pl -v'
2. Note that the automatic renewal doesn't show when "Allow auto-renewal
of items" is set to "No" but it does show when it's set to "Yes"
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Attempt to call undefined import method with arguments (search) via package C4::Utils::DataTables::VirtualShelves (Perhaps you forgot to load the package?) at svc/virtualshelves/search line 8.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Hold group target hold:
The hold that is set as the hold group's target. If a hold group has a
hold target, subsequent check-ins that would 'trap' items to the
remaining holds in the group are instead skipped.
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Anneli <anneli.osterman@koha-suomi.fi>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch removes the duplicate logging code from renewal scripts
(circ/renew.pl and svc/renew) that was part of the original Bug 9762
implementation.
The original implementation created separate logaction() calls with
custom JSON messages whenever renewal overrides occurred. This caused
double logging alongside the Alternative implementation which properly
logs overrides via the confirmations parameter in AddRenewal.
Changes:
circ/renew.pl:
- Removed unused variables: $user, $branchcode, @message
- Removed separate logaction() calls for override logging
- Changed to use confirmations array with proper codes:
* 'RENEWAL_LIMIT' for override_limit
* 'ON_RESERVE' for override_holds
- Removed C4::Log qw(logaction) import
svc/renew:
- Removed unused variables: $borrower, $user, $message, @message
- Removed separate logaction() calls for override logging
- Changed to use confirmations array with proper codes:
* 'ON_RESERVE' for on_reserve override
* 'RENEWAL_LIMIT' for too_many override
- Removed C4::Log qw(logaction) import
The Alternative implementation in AddRenewal will now handle all
override logging consistently through the confirmations parameter.
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
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>
This patch allows you to save commands that have been overridden by someone.
The patch has been updated but is not yet completed. Tests 10, 13, 14, and 17 are still not functional. Tests 15 and 16 need to be fixed as they do not display the barcode. All other tests should be functional.
To test:
--After each step, a message will be displayed in the action_logs table and in Tools > Log viewer --
Circulation -- Checking out
1) Check out an item that is age-restricted (AgeRestrictionOverride syspref)
2) Check out an item that has a “not for loan” status (AllowNotForLoanOverride syspref)
3) Check out an item that has a “lost” status (IssueLostItem syspref)
4) Check out an item to a patron who has reached the checkout limit (AllowTooManyOverride syspref)
5) Check out an item to a patron who is not allowed to borrow this item type
6) Check out an item to a patron who has unpaid fines (AllFinesNeedOverride and/or AllowFineOverride + noissuescharge sysprefs)
7) Check out an item on hold for someone else
8) Check out an item on hold ready for pickup by someone else
9) Check out an item already checked out to someone else (AutoReturnCheckedOutItems syspref)
10) Check out to a patron who has restrictions
Circulation -- Checking in
11) Ignore a hold upon check in
12) Ignore a hold and transfer upon check in
Circulation – Renewing
13) Renew an item on hold for someone else (AllowRenewalOnHoldOverride syspref)
14) Renew an item that has reached the maximum number of renewals (AllowRenewalLimitOverride syspref)
Holds
15) Place a hold for a patron who is not allowed to place this item type on hold (AllowHoldPolicyOverride syspref)
16) Place a hold for a patron who has reached the maximum number of holds
17) Place an item-level hold when rules dictate that this is not allowed (In circulation rules put "On shelf holds allowed" to "If any unavailable")
Sponsored-by: Solutions inLibro inc. <https://inlibro.com/>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
It can be useful, for instance, if a library has the same title from
different publishers (so 1 title but several biblio records) but the
user only wants a copy of the book, regardless of the publisher.
Test plan:
0. Run updatedatabase.pl and misc/devel/update_dbix_class_files.pl
1. Go to intranet search, display some results, click on some checkboxes
and click on 'Place hold' button at the top of the results.
2. Search for a patron
3. Check the 'Treat as hold group' checkbox
4. Click on 'Place hold'
5. In the next screen you should see all the holds you placed with the
additional text '(part of a hold group)' in Details column.
6. Click on the "hold group" link. A modal window should appear with
the content of the hold group (a list of holds)
7. Check in an item of one of the reserved biblios and confirm the hold
8. The hold status is changed to Waiting, and all other holds are deleted.
The other holds will also be removed from the holds queue.
9. Confirm tests pass
- t/db_dependent/Koha/Holds.t
- t/db_dependent/Reserves/HoldGroup.t
Note: the "hold group" link is displayed in the following pages:
- reserve/request.pl
- circ/circulation.pl
- members/moremember.pl
- circ/pendingreserves.pl
- circ/view_holdsqueue.pl
Note: A hold group is counted as only one hold
Sponsored-by: Catalyst IT
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
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>
We can now call metadata_record directly on the Koha::Biblio object.
This aptch updates all modules and controllers to use
Koha::Biblio->metadata_record directly where appropriate. The
exceptions are where we don't require any filtering or the filtering
makes sense to do after the initial fetch.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When viewing patron checkouts table from details or circulation page, overdue checkouts
are preselected for renewals and the overdue dates are bolded and red. This patch will enable
also preselecting checkouts that are due on the current day. The due dates for these checkouts
will be bolded but not red.
Test plan:
1) See/create a patron with several checkouts: overdue, due today and due later.
2) Note that only the overdue checkouts have a checkmark on Renew column when loading the table.
3) Apply patch.
4) Load the checkouts table again. Note that now also the checkout due today has a preselected renewal
checkmark and the due date has been bolded.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This enhancement prevents SQL queries from being run if they would return a password field from the database table.
To test:
1. Run tests and notice they fail t/db_dependent/Reports/Guided.t
2. Apply patch and restart services
3. Create a public report with an SQL report which would access a password column in a database table
4. Try to run the report. Notice you are met with an error and the results are not shown.
5. Access the JSON URL, you should not get the results and should be shown an error
6. Confirm tests pass t/db_dependent/Reports/Guided.t
Sponsored-by: Reserve Bank of New Zealand
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>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This change validates the "type" sent to the barcode/svc. Without this
change, we pass the user input directly to GD::Barcode, which passes
the input into an eval{} block without any validation of its own.
Test plan:
0. Apply the patch
1. koha-plack --reload kohadev
2. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=bad&barcode=123456
3. Note that a Code39 barcode is provided for an invalid type
4. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=Code39&barcode=123456
5. Note that a Code39 barcode is provided
6. Go to http://localhost:8081/cgi-bin/koha/svc/barcode?type=UPCE&barcode=123456
7. Note that a non-Code39 barcode is provided (presumably UPCE)
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 73b0c3cf621250008845f22f7a36f90a48e00b06)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There is a typo in svc/club/enroll - it tries to call
Koha::Club::Entrollments->search when it should be
Koha::Club::Enrollments. This causes and error when
enrolling patrons in clubs.
Test plan:
1. Without the patch, Tools - Patron clubs - New club template - name it
and save
2. New club - (your template) - name it and save
3. Circulation - check out to a patron - Clubs tab - Enroll - Finish
enrollment, get alert() about failure to enroll
4. Apply patch, restart_all
5. Enroll - Finish enrollment, success
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>
When an unauthorized call to svc is made, we use the ErrorDocument middleware to respond with an HTML
page. The API doens't do this, it simply returns its status. We should mount the svc as its own app to avoid
the redirect to HTML for unauthorized responses
To test:
1 - Create a report
2 - Add to IntranetUserJs:
$(document).ready(function() {
// Your report ID
var reportId = '492';
// Fetch the report
$.get('/cgi-bin/koha/svc/report?id=' + reportId, function(data) {
console.log('Kaboom');
});
});
3 - Log out
4 - Attempt to login
5 - KO
6 - Apply patch
7 - Reset all (or copy the necessary changes to your plack/apache files)
8 - Generate report and update user js again
8 - Logout, login
9 - Success!
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test Plan:
1) Create 3 clubs, 1 limited to library A, 1 limited to library B and one not limited
2) Use a patron with home library A.
3) Go to the opac-user page, "Clubs" tab show 0/2 (the one from library B is not listed)
4) Browse to /cgi-bin/koha/svc/club/enroll?id=1
5) Reload that page a couple times
6) Note the patron is now enrolled in the same club multiple times
7) Delete those enrollments
8) Apply this patch
9) Restart all the things!
10) Repeat steps 2-7, note the lack of duplicate enrollments!
11) Repeat steps 2-10 for the staff interface
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the option to specify a framework to be used when overlaying records from webservices/connexion
To test:
1 - vim /etc/koha/sites/kohadev/connexion.cnf
2 - Set content:
host:
port: 8888
koha:http://localhost:8081
log:/var/log/koha/kohadev/connexion.log
match:ISBN
user:kohauser
password:kohapass
overlay_action:replace
nomatch_action:create_new
item_action:always_add
import_mode:direct
framework:BKS
overlay_framework:
debug:1
3 - Save the sample file from this bug into your kohaclone (or copy and paste into a file your koha test site can reach)
4 - On the command line:
perl misc/bin/connexion_import_daemon.pl -c /etc/koha/sites/kohadev/connexion.cnf
5 - In another terminal:
cat bug_33418.test | nc -v localhost 8888
6 - It should report success and a biblionumber
7 - In Koha: Cataloguing->Manage staged MARC record
8 - View the most recent batch with file name (webservice)
9 - Confirm it was imported, no match
10 - Click 'View' under the 'Record' column
11 - Confirm record loads correctly and 'MARC framework' detail is 'Books, Booklets, Workbooks'
12 - On the terminal repeat the command:
cat bug_33418.test | nc -v localhost 8888
13 - It should succed
14 - View the new batch, confirm the record matched this time
15 - View the record details, confirm framework is now 'default'
16 - On the first terminal hit Ctrl+C to stop the daemon
16 - Edit connexion.cnf and change:
import_mode:stage
framework:ACQ
overlay_framework:IR
17 - Restart daemon:
perl misc/bin/connexion_import_daemon.pl -c /etc/koha/sites/kohadev/connexion.cnf
18 - Delete the record created above
19 - On the second terminal repeat the command:
cat bug_33418.test | nc -v localhost 8888
20 - Confirm the batch is created, but not imported
21 - In terminal:
perl misc/cronjobs/import_webservice_batch.pl --framework=ACQ --overlay_framework=BKS
22 - Confirm batch imported, and record in ACQ framework
23 - In terminal:
cat bug_33418.test | nc -v localhost 8888
perl misc/cronjobs/import_webservice_batch.pl --framework=ACQ --overlay_framework=BKS
24 - Confirm batch added, record matched, record imported, and record now in Books framework
25 - Stop the deamon, edit connexion.cnf:
import_mode:direct
26 - Start the daemon, and on other terminal repeat:
cat bug_33418.test | nc -v localhost 8888
27 - Confirm record in Binders framework
28 - Set record framework to Books
29 - Stop daemon, edit cnf and remove 'overlay_framework' setting
30 - Start daemon and cat the file again
31 - Confirm the record remains in Books framework
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Also change the cache key in template plugin. And the X- header
that had an underscore in svc script.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We need to set the content type to application/json for the svc scripts
returning json
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Add some checkouts and load the issues-table
2. Select 'Check in' checkbox for that item and click "Check in selected items"
3. The row becomes read and reads "Unable to check in"
4. Reload the page, the item has actually checked in
5. Try the 'Renew' checkbox and click "Renew selected items"
6. It just spins and spins.
7. Reload the page, the item has actually renewed.
8. APPLY PATCH and restart_all
9. Try the steps again and this time everything should work properly.
10. tests these URLs
http://localhost:8081/cgi-bin/koha/svc/recallhttp://localhost:8080/cgi-bin/koha/svc/club/enrollhttp://localhost:8081/cgi-bin/koha/svc/mana/increment : empty response
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
No desire to have a nice api client for this.
This patch also:
Improve failure handling
Remove unecessary code in svc script
Remove duplicated on click binding
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Removing the ability to remove several cover images, it was not used.
FIXME - Note that I am getting randomly a failure when uploading an image and
seeing the following error in the log:
[Wed Feb 21 10:43:59.168934 2024] [cgi:error] [pid 24037] [client 172.18.0.1:45074] AH01215: Use of uninitialized value $fileID in bitwise and (&) at /kohadevbox/koha/tools/upload-cover-image.pl line 101.: /kohadevbox/koha/tools/upload-cover-image.pl, referer: http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=1
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GET svc/authentication will return a CSRF token in a response header
POST svc/authentication requires a CSRF token which can be sourced
from the response header of GET svc/authentication or some other
place like the meta element on a HTML page
Note: misc/migration_tools/koha-svc.pl is a simple script which
can be used to practically evaluate svc/authentication and svc/bib
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Tomás Cohen Arazi
Aleisha Amohia
Martin Renvoize
Marcel de Rooy
Hammat Wele
David Cook
Pedro Amorim
Julian Maurice
Jonathan Druart
Nick Clemens
emilyrose
Aleisha Amohia
Koha Development Team
Martin Renvoize
Katariina Pohto
Phil Ringnalda
Kyle M Hall
Lucas Gass