This patch makes the following methods return array references of
Koha::Library objects instead or unblessed objects;
- Koha::Item->pickup_locations
- Koha::Biblio->pickup_locations
- Koha::Libraries->pickup_locations
Bonus:
- The template plugin is adjusted to unbless things to keep behavior
- Tests are moved to the right .t file.
- Tests for the new behavior are added.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds "patron's hold group" as a new option to Hold pickup library match
To test:
1. Set ReservesControlBranch preference to item.
2. Create a hold group
3. Go to circulation and fines rules
SUCCESS => in 'Hold pickup library match' there is a new option called "patron's hold group"
4. In a library not in hold group set 'Hold policy' to "any" and 'Hold pickup library match' to "patron's hold group"
5. Search for a user in the hold group
6. 'Search to hold' for items of the library of step 4
7. Select an item and 'Place hold for [user]'
SUCCESS => in 'Pickup at' you should see patron's hold group as options
8. In OPAC sign in as the same user of step 5
9. Search for the item in step 7
SUCCESS => in 'Pick up locations' you should see patron's hold group as options
10. Sign off
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a new message to 'Hold' column in 'Place a hold on a specific item' table.
The message is "Cannot place hold from patrons's library". It appears when patron's homebranch is not in item's hold group, and hold_fulfillment_policy is set to 'holdgroup'.
This patch also adds a new column "Allowed pickup locations" that lists allowed pickup locations per item.
Finally, the select that displays pickup locations is filtered by allowed pickup locations, when multi_hold is not enabled
To test:
1) Apply this patch
2) In library groups add a root group and check it as hold group.
3) Add two libraries to the group
4) In circulation and fines rules, in 'Default checkout, hold and return policy', in Hold policy change the value to 'From local hold group'
5) Search a patron from a different library than step 3, select one and click 'search to hold'
6) Search by location for items in any library of step 3
7) On any item, clic on 'Place hold for ...'
SUCCESS => when the page is loaded, in the 'Place a hold on a specific item', you should see the message "Cannot place hold from patrons's library" in 'Hold' column
=> You should see a new column called "Allowed pickup locations" and the message is "Any library"
8) In circulation and fines rules, in 'Default checkout, hold and return policy', in 'Hold policy' change the value again to 'From any library' and change 'Hold pickup library match' to "Item's hold group"
8) Repeat steps 5 to 7
SUCCESS => when the page is loaded, you should see the "Pickup at" select filtered by libraries in hold group
=> You should see in "Allowed pickup locations" a coma separated list of the libraries in item's hold group
=> If biblio has an item whose control branch is not in a hold group, you should see the control branch name in "Allowed pickup locations"
9) Sign off
Sponsored-by: VOKAL
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch actually fixes the issue described on bug 23116.
Test plan:
See bug 23116 and comment 5. Important to note that the later comparison with
itemAlreadyOnHold assumes that the variable is a string.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1. Place some holds
2. Go to the 'Holds' tab of the biblio record
3. Modify dates in the table and click on 'Update holds' button
4. Verify that dates have been correctly updated
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the ability to place a hold for each member of a club in random order.
To test:
1) apply this patch
2) create 2 clubs, (club names should have some part in common, and some part different for each other)
3) in one of them add at least 6 members
4) enter patron clubs management and click on "Actions" button
SUCCESS.1 => club with members has a new action called "search to hold"
5) click on search to hold
SUCCESS.2 => in the list of bilios there appears an action called "Place hold for <club name>"
6) click on "Place hold for <club name>"
SUCCESS.3 => a new window appears where you can select pickup location (defaults to club's library, if any), and the list of members.
7) go back to the list of bilios in the catalog and click on "Forget <club name>"
8) click on "Holds" action of any biblio
SUCCESS.4 => a search box appears with two tabs: Patrons and Clubs
9) click on Clubs tab and search by the common part of clubs names
SUCCESS.5 => a list of clubs that matches the search appears. If you click on any of them, the same page as SUCCESS.3 appears.
10) go back to the search box in SUCCESS.4 and search by the different part of the name.
SUCCESS.6 => because there is only one club that matches search criteria, the same page as SUCCESS.3 appears;
11) Sign off
Sponsored-by: Southeast Kansas Library - SEKLS
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Unify and clean up subtitle usage so that it's always used as a simple array and not the old hash structure.
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch is a bit of a clean-up to bring the item status display
more in line with the display on the detail page:
- show descrpition of authorised value for not for loan instead of hardcoded text
- Show description of authorised value for lost instead of hardcoded text
This is also a translatability fix, as the text came from the .pl
- Show description of authorised value damaged instead of hardcoded text
- Make sequence of status match display on details page:
lost - damaged - not for loan
To test:
- On a record with multiple items
- Add different status to the items
damaged, lost, not for loan
- Make sure you have items with one status and multiple status at the same time
- Look at how the status display on the detail page
- Place a hold, compare display
- Apply patch
- Repeat
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
A library appears to be able to place a second item level hold on an item a patron already has on hold if
A) AllowHoldPolicyOverride is enabled
and
B) the circ rule allow for multple item level holds.
Once the patron submits the hold requests though, the hold does not get stored in the database.
Because allowing two item level holds for the same item makes no sense, we should not allow
this attempt to take place, even if AllowHoldPolicyOverride is enabled.
Test Plan:
1) Enable AllowHoldPolicyOverride
2) Set up circ rules to allow for multiple item level holds on one record
3) Place an item level hold on a record
4) Note you can force placing a second item hold on that reocrd
5) Attempt to do so, it will not actually work
6) Apply this patch
7) Note you can no longer place another item level hold for the same item
you just placed an item-level hold on
8) Note you can still force holds that contravene the circ rules for
any and all other reasons
9) Test with record level holds
10) Test by placing multiple holds from search results
Signed-off-by: Martha Fuerst <mfurest@hmcpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Simple fix for a regression. Works as expected.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Almost everywhere we call IsAvailableForItemLevelRequest we already have
a Koha::Patron and Koha::Item object. It makes sense to use them to
avoid a refetch
Test plan:
It would be good to test this patch on top of 19300 and 19301 and make
sure everything works as expected
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
1) Enable the CheckPrevCheckout and DisplayMultiPlaceHold system preferences
2) Have a patron with some checkouts history
3) Try to place hold on one of titles from history for this patron
4) You should see an information at the top of confirm request page, but
you still should be able to place a hold
5) Try this with multiple titles - one or more of them should be from
history
6) You should see this information in "Information" column
7) There is also new column placed at the beggining with checkbox, you
could uncheck it for titles you do not want to place a hold on it
8) Confirm the hold is placed only on checked titles
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Bin Wen <bin.wen@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Branch transfer limits are respected for placing holds in the OPAC but nowhere else. This should be remedied.
Test Plan:
1) Set up a branch transfer limit from Library A to Library B
2) Verify you cannot set up a hold for an item from Library A for pickup at Library B from the staff interface ( without overriding )
3) Verify you cannot place that hold via ILS-DI
4) Verify you cannot place that hold via SIP
4) Verify a forced hold from Library A to Library B will not show up in the holds queue
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The changes caused by the patches for bug 11512 have broken existing
workflows for many libraries and are widely considered to be a bad move.
We should revert this behavior.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Rhonda Kuiper <kuiper@roundrocktexas.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch disables the dropdown for found holds, and adds a new button
to revert the waiting status, setting the hold to priority 1
Additionally we remove some changes from 19469 and update the JS to skip
found holds when updating priority
To test:
1 - Find a record with multiple items
2 - Place 4 holds (or more)
3 - Capture one ohld as waiting, one as in transit
4 - View the holds on the record - switch the last to priority one
5 - Waiting and transit statuses get confused
6 - Apply patch
7 - Observe dropdown is now disabled for waiting holds
8 - Confirm other holds operate as expected
9 - Confirm 'Revert found status' resets hold
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 21608: (follow-up) Use RevertWaitingStatus and do not alter _FixPriority
[EDIT]
Completely removed the changes to Reserves.pm by adding module prefix in
the request.pl script.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch was generated using codespell
Test plan:
Read through changes and confirm they make sense
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=21706
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds a new collection column to the item table when selecting
a specific item for a hold. The column will only appear if at least
one item has a collection set.
To test, in staff:
- Place a specific hold on
- a record with one or more items with collections
- a record with one or more items without collections
- Verify the collections display correctly when they exist
- Verify the table still works as expected
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The subscriptionsnumber is required in biblio-view-menu.inc to display
the Subscription(s) tab. In detail.pl, if you click any of
Labeled MARC (you need to set the syspref viewLabeledMARC)
Hold(s)
Article requests
Checkout history
Modification log
Rota (you need to set the syspref StockRotation)
you lose the Subscription(s) tab.
This patch fixes the display by having each feature script generate that
value to be passed to the UI. I keep this separated from the first patch
since it's not exactly the same issue, and the solution might not
please.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
It is possible to set up circulation rules to limit trapping of holds by pickup library and itemtype.
To make it easier to understand which holds will be trapped in a given circumstance,
it would be nice if we could optionally group holds by pickup library and/or itemtype.
Test Plan:
1) Apply this patch set
2) Run updatedatabase.pl
3) Enable AllowHoldItemTypeSelection
4) Pick a record and create holds with various pickup libraries and itemtype combinations
5) Enable HoldsSplitQueueNumbering
6) Try the different combinations of HoldsSplitQueue
7) Ensure the hold "arrows" move the items correctly
* Up and down arrows should move hold above or below the adjacent hold within a hold fieldset
* Top and borrom arrows should move hold to the top or bottom within a hold fieldset
Sponsored-by: Stockholm University Library
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Followed test plan, patch worked as described. Also passed QA test tool
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Currently in Koha, if you choose to force a hold from the staff side that would contravened the current issuing rules, that hold will never be filled, as it is always skipped over by CheckReserves.
This patch disallows overrideing except for tooManyReserves which are the only overridden holds that will be trapped.
Test Plan:
1) Apply this patch
2) Attempt to override hold placement, only placements where the patron has too many holds already should be allowed
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We lost the ability to place multiple holds when we are searching for
patrons. The multi_holds parameter is lost and not handled correctly in
the template.
Test plan:
- Make sure you can place multiple holds for a patron you will search for
- Same for simple hold
TODO the multiple holds view should not be displayed if only 1 record
has been selected from the search result.
Signed-off-by: claude brayer <claude.brayer@cea.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch fixes very weird behaviours introduced by
commit 0ab22e1c7c
Bug 18789: Send Koha::Patron object to the templates
The patron variable was only set when no action was defined.
This patch restores the feature the easiest way possible (less changes)
even if it is not the best one.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This subroutine is only used once and can be replaced easily with a
Koha::Biblioitems->search call
Test plan:
Test this on top of bug 19941 and confirm that the correct item types
are displayed
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The GetMemberAccountRecords may be a perf killer, it retrieves all the
account lines of a patron and then the related item and biblio
information.
Most of the time we only want to know how much the patron owns to the
library (sum of amountoutstanding). We already have this information in
Koha::Patron->account->balance.
This patch replaces the occurrences of this subroutine by fetching only
the information we need, either the balance, the detail, or both.
It removes the formatting done in the module, to use the TT plugin
'Price' instead.
There is a very weird and error-prone behavior/feature in
GetMemberAccountBalance (FIXME): as the accountlines.accounttype is a
varchar(5), the value of the authorised value used for the
ManInvInNoissuesCharge pref (category MANUAL_INV) is truncated to the 5
first characters. That could lead to unexpected behaviors.
On the way, this patchset also replace the GetMemberAccountBalance
subroutine, which returns the balance, the non issues charges and the
other charges. We only need to have the balance and the non issues
charges to calcul the third one.
Test plan:
Add several fees for a patron and play with HoldsInNoissuesCharge,
RentalsInNoissuesCharge and ManInvInNoissuesCharge.
The information (biblio and item info, as well as the account line) must
be correctly displayed on the different screens: 'Fines' module, fine
slips, circulation module
Note that this patchset could introduce regression on price formatting,
but will be easy to fix using the TT plugin.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In order to simplify and make uniform the code, the controller scripts send
a Koha::Patron object to the templates instead of all attributes of a patron.
That will make the code much more easier to maintain and will be less
error-prone.
The variable "patron" sent to the templates is supposed to represent the
patron the librarian is editing the detail.
In the members module and some scripts of the circulation module, the
patron's detail are sent one by one to the template. That leads to
frustration from developpers (making sure everything is passed from all
scripts) and to regression (we got tone of bugs in the last year because
of this way to do).
With this patch set it will be easy access patron's detail, passing only
1 variable from the controllers.
Test plan:
Play with the patron and circulation module and make sur the detail of
the patron you are editing/seeing info are correctly displayed.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is already a HidePatronName syspref to hide patron's information
on bibliographic
record detail pages and the hold list.
Test plan:
With the HidePatronName enabled, make sure the patron's information are
hidden from
the catalogue and hold list pages. If the logged in user is not allowed
to see the
patron's info, no link and no cardnumber will be displayed
With he HidePatronName disabled, make sure the patron's information are
displayed
if the logged in user is allowed to see the patron's info.
Technical note:
This patch improves the existing patron-title.inc include file to
display patron's
information. Using it everywhere patron's details are displayed will
permit to
homogenise the way they are displayed. The file takes now a patron
object (what
should be, in the future, the only way to use it), that way we can call
the new
method on it to know if patron's information can be shown by the logged
in used.
NOTE: I am not sure this syspref makes sense anymore. Should not we
remove it?
Signed-off-by: Signed-off-by: Jon McGowan <jon.mcgowan@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patchset move The OPACItemHoldsAllowed logic
(issuingrules.opacitemholds) to a new class method of
Koha::IssuingRules: get_opacitemholds_policy
On the way, this patch will certainly fix the same problem as bug
19298 with onshelfholds.
Test plan:
Make sure the opacitemholds policy is correct when placing a hold at the
OPAC or the staff interface.
Followed test plan which worked as described
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1) Enable AllowHoldPolicyOverride
2) Enable AllowHoldItemTypeSelection
3) Create a situation where adding a hold for a patron would trigger a tooManyReserves
warning.
4) Note the itemtype pulldown is empty
5) Apply this patch
6) Reload the page
7) Itemtype pulldown should have values
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug caused by
commit bc39f0392b
Bug 14695 - Add ability to place multiple item holds on a given record per patron
Test Plan:
1) Set AllowHoldsOnPatronsPossessions to "Don't"
2) Check out an item to a patron
3) Place a hold on that item for the same patron
4) Note you are allowed to with no alert
5) Delete the hold
6) Apply this patch
7) Place a hold on that item for the same patron
8) Note you recieve an alert now
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a new Koha::Hold->cancel method and replaces the calls
to C4::Reserves::CancelReserve with it.
Test plan:
- Add and cancel holds
- Change priority of holds
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This subroutine is only used once and can easily be replaced with
Koha::Patron->holds->count
Test plan:
- Set maxreserves=5
- Place 3 holds for a given patron
- Place again 3 holds for this patron
3+3 > 5 => The holds must not be placed
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Most of the time C4::Biblio::GetBiblioData is used to retrieve the title
and/or the author of a bibliographic record.
This patch replaces the easy occurrences of GetBiblioData, the ones
where the 2 joins are needed, but only data from biblio and biblioitems
table are.
Test plan:
It will be hard to test everything, I'd suggest a QAer to review this
patch and confirm that the difference occurrences of GetBiblioData have
been correctly replaced by calling Koha::Biblios->find or
$biblio->bibioitem
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This script is really ugly and need to be rewritten completely to
separate the different action.
$patron is not always defined, we need to take it into account.
Note that this patch is mainly indentation changes.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GetMember returned a patron given a borrowernumber, cardnumber or
userid.
All of these 3 attributes are defined as a unique key at the DB level
and so we can use Koha::Patrons->find to replace this subroutine.
Additionaly GetMember set category_type and description.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
C4::Circulation::GetItemIssue returned all the issue and item
informations for a given issue. Moveover it also did some date
manipulations. Most of the time this subroutine was called, there
additional information were useless as the caller usually just needed
the basic issue's infos 'from the issue table).
This first patch updates the simple calls, ie. the ones that just need
the issue's infomations.
Test plan:
The following operations should success:
- transfer a book
- create a rule for on-site checkouts and confirm that a patron cannot
check more items out that it's defined in the rule.
- Renew an issue using ILSDI
- Using SIP confirm that you are able to see your issues
Followed test plan, works as expected
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
"$itemnumbers_of_biblioitem" is declared but not used at line 314,
column 5. Unused variables clutter code and make it harder to read.
(Severity: 3)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
At this point this subroutine is only used once, from reserve/request.pl.
Since we already have the items, it's easy to populate the different
hashes as the rest of the code is expecting it.
Test plan:
You need to create analytical record relationships (
EasyAnalyticalRecords needs to be set). Link an item to a biblio using
the 'Edit > Link to host item' menu from the biblio detail page.
From the staff interface place a hold on the biblio. You should see the
items from the biblio and the one you just linked
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
The code from scripts and subroutines using this subroutine was not very
elegant. Most of the time the code was unnecessarily complex.
This patch removes this subroutine and adapt the code to use
Koha::Items instead.
1. C4::Items::get_hostitemnumbers_of
I did not understand why the code was so complicated, it seems that we
only want to know if a given item has a given biblionumber
2. cataloguing/merge.pl
We want to retrieve the itemnumber for a given biblio.
We could also have done that with:
Koha::Biblios->find( $biblionumber )->items;
3. labels/label-item-search.pl
We want to loop over the items for a given biblio, no need to use
get_itemnumbers_of and GetItemInfosOf.
We just need to use:
Koha::Items->search({ biblionumber => $biblionumber })
4. reserve/request.pl
We want to retrieve the itemnumbers of the biblio's items
We could also have done that with:
Koha::Biblios->find( $biblionumber )->items->get_column('itemnumber');
Test plan:
1.You need to create analytical record relationships (
EasyAnalyticalRecords needs to be set). Link an item to a biblio using
the 'Edit > Link to host item' menu from the biblio detail page.
From the staff interface place a hold on the biblio. You should see the
items from the biblio and the one you just linked
2. Merge two bibliographic records (with items), the resulting record
should contain items from both original records
3. Create a new label batch, edit it.
Add items to this batch ('Add items' button).
Fill the input with a barcode.
You should see all the items of a biblio.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: sonia BOUIS <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Updating to use they/them and skipping the ones changed to it
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comments throughout the Koha codebase assume that
all librarians or borrowers are male by using the
pronoun 'he' universally. This patch changes to
'he or she' / 'him or hers'.
Testing plan:
- ensuring modifying tests still pass:
+ C4/SIP/t/06patron_enable.t
+ t/db_dependent/Circulation.t
+ t/db_dependent/Koha/Patrons.t
+ t/db_dependent/Reserves.t
Sponsored-By: California College of the Arts
No code changes detected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
On the same way of Koha::Biblio->get_holds,
Koha::Biblio->get_holds_placed_before_today and Koha::Patron->get_holds,
this new subroutin will permit to retrieve the holds placed on a
specific item.
Note that at the moment we do not need a Koha::Item->get_holds method:
we do not want to display future holds placed in the future.
Test plan:
I would suggest to test this patch with patches from bug 17736 and bug 17738,
to place different kind of holds (biblio and item level, future and
past).
Then do a whole workflow to detect bug, view a record, delete record,
order, place a hold on an item which has been ordered, etc.
The hold's informations should always be the same without or without
these patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch is more a bugfix than a refactoring.
Indeed the C4::Koha::get_notforloan_label_of behaviors were buggy:
1/ It does not display the opac description at the OPAC, but always the
staff description
2/ It does not care of the framework of the biblio, but retrieve the
first row of the marc_subfield_structure mapped with items.notforloan
These 2 bugs can easily be fixed using the
Koha::AuthorisedValues->search_by_koha_field
Steps to recreate the issues:
- Create 2 authorised value categories for not for loan (NFL1 and NFL2)
with the same values. Define a different description for the OPAC.
- Define link 952$7 to NFL1 for the default framework and to NFL2 for
the BK framework
- Create 2 bibliographic records (B1 using NFL1 and B2 using NFL2) with
2 items each (1 item should have a not for loan value)
- Go to the "Place a hold" view for this record.
- In the item list, you should see the not for loan value
=> The staff description of NFL1 will always be used, even for the OPAC
Test plan:
- Recreate the issues without this patchset
- Apply this patchset
- Recreate the steps to recreate the issues
=> The staff description of NFL2 should be displayed for the B2 item
=> The opac description of NFL2 should be displayed for the B2 item at
the OPAC
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
