As a continuation of bug 41919, we should limit the total number of simultaneous reports that can be run at a time.
Test Plan:
1) Set total_running_reports_per_instance_limit to 2 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
5) Note the first two continue to run, but the last one gives an error
that you have too many reports running simultaneously!
Signed-off-by: Alex Carver [Acerock7] <alex@rcls.org>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
When an authorised value is limited to more than one library, the
no_limit query in GetAuthorisedValues joins authorised_values_branches
and returns one row per associated library, so the value was listed
several times in the item edition dropdown.
Group by the authorised value so each one is only returned once, and
aggregate the restricted flag with MIN() so the value stays
unrestricted as soon as one of its libraries matches the current one.
Sponsored-by: BibLibre
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
When we set an authorised value linked to one library,
users who do not belong to this library do not get the
value and can therefore overwrite it.
This patch add current value to the dropdown list even if it comes from an authorized value of another library.
Test plan :
1) Edit an item with one of these fields has an authorized value from
another library.
2) On 'edit' you will see AV but with '(Not an authorised value)' string
and a warn
3) Apply this patch
4) Refresh page and edit item again
5) Now if the authorised value belongs to another lib and is the current
value, you will see it with a tooltip and a warn. But if there are
authorised values restricted to another lib and isn't current value,
normally it will be not present in the option list.
Sponsored-by: BibLibre
Signed-off-by: Mathieu Saby <mathsabypro@gmail.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The previous follow-up only blanked the button's label via JS for
users without the recalls permission; the button still rendered,
was still clickable, and modrequest.pl's cud-convertall had no
permission check at all, so the conversion still succeeded.
Adds CAN_user_recalls to the button's template condition (matching
the existing "Move selected holds" button) so it doesn't render at
all without the permission, drops the now-redundant JS check in
holds.js, and adds a manage_recalls check in modrequest.pl itself.
checkauth()'s userid is the login username, not a borrowernumber, so
this uses C4::Auth::haspermission() directly rather than
Koha::Patrons->find().
Test plan:
1) Set a default recalls rule in admin/smart-rules.pl.
2) Set UseRecalls to 'staff' or 'opac_and_staff'.
3) Give a test patron 'catalogue' + 'reserveforothers' but not
'recalls'.
4) Check out an item, place a hold on it for another patron.
5) As the test patron, go to that record's Holds tab, confirm
'Convert selected to recall' doesn't appear.
6) Since the button is gone, confirm the server side is enforced too:
post op=cud-convertall directly to modrequest.pl and confirm it no
longer converts the hold.
7) Grant 'recalls' and confirm the button reappears and works.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This introduces a permission check on "recalls" for the link on the holds summary page.
1) Go to http://localhost:8081/cgi-bin/koha/admin/smart-rules.pl, and under the default rule, set:
- 'Recalls allowed (total)': 5
- 'Recalls per record': 3
- 'On shelf recalls allowed': if any unavailable
- 'Recall due date interval': 5
- 'Recall overdue fine amount': 5
- 'Recall pickup period': 2
2) Go to 'Administration' > 'Global system preferences' (http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfield=UseRecalls), set 'UseRecalls' to 'can be placed through the staff interface only'.
3) Go to Henry's patron account, borrowernumber 19, set him a password (http://localhost:8081/cgi-bin/koha/members/member-password.pl?member=19), then edit his permissions (http://localhost:8081/cgi-bin/koha/members/member-flags.pl?member=19) and give him only 'catalogue' and 'reserveforothers' (place holds), do not give him 'recalls'.
4) As a superlibrarian, check out item 39999000003154 (biblionumber 76) to borrowernumber 23, then place a hold on that same record for borrowernumber 49
5) Log out and log back in as Henry.
6) Go to http://localhost:8081/cgi-bin/koha/reserve/request.pl?biblionumber=76, tick the checkbox next to the hold, click 'Convert selected to recall', confirm in the modal.
7) The hold gets cancelled and a recall gets created, even though Henry has no recalls permission at all, proving the action isn't actually gated by it.
8) Apply patch, re-run test plan to 6) - The link to convert should no longer display.
9) Toggle the recalls permission for Henry, link to convert should now reappear.
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The code was using the patron's home library instead of passing the pickup-location
of the original hold. This is a simple variable change in 2 places for record level and item
level holds.
A) Set 'UseRecalls' to 'staff' at http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfield=UseRecalls
B) At http://localhost:8081/cgi-bin/koha/admin/smart-rules.pl set the default rule: 'Recalls allowed' = 5, 'Recalls per record' = 3, 'On shelf recalls allowed' = 'if any unavailable' (not 'all').
C) Use biblionumber '437' (has just one item, barcode '39999000019186'), check that item out to 'Henry Acevedo' (Patron A).
D) Place a record-level hold on it for 'Johnny Bryan' (Patron B), who's from 'Midway' — but set the hold's pickup location to 'Centerville' instead.
E) On http://localhost:8081/cgi-bin/koha/reserve/request.pl?biblionumber=437, tick the hold, click 'Convert selected to recall', confirm.
F) Check the new recall's pickup location on http://localhost:8081/cgi-bin/koha/recalls/request.pl?biblionumber=437
- Expected: 'Centerville'
- Without the patch applied, it will be the patron's home library: Midway
- With the patch applied, the pickup-location of the hold is kept: Centerville.
G) Cancel the recall.
H) Repeat the test plan, but in step D) place an item level hold instead of a record level hold.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
We are skipping the notice, if UseRecalls == "off".
This now matches the check in staff too.
A) Go to the KTD staff interface at http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfield=UseRecalls and set 'UseRecalls' to any non-'off' value, e.g. 'can be placed through the OPAC only'.
B) Log into the OPAC at http://localhost:8080/cgi-bin/koha/opac-user.pl as any patron.
C) Go to http://localhost:8080/cgi-bin/koha/opac-messaging.pl
D) Look for the recall-related notice row (item recalled / recall notices) — it's missing, even though recalls are enabled.
E) Now flip 'UseRecalls' back to 'off' in step 1's page.
F) Reload http://localhost:8080/cgi-bin/koha/opac-messaging.pl — the recall notice row now shows up, even though recalls are off.
G) Steps 4 and 6 are the reverse of what should happen — confirms the condition is inverted.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This fixes a test to use 'opac' in transfers.t
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The pref was mocked to '1' (the old value) in Holds.t
Test now uses 'opac_and_staff'
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Fixes a problem with the template variables that made the recall button
show in some places when UseRecalls was set to off.
As the problem was in item-status.inc that is used in several pages,
a small fix goes far here.
Part 1: opac-detail.tt / opac-basket.tt (default config, useRecalls = 'off')
1) Confirm UseRecalls is at its default (off)
2) Check out item 39999000003154 to patron 'Henry Acevedo'
3) Log into the OPAC as a different patron (e.g. koha user)
4) As koha user, go to the biblio detail page for the record we just checked out:
http://localhost:8080/cgi-bin/koha/opac-detail.pl?biblionumber=76
5) Look at the item's status row: next to "Checked out", a "Recall" button is visible, even though UseRecalls is off.
6) Click it, lands on opac-recall.pl, shows a "Recalls have not been enabled. Please contact your library.", which confirms it's a dead-end button that never should have rendered.
7) Same thing reproduces in the basket: as koha user, add that biblio to your cart (Add to cart on the results/detail page), then click the cart icon on the top left. The same button erroneous will show.
Part 2: opac-course-details.tt — staff-only mode still leaks the OPAC link
1) Continuing from the previous instructions: Set UseRecalls to "can be placed through the staff interface only".
2) Add the same checked-out item (39999000003154) to a course reserves list — http://localhost:8081/cgi-bin/koha/course_reserves/course-details.pl?course_id=1
3) Click "Add reserves"
4) As koha user on the OPAC, view that course's page: http://localhost:8080/cgi-bin/koha/opac-course-details.pl?course_id=1
5) The "Recall" button shows here too, even though UseRecalls=staff should mean OPAC patrons can't place recalls at all.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This follow-up includes the following changes:
- only allow a recall cancellation via the OPAC if UseRecalls is enabled for the OPAC.
- uses singleBranchMode var passed by C4::Auth in staff interface biblio recalls
- drops unused attribute_type_codes var
- drops unnecessary items var and uses biblio.items in template
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Adds a new entry "Place recall" to the detail page's toolbar, visible when:
- UseRecalls is set to allow recalls in staff
- User has recalls permission
This matches the behavior for holds and bookings, so seems to increase
consistency.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This enhancement adds the ability to place recalls via the staff
interface by changing the UseRecalls system preference to have choices which
describe where recalls can be placed. Recalls can either be placed via
the OPAC, or the staff interface, or both. To be set to OPAC would be
consistent with current 'on' behaviour. UseRecalls is turned off by default.
This enhancement also adds the ability to convert existing holds to
recalls easily via the staff interface. The hold will be cancelled
and a recall placed using the hold's information.
To test:
1) Update database and restart services
2) Set UseRecalls to OPAC and set the relevant recalls circulation rules
OPAC only by default
3) Check out Item A to Patron B.
4) Log into the OPAC as Patron A. Confirm you can place, view and cancel
recalls as normal.
5) In the staff interface, set UseRecalls to Staff interface only.
6) In the OPAC, confirm you can still view and cancel recalls, but can
no longer place recalls.
7) In the staff interface, search for Item A and go to the Holds tab.
Place a hold for Patron C.
8) Check the checkbox for your hold and confirm the counts in the buttons above the Holds table are incremented as expected.
9) Click the button to Convert selected holds to recalls, a modal should pop up. Confirm all of the information is correct.
10) Confirm the conversion and once the page refreshes, your hold should be correctly cancelled using the new RECALLED reason.
11) Go to the Recalls tab. Confirm your hold has been converted to a
recall, and details like the patron, expiration, and pickup location have
carried across to the recall.
12) On this Recalls page, use the patron search to find Patron D. Test
placing a record-level recall by choosing to recall the next available item.
13) When the page refreshes, confirm the recall was successfully placed
with the correct details stored.
14) Repeat steps 12 and 13 with Patron E, this time place an item-level
recall by choosing an item in the 'place a recall on a specific item'
table. When selecting one of these items, the 'recall next available
item' section should become disabled.
15) Set UseRecalls back to OPAC only. Go back to the record and
view the Recalls tab.
16) Confirm you cannot search for a patron to place a recall, but can
still view and cancel recalls. Confirm you also cannot convert holds
to recalls.
17) Set UseRecalls to both staff interface and OPAC. Confirm you
can place recalls on both interfaces.
18) On the staff interface, test placing recalls that your circulation
rules do not allow. For example, if 'recalls per record' is 1, ensure
you're blocked from placing a second recall on a record for a patron. Another example, testing converting a hold to a recall when there are NO checked out items, as recalls can only be placed if something is checked out.
19) Place a hold for one of the patron's that already has a recall.
Once complete, try to convert this hold into a recall. Confirm you
are blocked and shown a message that the hold cannot be converted to a
recall.
20) Confirm patron messaging preferences for recalls notices can still be configured as expected.
21) Ensure tests pass:
* t/db_dependent/Circulation.t
* t/db_dependent/Circulation/transferbook.t
* t/db_dependent/Holds.t
* t/db_dependent/Koha/Biblio.t
* t/db_dependent/Koha/Item.t
* t/db_dependent/SIP/Transaction.t
* t/db_dependent/Search.t
* t/db_dependent/XSLT.t
Sponsored-by: Auckland University of Technology
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>
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>
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>
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>
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>
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>
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>
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>
Before starting the test plan, you have to enable the following system
preferences:
CurbsidePickup, useDischarge, OPACHoldsHistory,
ILLModule,EnhancedMessagingPreferencesOPAC, CookieConsent, OPACPrivacy,
opacreadinghistory, UseRecalls, OPACHoldRequests, RoutingSerials,
EnableOpacSearchHistory, virtualshelves,suggestion,
OPACViewOthersSuggestions, TagsEnabled, OpacTopissue,OPACVirtualCard.
Test plan:
A) Add skip link to menu
1. Apply the patch, you don't have to be logged in for this part.
2. Go to these different pages: search result page, record details page
(try the different views), and Most popular page.
3. Try navigating with the keyboard, fix the focus at the top of the
page
4. You should see a skip link in red, 'skip to menu' appear. After
pressing enter, the focus should be on the menu.
5. Now go to these different pages: Purchase suggestions page, search
history page, Lists page.
6. Repeat the third step and check if the skip link "Skip to menu" does
not appear on these pages.
7. Now you have to log in to a patron account.
8. Go to your Summary page.
9. Repeat the third step with the different pages of the menu (Summary,
Charges, Personal details, Consents, Tags, Change password, Search
history, Checkout history, Privacy, Holds history, Recalls history,
Purchase suggestions, Messaging, Lists, Ask for discharge,
Interlibrary loan request, Curbside pickups, My virtual card).
10. You should see the "Skip to menu" link, after pressing enter, the
focus should be on the menu.
B) Add a skip link to the search box
1. Try navigating with the keyboard, fix the focus on the top of the
page.
2. Check if there is a skip link "Skip to the search" in red on each
page of the OPAC, except on the advanced search page.
C) Add a skip link to the footer
1. Try navigating with the keyboard, fix the focus at the top of the
OPAC page.
2. Check if there is a skip link 'Skip to footer' after the skip link
'Skip to main content' on each page of the OPAC.
3. Now, disable the system preferences (OPACReportProblem and
KohaAdminEmailAddress, CookieConsent, OpacKohaUrl,
OpacLangSelectorMode
= 'both', or OpacLangSelectorMode = 'footer') to remove the OPAC
footer.
4. Repeat step 2. Now, you should not have the skip link to the footer.
D) If all the tests succeed, sign off !
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Large files were failing to enqueue/process because the whole CSV was
embedded in the job's JSON args, hitting DB/broker size limits. This
now uploads the file via Koha::Uploader first (same pattern as MARC
staging) and only passes a small uploaded_file_id through the job,
and fixes the enqueue-failure message to not claim nothing happened
when a job was in fact created.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
patron_import.inc provides the report/detail/js blocks consumed by the
background job viewer: a summary of counts when finished, a live progress
bar while running, and the full feedback and error analysis in the detail
section. background_jobs.tt gains a patron_import entry in the job type
filter dropdown.
Test plan:
1) Apply patches, restart plack.
2) Navigate to the patron import tool:
<staff_url>/cgi-bin/koha/tools/import_borrowers.pl
3) Upload the provided sample CSV file and click 'Import patrons'.
4) Confirm the page shows "The patron import job has been enqueued!" with a link to view the job.
5) Follow the link to the background job. Confirm a progress bar is shown while the job is running.
6) Once finished, confirm the report shows the correct counts (imported, overwritten, already_in_db, invalid, total).
7) Confirm the imported patrons exist under 'Patrons'.
8) Re-import the same file with 'Overwrite cardnumber' unchecked. Confirm 'already_in_db' count is 5.
9) Re-import again with 'Overwrite cardnumber' checked. Confirm 'overwritten' count is 5.
10) Visit the background jobs admin and filter by type 'Import patrons':
<staff_url>/cgi-bin/koha/admin/background_jobs.pl
11) Confirm the jobs appear in the list.
12) Run the tests:
prove t/db_dependent/Koha/BackgroundJob/PatronImport.t
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
import_borrowers.pl now reads the uploaded file into memory and calls
Koha::BackgroundJob::PatronImport->enqueue() instead of running the import
synchronously. On success the template shows a confirmation with a link to
the background job viewer; on failure it shows an error alert.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Tests cover enqueue() (status, queue, job_size, job_type) and six
process() scenarios: happy path, import errors (with validation that
the 25-error cap has been removed), already_in_db and overwritten,
patron list creation, and cancelled job handling.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Introduces a new background job class for patron imports. enqueue() reads
the uploaded file content into the job_args and uses line count as job_size
for progress tracking. process() reconstitutes the file handle from the
stored content, delegates to Koha::Patrons::Import with step_callback wired
to $self->step, handles patron list creation, stores the import results, and
clears file_content from the stored data to free space.
Also registers patron_import in Koha::BackgroundJob::core_types_to_classes
so _derived_class can resolve the job correctly.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Adds an optional step_callback coderef parameter to import_patrons(). When
provided it is called after every row — whether the row succeeds, is skipped
as a duplicate, or is rejected as invalid — so callers can track progress.
Also removes the 25-error cap that was there to protect browser response
size; that constraint no longer applies when results are stored in a
background job's data field.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The existing tests pass even if the endpoint counts all checkouts
instead of overdues only. This patch adds a checkout due in the future
and tests the count is unchanged. It also tests that a patron without
the borrowers flag gets a 403.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This tag describes the /search/patrons endpoints added by bug 42508.
Nothing in this bug uses it, and if this bug is pushed alone main would
carry a tag for endpoints that don't exist. Bug 42508 should add it.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Returns the count of overdue checkouts for a patron as a plain integer.
Computed live from the database (date_due < NOW()) to ensure accuracy,
as overdue status is time-based with no discrete event to trigger updates.
This endpoint is intended for async loading in the patron search table,
allowing the main search results to render immediately while overdues
are fetched separately per visible page.
Test plan:
1. Apply patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/patrons_overdues_count.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Bug 39420: removed old breadcrumb - Update additem.tt
Bug 39420: Removed old edit breadcrumb.
Bug 39420: Fixing syntax error in END tag
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
To test:
1. Set the TagsExternalDictionary system preference to a non-empty value, for example:
/usr/bin/ispell
2. Restart Plack if necessary.
3. Visit a staff interface page which loads C4::Tags, such as the staff home page or a bibliographic detail page.
4. Observe:
Undefined subroutine &C4::Tags::check_install called at C4/Tags.pm line 44.
BEGIN failed--compilation aborted at C4/Tags.pm line 53.
Compilation failed in require.
BEGIN failed--compilation aborted.
5. Clear TagsExternalDictionary and clear/update the system preference cache.
6. Apply the patch.
7. Set TagsExternalDictionary to an empty value.
8. Verify that you can access the home page and other pages.
9. Set TagsExternalDictionary to a valid non-empty path such as
/usr/bin/ispell
10. Verify the staff home page, catalog detail page, and Tools page load without HTTP 500 errors.
11. Prove t/db_dependent/TagsExternalDictionary.t
12. Sign off and have a great day! :D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Move the ReportsExportLimit system preference from the
staff interface category to the reports category, as
it relates only to the reports module.
1. Go to Administration > System preferences.
2. Search for the ReportsExportLimit system preference.
3. Note that it is in the Staff interface > Options category.
4. Apply the patch.
5. Repeat step 2.
6. Note that it is now in the Reports > Options category.
7. Note that the "Reports access" section is now in sentence case.
Signed-off-by: Bastien CHAUVET <bastien.chauvet@inlibro.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The current description uses "records". It actually controls the
number of rows (or results) exported, which may or may not be records.
Additional updates were also made to improve the description notes.
1. Go to Administration > System preferences.
2. Search for the ReportsExportLimit system preference.
3. Note the use of "records" in the description - results returned may or
may not necessarily be records.
4. Apply the patch.
5. Refresh the page.
6. Note the updated description:
- "records" changed to "rows"
- changes to the notes:
. NOTE changed to bold, consistent with other descriptions
. now uses an unordered list
. active voice used
. removed note about requiring a positive vale
. added a note about the "Open in DataTables" option
7. Sign off 8-).
Current description:
Download a maximum of _____ records when downloading from the
reports module.
NOTE: Only a positive value will enforce a limit. A specific
limit in the report overrides this setting.
Updated description:
Download a maximum of _____ rows when exporting report results.
NOTE:
- Using LIMIT in a report overrides this setting.
- It does not limit results when using 'Open in DataTables'
export options.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Pedro Amorim
Lucas Gass
Kyle M Hall
Thibaud Guillot
Lisette Scheer
Katrin Fischer
Katrin Fischer
Aleisha Amohia
nina martinez
Tomás Cohen Arazi
Laura_Escamilla
Samuel Sowanick
Jonathan Druart
David Nind