Instead of updating only when DT init is complete we are going to update
the visibility when the table will be redrawn.
Test plan:
1 - Find/Add a bib record with no items
2 - Add 20 items from Centerville
Edit ->Edit items -> enter CENTER1 into barcode ->'Add multiple copies' -> 20
3 - Add 20 items from Fairview as above but enter 'FAIR1' for barcode and 'FAIR ITEM' as callnumber
4 - Add 1 item from Midway with barcode MIDWAY1
5 - Edit a midway patron to grant 'catalogue' and 'edit_items' permission - NOT edit_any_item
6 - Sign in as the patron above
7 - Find the record
8 - Note there is callnumber and actions/edit columns
9 - Go to page 2 of items - callnumber visible
10 - Go to page 3 - edit column
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>
tar has exit status 1 if any file has changed while being read, which is likely to happen as the logfiles are included. this patch will catch these harmless errors so that koha-dump will still return a success code.
Test plan:
1. Create a number of backups and edit their modify time to being older than 2 days
2. run the koha-run-backups script and try and write to one of the files it includes while it's being backed up (you'll trigger a warning from tar saying the file changed as it was being read)
3. verify that the older backups are not being cleaned up and deleted despite new backups being made.
4. Apply this patch
5. Complete steps 1-2 again and then go and look to see if the older backups are being deleted.
Sponsored-by: Catalyst IT
Signed-off-by: David Nind <david@davidnind.com>
Co-authored-by: Michał Kula <148193449+mkibp@users.noreply.github.com>
Signed-off-by: Michał Kula <148193449+mkibp@users.noreply.github.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This is cheating, yes.
We had a cypress test failing because of this line
$(...).tooltip is not a function
It's failing randomly on Admin/RecordSources_spec.ts, which does not
need the tooltip.
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>
Not really sure why we had this line, but Owen decided to remove it when
upgrading to Bootstrap5.
So let's remove them from the other files as well.
Waiting for Owen to confirm this one.
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>
This reverts commit 23b00bdc06.
JD: No, really, don't wait.
And it does not fix the issue initially raised on bug 37917
https://bugs.koha-community.org/show_bug.cgi?id=38049
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>
The original submission missed a number of slip types that are print on
demand without queueing.
These all need an "id" passing in to the template and in some cases we
were also missing passing in the new style parameter too (preservation)
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When moving the style up, it was moved before the code that handles printing a single slip, i.e.
taking the variables and forming a slip hash.
This patch moves that code to the top and additionally passes through the CODE of the notice so the ID is not blank
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch moves the local style sections from the body to the head
where they belong and it also updates the regular expression used to
prepend the slip_id id to css selectors rather than replace them
To test:
1 - Create a new notice in the 'Patron (custom slips)' module called 'Testing'
2 - Set print content as:
Try the <span class="styled">styling</span> stuff.
3 - Set the 'Format' as:
.styled {color:red;font-weight: bold;}
4 - Set system preference IntrnaetSlipPrinterJS to "//test"
http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfield=IntranetSlipPrinterJS
This will prevent auto printing popup
5 - Go to a patron and click Print -> Print Testing
6 - Note incorrect styling
7 - Apply patch, restart all
8 - Print Testing again
9 - Confirm styling is correct
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The ability to create fast add records was fixed on bug 38076, but they still cannot be edited after they are saved.
Test Plan:
1) Create a librarian with only fast add cataloging permissions
2) Create a fast add record, save it
3) Attempt to edit that record, you cannot!
4) Apply this patch
5) Restart all the things!
6) Attempt to edit that record, you can!
7) Attempt to edit a non-FA record, you cannot!
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Any librarian with the edit_catalogue sub-permission should also be able
to edit fast catalog records. If that was not true, a cataloger could
not convert fast adds into full records.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If a librarian does not have the editcatalogue permission, but does have the fast_cataloging permission, they should be able to add and edit fast cataloging records. Instead they are presented with a login screen and the message that they do not have sufficient permissions.
Test Plan:
1) Create a librarian with only fast add cataloging permissions
2) Attempt to create a fast cat item from the circ menu
3) Note the login screen and error
4) Apply this patch
5) Restart all the things!
6) Try again, you can now create FA records!
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The form cannot longer be saved, and no appear appear (nothing in log,
nothing on the UI)
This is coming from bug 37955 where we modify the table_id to fix
anchors, but we didn't care of the rest of the code using this TT
variable.
This patch suggests to replace # and _ with |
Test plan:
Confirm that the form can be edited, saved, and that it is taken
correctly into account.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When using the Koha acquisition module to receive items (basket receiving
an order), Koha does not consideration of UniqueItemFields setting.
The problem is that you can accidentally attach 3 items to an order with the same values.
Test plan:
1. Set preference UniqueItemFields: Public note (itemnotes)
2. Go to the acquisition module.
3. Create a basket with the option for 'Create items when:' set to receiving an order.
4. Add an order to the basket, for example: From a new (empty) record with the Quantity set to 3 or more.
5. Close the basket.
6. Receive the order.
7. Add a public note: TEST, and receive the first item (Add item).
8. You will see that the next item has the same public note.
9. Apply this patch and repeat step 7 - the public note is not used for the next note.
Sponsored-by: kohawbibliotece.pl
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1. Have additional language installed and set up for OPAC
2. Search something
3. Notice "Item types" facet label untranslated
4. Apply patch and make sure translations are updated
5. Observe facet label "Item types" translated
6. See patch [1] "Bug 36750: Fix some labels" in Bug 36750
7. Observe item type change missing for OPAC but present in staff client
[1] https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=166289
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Tiny adjustment for very special and malicious cases needed in
Koha::SearchEngine::Elasticsearch::QueryBuilder::clean_search_term.
Extended unit tests added following Nick's suggestions in
Bug 33407 discussion.
Test plan
=========
1. Use ktd with Elasticsearch and ktd's test data.
2. Edit the 4th record (The C programming language) and add a semicolon
followed by a space before the slash in 245 $a to have:
The C programming language ; /
3. Make a search for the first ISBD zone taken verbatim from the forth
record:
The C programming language ; / Brian W. Kernighan, Dennis M. Ritchie
There should be no result.
4. Apply the patch, restart plack.
5. Repeat the search. You should get the record.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This bug ensures that the facet labels for holdingbranch and homebranch are updated, regardless of how the DisplayLibraryFacets system preference is set.
To test:
1. Check out an earlier version of Koha, for example `git checkout v23.11.08-1`
2. Spin up your development environment with elasticsearch, for example `ktd --es7 up`
3. Once it's ready, go to the staff interface and search for the DisplayLibraryFacets system preference in Koha administration. Set to 'holding library' if not already.
4. Do a catalogue search, notice the facets on the side. "Holding libraries" should show as normal. There should be no facet for home libraries.
5. In your terminal, check out 24.05.x, for example `git checkout v24.05.03`
6. Run database updates to upgrade Koha, for example `sudo koha-upgrade-schema kohadev`, and restart services `restart_all`
7. Repeat step 4. Notice the error in the facets "homelibrary"
8. Apply patch from Bug 37446
9. Repeat step 6
10. Repeat step 4. This time the facet should read "Home libraries"
Sponsored-by: Toi Ohomai Institute of Technology
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a regex (thanks to Katrin for the help) specific to the
range of values which will be accepted by the discount column in the
database which has the type "float(6,4)".
The patch also removes the format() filter from the template so that
values returned from the database won't be truncated:
Using "format ('%.1f')", a value in the db of '9.009' would appear in
the edit form as '9.0', a change which could be missed if the user was
editing some other field in the vendor edit form.
To test, apply the patch and clear your browser cache if necessary.
- Go to Acquisitions -> Vendors -> Edit vendor.
- Under "Ordering information," test entering various values in the
"Discount" field. It should accept numbers with up to two digits
before the decimal and up to three digits after the decimal:
9, 99, -99, 99.9, 0.99, 99.99, 99.999
- In each of these cases, confirm that a value accepted by the
client-side validation is also accepted when you submit the form and
is correctly displayed when you edit that vendor again.
- It should not accept:
100, 100.001, 100.00001
- The error message has been updated to read, "Please enter a decimal
number in the format: 0.0"
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Sonia <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When a comma is used to define the discount rate of a vendor,
the data is not recorded (as NULL), it is however recorded if the
separator is a point.
Test plan:
1) Go to acqui module and edit a vendor
2) Set a discount rate with a comma as decimal separator
3) Edit again or request your database to see that there is no data
saved
4) Do it again with a point as decimal and see it works
5) Apply this patch and reloard the build for the templates
6) Repeat step 2 and see the warning to inform you that you must use a
point
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Sonia <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the missing "dropdown-item" class to the "Run with
template" dropdown menu markup in order to correct the menu's style.
The patch also adds a template ID to the menu items' id attributes so
that we don't have duplicate IDs.
To test, apply the patch and go to Tools -> Notices.
(testing steps copied from Bug 36157)
1. Create a notice with the module of "Reports" -- add something to the
"Print" section. Example from the other bug:
[% FOREACH b IN data %]
<div class="panel panel-default">
<div class="panel-heading">[% b.surname %], [% b.firstname %]</div>
<div class="panel-body">Expiration: [% b.dateexpiry %]</div>
<div class="panel-footer">ID: [% b.borrowernumber %]</div>
</div>
[% END %]
2. Create and run a saved report. Example from bug 36157:
SELECT * FROM borrowers
3. Click on the "Run with template" dropdown and confirm that it is
styled correctly.
4. Click to run the report with the template and confirm that it works
correctly.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Noticed this while debugging a search related problem on a live server. This is cosmetic only.
Signed-off-by: Shi Yao Wang <shi-yao.wang@inlibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Auto renewals via phone are only disallowed because itiva did not support them.
There is no reason to disallow auto-reneals for the generic phone transport.
Twilio, for example, would have no problem sending those phone notices.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Note you can now select phone for auto-renewals!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
"Upload image" item not correctly styled
Test plan:
Go to the bib detail page with at least one item.
Open the action dropdown list and notice the "Upload image" is correctly
styled with this patch
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch updates the OPAC header so that if opacuserlogin is off and
there are no public shelves, the Lists button does not appear. If
opacuserlogin is turned off the only kind of lists the user can interact
with are public ones, and without public lists there's nothing to do.
To test, apply the patch and test the arrangement of the OPAC header in
these cases:
- opacuserlogin is on, user is logged in, and there are no public lists:
- The Lists button appears and contains only "Your lists" menu items.
- opacuserlogin is on, user is logged in, and there are public lists:
- The Lists button appears and the menu contains controls for both
public and private lists.
- opacuserlogin is off and there are public lists:
- The Lists button appears and shows only controls for public lists.
- opacuserlogin is off and there are no public lists:
- The Lists button does not appear.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If patron has privacy==2 ("Never: Delete my history immediately"), the "Export today's checked in barcodes" button is supposed to be disabled, with a tooltip with an explanation, but it is not.
Test plan:
Turn on OpacPrivacy and select "Never" in your privacy settings (OPAC)
Go to the circulation page for this patron (staff) and notice that the
export button (under "More") is disabled and has a tooltip when the
mouse hover it.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When scroling down <staff_url>/cgi-bin/koha/tools/modborrowers.pl,
there is a point where the table header leaves the normal flow of
the page to stick to the top of the screen instead. When this
occurs, the header becomes fixed: if scrolling through the table
horizontally, only the body will move. This is an issue as it means
that in this situation, some column headers cannot be viewed and the
data does not necessarily match the header under which it is found.
This patch resolves this issue by allowing the header to scroll
horizontally and ensuring that the width of the column headers
still match that of the columns themselves.
Test plan:
A) Reproduce the bug as per Pedro's intructions:
***
1) Visit "batch patron modification":
<staff_url>/cgi-bin/koha/tools/modborrowers.pl
2) Enter multiple cardnumbers, in k-t-d you may use these:
23529000104159
23529000120056
23529000714163
23529000651225
23529000445172
23529000105040
23529000224510
23529000591678
3) Press "Continue"
4) Scroll down the page enough that the table headers row becomes
"detached"
and sticks to the top of the page as you scroll down.
5) Scroll the table horizontally. Notice the headers are stuck even
though
the data columns have moved horizontally, causing the headers and
data to
not match.
***
B) Apply the patch
C) Go through steps 1-5 again. This time, notice that the header scrolls
along with the table body and that the column headers and data always
match.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Some SUSHI providers return ServiceActive instead of the documented Service_Active:
https://countermetrics.stoplight.io/docs/counter-sushi-api/f0dd30f814944-server-status
This ensures the test connection does not fail regardless of what is used
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1) Apply only tests patch, run:
prove t/db_dependent/Koha/ERM/EUsage/UsageDataProvider.t
2) Verify tests fail
3) Apply fix patch
4) Run tests again, verify they pass
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
1) Apply both patches
2) $ qa -c 2 -v 2
Amended-by: Jonathan Druart
Add the different attribute at the end of the node so that we can easily
see what's different between the two lines
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The bug is caused by the SMS data not being submitted as its fieldset is disabled if SMSSendDriver is empty.
This causes the SMS instance of the notice to not be updated when the edit happens, becoming out of sync.
Once it becomes out of sync with the other notices of same code but different transport_type, the 'GROUP BY branchcode,module,code,name,branchname' in letter.pl will fail, as the name no longer matches, listing the same notice twice on the notices table.
This patch updates the logic on the template to have the SMS input elements be disabled/readonly instead of having disabled='disabled' on the SMS fieldset.
This keeps the same functionality i.e. staff member is unable to edit SMS notice if SMSSendDriver is disabled, but ensures that SMS related data is submitted to the controller when the notice edit save happens.
Test plan:
1) Visit notices and slips:
<staff_url>/cgi-bin/koha/tools/letter.pl
2) Search for a notice code e.g. 'ILL_REQUEST_UPDATE'.
3) Notice only one result is returned. Click 'Edit'.
4) Edit the 'Name'. Click 'Save'.
5) Repeat 2. Notice two results are now returned.
6) Apply patch. Repeat test plan. Notice only one result is returned at the end.
Signed-off-by: Jason Robb <jrobb@sekls.org>
Amended-by: Jonathan Druart
Align
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Not sure how this is coming from, neither why we have not noticed that
before, but "sound" is listed under `koha-translate --list`
It's coming from `ls koha-tmpl/intranet-tmpl/prog`
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch limits indexing of field 246 to $a, $b, $n, and $p in
various title indexes.
Previously, all 246 subfields were indexed, including non-title
subfields such as $i (Display text), $g (Miscellaneous information),
and linking subfields, making the title index very large and giving
false results.
To test:
1. Add all the 246 subfields to the default bibliographic framework
1.1. Go to Administration > MARC bibliographic framework
1.2. Click Actions > MARC structure next to the Default framework
1.3. Search for 246
1.4. Click Actions > Edit subfields
1.5. For each subfield, make sure Editor is checked
1.6. Click Save changes
2. Create a new record and fill out all the 246 subfields
2.1. Go to Cataloging
2.2. Click New record
2.3. Fill out the mandatory fields (000, 003, 005, 008, 040$c,
245$a, 942$c)
2.4. Fill out all the subfields in 246 (I simply write the name of
the subfield in the text field e.g. Display text in 246$i)
2.5. Click Save
2.6. Click Normal to access the detailed record
3. View the Elastic search record
--> All the subfields (including "Display text", "Miscellaneous
information" and other non-title subfields) should be indexed in
- title
- title__suggestion
- title-abbreviated
- title-abbreviated__sort
- title expanded
- title-expanded__sort
- title-former
- title-former__sort
4. Make a title or keyword search for "Display" (or whatever you wrote
in 246$i)
--> Your record should be in the results
5. Apply patch
6. Rebuild the index using -r
koha-elasticsearch --rebuild -d -r -v kohadev
7. Redo step 3
--> Only 246 $a, $b, $n, and $p should be indexed
8. Redo step 4
--> Your record should NOT be in the results
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Add the ability to specify STOMP connection info via environment
variables and utilize those in unit tests.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch makes the background jobs (jobs from now on) connect step not
try to connect to the STOMP broker, unless explicitly told to do so.
This is achieved by using a newly introduced system preference
`JobsNotificationMethod` which falls back to STOMP if undefined.
The "about" page now has 3 states for
+ Message broker: Using SQL polling
+ Message broker: Using SQL polling (Fallback, Error connecting to RabbitMQ)
+ Message broker: Using RabbitMQ
The goal for this patch is to stop flooding the logs on very busy sites
when Rabbit is not being used. This shouldn't predate any efforts on
making the STOMP based jobs brokering mechanism solid and usable.
To test:
1. On clean `main`, run:
$ ktd --shell
2. Open the logs on a separate terminal:
$ ktd --shell
k$ tail -f /var/log/koha/kohadev/*.log
3. Stage some MARC for import
=> SUCCESS: No warnings about STOMP
4. Import the staged records
=> SUCCESS: No warnings about STOMP
5. Stop rabbitmq:
k$ sudo service rabbitmq-server stop
6. Repeat 2-4
=> FAIL: The logs say it couldn't connect to STOMP
7. Apply this patches and run:
k$ restart_all
8a. See the "about" page, should read:
Message broker: Using SQL polling (Fallback, Error connecting to RabbitMQ)
8b. Repeat 2-4
should work with one warning in the
9. Start rabbit:
k$ sudo service rabbitmq-server start
k$ restart_all (not really necessary)
10a. See the "about" page, should read:
Message broker: Using RabbitMQ
10b. Repeat 2-4
=> SUCCESS: No warnings about STOMP
11. Change the `JobsNotificationMethod` system preference to *polling*
and stop rabbit:
k$ sudo service rabbitmq-server stop
k$ restart_all
12a. See the "about" page, should read:
Message broker: Using SQL polling
12b. Repeat 2-4
=> SUCCESS: No warnings about STOMP, not even on startup
13. Sign off :-D
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
There's a regression in bug 32256 and commit bb059abe respectively:
https://gitlab.com/koha-community/Koha/-/commit/bb059abe90#a22dc682a84c41672294c66e441329a451b5cd5a_137_137
The refactoring of "renew" -> "c.renew" missed this line (at least), so the condition is never met.
This fixes the issue and restores the original functionality.
Test plan:
1. log in with a patron at http://localhost:8080/cgi-bin/koha/sco/sco-main.pl
2. check out an item
3. scan it again
4. see that the "return this item" choice isn't proposed. This is the
bug
5. apply patches
6. rescan the item in the self-check out
7. returning is proposed
8. check it in and confirms that it's not checked out anymore
Signed-off-by: Oliver Behnke <oliver.behnke@aei.mpg.de>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
At the moment, the filtering on item results page
requires using the code in the following fields:
- Collection
- Home library
- Current library
- Shelving location
- Itemtype
- item status -fields (not for loan etc)
So e.g. "Centerville" in Home library -field doesn't
bring back results but code "CPL" does. This happens
because "columns" option in search results table
isn't working when its used in function columnFilter.
However option "aoColumns" works.
To test:
1. Navigate to item search and search items.
=> Note that all filters in search result table
are free text fields.
2. Attempt to filter search results by home library
with description of some library.
=> No results are displayed.
3. Now filter results with code of the library.
=> Results are now displayed.
4. Apply this patch and refresh page.
5. Search items again.
=> Note that now some of the filters are now using
dropdown select fields.
6. Attempt to filter results by home library again.
=> Results are now displayed correctly.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Olivier Hubert <olivier.hubert@inlibro.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The REST API has a default page size of 20, controlled by the preference
RESTdefaultPageSize. That's fine for things that are fetched to display
in pages of 20, but for things like macros in the Advanced Editor that
don't implement paging, it's awkward, since when you create your 21st
macro, it disappears the next time you open the editor.
The Advanced Editor should instead disable paging by passing the param
_per_page=-1
Test plan:
1. Set the preference EnableAdvancedCatalogingEditor to Enable. While you
are there, set the preference RESTdefaultPageSize to 2, so you don't have
to create 21 macros to see one disappear
2. Cataloging - Advanced editor - Macros
3. Click New macro..., give it the name 1, then repeat for 2 and 3
4. You have a list of macros open with all three listed, so far so good.
Refresh the browser page and reopen Macros. You now have two macros
5. Apply patch, refresh the page, reopen Macros. You now have three macros
6. You should probably reset that RESTdefaultPageSize back to 20 if you
aren't about to reset ktd
Sponsored-by: Chetco Community Public Library
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
-Newly created or edited libraries no longer display 'null' for undefined
open and close times.
-Libraries without any defined hours will state such instead of displaying the
hours table.
-The CalendarFirstDayOfWeek system preferences is now respected when viewing
a library with defined hours.
-Time displays and inputs now follow the TimeFormat system preference.
-Times are no longer displayed with seconds.
As part of this patch, a new Template Filter, KohaTimes, has been added to
allow for proper formatting of time strings based on systems preferences.
To Test:
1. Login to staff interface
2. Go to Koha administration > Basic parameters > Libraries
3. Edit any library or create a new library. Do not set hours.
4. Save the library.
*Note that on the library list, in the hours column, all days are displayed
with 'null'.
5. Edit or create a 2nd library.
6. Try to manually enter a time (not using the flatpickr modal)
*Note that the mask wants a date format, not a time format.
7. Set some hours for the library, leaving at least one
day without hours. Save.
*Note that in the library list, in the hours column, defined times are in
the format HH:MM:SS.
7. Edit the system preference CalendarFirstDayOfWeek to set a day other
than Sunday as the first day of the week.
8. Return to Koha administration > Basic parameters > Libraries
9. Click on the name of a specific library with hours to view details.
*Note that the order of the calendar weeek still starts with Sunday.
10. The order of the calendar week still starts with Sunday.
11. Edit the system preference TimeFormat and set to 12-hours.
12. Return to Koha administration > Basic parameters > Libraries.
*Note that the time format on the branches list is not in 12-hour format.
13. Click on the name of a specific library with hours to view details.
*Note that the time format in the branch details screen is not in 12-hour
format.
14. Apply Patch.
15. Return to Koha administration > Basic parameters > Libraries
16. Verify that your library with all undefined times shows "Library hours
not set".
17. Verify that your library with defined hours is showing times in HH:MM
format, and days without defined hours are blank.
18. Verify that your library with defined hours is respecting the TimeFormat
preferences.
19. Click on the name of a library with hours to view details.
20. Verify that the hours respect the CalendarFirstDayOfWeek and TimeFormat
preferences.
21. Click on the name of another library without hours to view details.
Verify these libraries show as "No opening hours have been set"
in the branch detail view.
22. Edit a library's hours. When inputing, try to manually enter a time (not
using the flatpickr modal). Verify that you can enter time in the proper
(12 or 24 hours) format.
Sponsored-by: Westlake Porter Public Library
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In the curbside pickup module, when the "Schedule a pickup" tab is selected we expect
the patron search box to get the focus. But it has been broken bug 30965 (which changed the id of the input).
Test plan:
Setup curbside pickup for your library
Go to Circulation > Curbside pickups
Click the last tab
Notice that you can directly search for a patron, the input has the
focus
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Jonathan Druart
Aleisha Amohia
Martin Renvoize
Nick Clemens
Tomas Cohen Arazi
Kyle M Hall
Michał Dudzik
Lari Taskula
Janusz Kaczmarek
Aleisha Amohia
Owen Leonard
Thibaud Guillot
Pedro Amorim
Lucas Gass
Chloe Zermatten
Caroline Cyr La Rose
Oliver Behnke
Emmi Takkinen
Phil Ringnalda
CJ Lynce