To test:
1. Make sure MarkLostItemsAsReturned is set so a lost item will stay on a patrons account after being marked as lost.
2. Check an item out to a patron, make sure it has a replacementprice
3. Mark the item as lost.
4. Now check the item in.
5. Go to the patrons account -> transaction tab. You should see 2 accountlines related to the item.
6. For the account type 'Lost item' you will see issue infomation ( check out date, due date, checkouted out from, etc )
7. For the account type 'Lost item fee refund' there is no issue information.
8. Apply patch
9. Try 2 - 6 again. This time the 'Lost item fee refund' should include issue information.
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
No need to do a walk through on all the results.
Correcting two test descriptions on the way.
Test plan:
Run t/db_dependent/Koha/Item.t
Run t/db_dependent/Koha/Items.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Prefetching is useful, but we don't want to fetch all the inactive
transfers for an item. This patch adds a filtered relationship and
updates get_transfer(s) to use this
To test:
prove -v t/db_dependent/Koha/Item.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch corrects a string in the staff interface's ILL requests
template. "This item cannot be issued as it has no biblio record
associated with it" is updated to read "This item cannot be checked out
as it has no bibliographic record associated with it."
I don't know how to trigger the error message in the interface, but the
change is simple enough that it could be verified by examining the
patch.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1 - Find an adult patron in Koha
2 - Add two guarantees
3 - Add $1 fine to parent, $5 fine to each guarantee
4 - Set no issues charge guarantees to 9
5 - perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL -m patron_information --patron BARCODE
6 - Note the 64 message starts with Y's that mean patron is blocked
7 - Repeat with each child barcode
8 - They are blocked?
9 - Apply patch, restart all (restart_all will restart SIP)
10 - Try again
11 - Parent blocked, children should not be
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Both Elastic and Zebra search_auth_compat return a hash key
authid for a result.
Test plan:
Remove an authority that should be in your results list.
Note that it is no longer marked as pending, but just not displayed.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When an authority is removed from the result list it is not removed from
the search engine yet.
This patch suggests to add a note in the summary column to tell the user
that the deletion is pending.
Test plan:
1 - Go to authorities home and perform a search;
2 - Delete any authority;
3 - After the confirmation, the page is refreshed but still contains the
deleted authority, with a red note explaining that the deletion is
pending.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch attempts to fix a UI issue on addorderiso2709.tt. It removes the <td> which contains the actoin buttons MARC, Card, and Add Order and adds them to the title line. This is so there is more space for the fieldsets.
1. Apply patch
2. Set MarcItemFieldsToOrder like this:
homebranch: 975$a
holdingbranch: 975$b
itype: 975$y
nonpublic_note: 975$x
public_note: 975$z
loc: 975$c
ccode: 975$8
notforloan: 975$7
quantity: 975$q
price: 975$g
replacementprice: 975$v
uri: 975$u
3. Stage a MARC file where the bibs have items attached
4. From acquisitions create a new basket and add 'From a staged file'.
5. Add the staged files to a basket.
6. Make sure the display looks correct.
7. Expand the data by clicking on the checkbox on the left hand side, or by clicking 'Select all'.
8. Make sure the display looks correct.
9. Tab over to 'Item informtion' and make sure that display looks correct.
10. Shrink the screen size down to less that 992px, ensuring the display remains correct.
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates instances in the code and templates where the term
"Authentication providers" is used, replacing it with the preferred
"Identity provider."
Most of the instances of this change are in module or API documentation,
but you can see a couple of the changes in the interface:
- Administration -> Identity providers:
- The sidebar menu should show "Identity providers" instead of
"Authentication providers."
- Patrons -> Patron details -> More -> Set permissions
- Under " Manage Koha system settings (Administration panel)" you
should see "Manage identity providers (manage_identity_providers)"
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In API key management page, anchor closing tag is missing in message "No keys defined for the current patron".
This patch fixes that.
Also changes display with link on a new line.
Translatable text is on purpose surrounded by span or div.
Test plan :
1) Enable system preference RESTOAuth2ClientCredentials
2) Go to a patron page
3) Click More > Manage API Keys
4) Look at page source HTML code
=> Check code is OK
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 27421 replaced the progress bar with job_progress.inc.
The code related to the old progress bar has not been removed however.
Moreover there was a JS error in the console:
"Uncaught ReferenceError: submitBackgroundJob is not defined"
Test plan:
Stage a MARC record for import
Import it
Revert the import
All should work correctly, without JS error in the console and with the
progress bar displayed nicely during the staging step.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Trivial edit.
Remove versions from the name of the packaging manager.
As also commented on BZ:
The script only expects to find a name here, not a version too.
See also maintainer role and how versions are handled there.
In this case I dont think it is really needed to still add that
distinction when we had two packaging managers in the past.
Test plan:
Look again at about.pl, Koha team, Koha development team.
Look at Mason James.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
to test:
1/ install pkg, reboot, note service is not 'active'
2/ add patch, build package
3/ install pkg, reboot, note service is 'active' :)
root@deb11:/etc# systemctl status koha-common
* koha-common.service - Start required services for each Koha instance
Loaded: loaded (/etc/init.d/koha-common; enabled; vendor preset: enabled) <<<<
Active: active (exited) since Thu 2023-06-01 12:45:08 UTC; 13min ago
Tasks: 0 (limit: 2244)
Memory: 0B
CPU: 0
CGroup: /system.slice/koha-common.service
Jun 01 12:45:08 deb11 systemd[1]: Starting Start required services for each Koha instance...
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch corrects the behavior of the 'Confirm' button on the three
possible scenarios regarding item creation.
Ordering:
- 'Confirm' disabled, only gets enabled if quantity > 0
Receiving:
- Quantity gets locked (only changeable when creating items)
- 'Confirm' disabled, only gets enabled if quantity > 0
Cataloguing:
- It now defaults to 1
- 'Confirm' enabled by default (because of 1) if quantity is set to 0,
it gets disabled.
To test:
1. Verify the described behavior with the sample orders for the previous
patch.
=> SUCCESS: It does the job!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On b0aab2aeef the flatpickr default to
'today' was restored, but only for acqcreateitem='ordering'. This patch
moves the initialization to a different stop for broader reach.
To test:
1. Have 3 baskets on with each setting:
- create_item = 'cateloguing'
- create_item = 'ordering'
- create_item = 'receiving'
2. Close those baskets
3. Go to 'Receive shipments'
4. Choose things from the 3 baskets and then 'Receive selected'
5. Navigate through the different orders
=> FAIL: Only the one that has items created on ordering has the date
filled by default
6. Apply this patch
7. Reload the page
8. Repeat 5
=> SUCCESS: Dates are pre-filled!
9. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The original patch makes the form set the right values in the order row
(before storing it) but misses to load the right value on page load,
which is still a regression. This patch solves that.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This restores behavior prior to 8179 to use the estimated cost when receiving if the
actual cost is not set.
We set the unitprice in the table row so that it will be used when editing and will be saved even if not adjusted
To test:
1 - Add some orders to a basket, do not set actual cost field
2 - Close basket, receive orders
3 - Note actual cost field is blank
4 - Cancel receipt
5 - Apply patch
6 - Receive again
7 - Note actual cost is populated
8 - Complete receipt and confirm actual cost correctly saved
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I cannot find any justification for this line existing.
MarkIssueReturned does not do this.
Resetting item's renewal count was introduced in bug 5877 with no explanation.
Test Plan:
1) Check out item 3999900000001 to a patron
2) Upload the KOC file attached to this bug report
3) Navigate the Pending Offline Circ actions, see your return is listed
4) Click the checkbox to select your return
5) Click Process once. Nothing appears to happen
6) In a new tab, pull up the bib for item 3999900000001, see that it has been checked in
7) Back on your Offline Circ tab, click Process a second time
8) Koha tells you the item is not checked out
9) Apply this patch, restart all the things!
10) Repeat steps 1-4, everything should now work!
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit: this line was introduced by bug 30275, by mistake. The
renewals_count attribute belongs to the `issues` table, and I agree it
shouldn't be set to 0 at all as it will (with no reason) make us loose
the value!
Tests pass with and without this change, so this isn't even tested.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the parameter from 'limit' to 'rows'
To test:
1 - Checkout an item to 5 different people
2 - View item details on items tab of record
3 - Note you see last borrower, and three previous borrowers
4 - Apply patch, restart all
5 - Refresh page
6 - You shoulw now only see last borrower and 2 previous borrowers
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Apply patch
2. Go to OPAC self registration and try to manually enter the date for date of birth.
3. You can do so sucessfully
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Resolve:
Can't call method "borrowernumber" on an undefined value at /usr/share/koha/opac/opac-illrequests.pl line 66
Test plan:
Put an unexisting illrequest_id in the URL parameter.
You should see a 404, not a crash.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Same as previous patch, but for 'update' and 'cancreq'.
We remove the redirect, but here we only want to focus on the security
fix.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Confirmed. Without this patch a patron can modify and cancel any ILL
request in the OPAC. With this patch the patron is redirected to the
404 page if modification or cancellation is attempted.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To reproduce:
- Enable the ILL module
- Install the FreeForm backend as described here:
https://wiki.koha-community.org/wiki/ILL_backends
- Go to the ILL module and add two different ILL requests by
clicking on "New ILL request" and entering the necessary details.
- Make sure you connect the two requests to two *different* patrons
in the field marked "Card number, username or surname"
- Make the two titles different, and make a not of which title is
connected to which patron
- Log in as one of the two patrons who now have an ILL request each,
in the OPAC
- Go to the "Interlibrary loan requests" tab
- Click on "View" for the request connected to this patron. The URL
will look like something like this:
http://<opac>/cgi-bin/koha/opac-illrequests.pl?method=view&illrequest_id=2
- Now change the number at the end to correspond to the the ILL request
connected to the *other* patron
- Verify you can see the details of an ILL request conncted to another
patron than the patron you are logged in as
To test:
- Apply the patch
- Restart all the things if you are testing with ktd
- Reload the detail view of the ILL request that belongs to the patron
you are not logged in as
- Verify you are redirect to the 404 page and can not see the details
of the request that belongs to the patron you are not logged in as
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When adding patrons to a patron list we get a JS error about undefined
variables. We can easily fix this problem by defining them even if the
pref is not set.
We are enabling the auto complete even if PatronAutoComplete if off.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If the logged in librarian modifies their own userid they will get the
following error when submitting the form:
Can't call method "password_expired" on an undefined value at /kohadevbox/koha/C4/Auth.pm line 1780
We could handle this situation and flag the session as expired. Better
would be to deal with this specific user case and update the cookie (?)
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes the GET request results more deterministic so we avoid
random failures. It does so by adding a fixed value to each ILL request
and then sorting by it.
To test:
1. Run:
$ DB_IMAGE=mysqli:8.0 ktd up -d
# wait until it finished:
$ ktd --logs
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/ill_requests.t
(repeat a few times)
=> FAIL: It sometimes fails
3. Apply this patch
4. Repeat 2
=> SUCCESS: It doesn't fail
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test Plan:
1) Check out an item
2) Claim return on it, moving it to the old_issues table
3) Delete the old_issue via koha-mysql or Use cleanup_database.pl
4) Attempt to resolve the claim
5) Note the error
6) Apply this patch set
7) Restart all the things!
8) Attempt to resolve the claim
9) No errors!
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
