If more that 1 tax rate exist, 1 total ligne should be display in the
footer.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Previous patch does modify the code for cancelled orders.
Test plan:
Cancel 1+ orders and verify the prices are correct (i.e. the same as
the non-cancelled orders) and that the prices are formated.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The total values should be formated too.
Test plan:
1/ Go on the basket page
2/ Using the CurrencyFormat, verify the totals are correctly formated.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12969 introduces a subroutine to centralize VAT and prices
calculation.
It should be use in the acqui/basket.pl script.
Test plan:
0/ Don't apply the patch
1/ Create 4 suppliers with the different configurations
2/ Create a basket and create several orders
3/ Go on the basket page
4/ Apply the patch
5/ Verify you don't see any difference before and after applying the
patch
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When responding to ListRecords and ListIdentifiers verbs, OAI server doesn't
return proper resumption token. At the end of a result set, OAI server
generates a resumption token even if there isn't anymore records. Consequently,
OAI harverster will send a new request, based on this invalid resumption,
token. OAI Server responds with an empty resultset, which is considered as an
invalid response by most of the harvesters.
TO TEST:
- Find in your DB, a day where a few biblio records have been created. The
number of created biblios must inferior to OAI-PMH:MaxCount.
- Let say this day is 2014-01-09. Send an OAI-PMH request to Koha OAI Server:
/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=marcxml&from=2014-01-09&until=2014-01-09
- At the end of the result, you will see a resumption token which looks like that:
<resumptionToken cursor="47">marcxml/47/2014-01-09/2014-01-09/</resumptionToken>
This is wrong. No resumptiion token should be sent since there isn't anymore
records to harvest.
- Apply the patch.
- Resend the OAI-PMH request. There is no resumption token at the end of the
result.
- You could test also with ListIdenfiers verb in place of ListRecord.
Signed-off-by: Christophe Brocquet <christophe.brocquet@obspm.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To test:
- Make sure your database is pre 3.19.00.010 (for example by loading in
an older backup)
- Run through the web-based database update (web installer, step 3)
- Verify that updates 3.19.00.010 and 3.19.00.011 are squashed
together on one line
- Apply the patch
- Reset the database and run the web-based database upgrade again
- Verify that the two uupdates are noe displayed on separate lines
(as separate bullet points)
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Previous comments were wrong.
Actually the main part of price values is correct.
Only some rounding and tax values are badly calculated.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If more that 1 tax rate exist, 1 total ligne should be display in the
footer.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12969 introduces a subroutine to centralize VAT and prices
calculation.
It should be use in the acqui/invoice.pl script.
Test plan:
0/ Don't apply the patch
1/ Create 4 suppliers with the different configurations
2/ Create a basket and create several orders
3/ Receive the items and create an invoice
4/ Go on the invoice page acqui/invoice.pl?invoiceid=XXX
5/ Verify you don't see any difference before and after applying the
patch on the invoice details table.
Note: The only different you should see is the price formating for
"Total tax exc.". Before this patch "432.10" was displayed "432.1".
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch makes a follow-up change and takes as its basis a dependency
on Bug 13218 - usability enhancement for z39.50 search. If we have a
one-column search form it's possible to put the "Clear search form" link
at the bottom of the form rather than in the header, logically
associating it with the grouping of form fields which will be affected.
Doing so also allows us to eliminate all the custom styling which was an
issue for QA.
Other changes made by this patch: Fixing the indentation
error, correcting the case of the link text ("Clear search form" instead
of "Clear Search Form"), and adding "preventDefault()" to the click
handler so that clicking the link doesn't scroll the user back to the
top of the page.
To test, apply the previous patch and this one on top of Bug 13218.
Repeat the test plan.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Tested in:
/koha/cataloguing/z3950_auth_search.pl
(Home:Authorities:New from Z39.50)
/koha/cataloguing/z3950_search.pl
(Home:Cataloging:New from Z39.50/SRU)
/koha/acqui/z3950_search.pl
(Home:Acquisitions:[Bookshop]:[Basket]:Order from external source)
All three forms can now be cleared.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It appears that an empty string is sneaking into the list of words
to highlight and that is causing the browser to freak out.
Test Plan:
1) Enable NoveList
2) Enable OpacHighlightedItems
3) Search a title with a series (i.e. The Hunger Games)
4) Click into the record
5) Click on the series to search it
6) Click on a title in the search results
7) If Firefox doesn't crash, it gives the unresponsive script message
8) Apply this patch
9) Repeat steps 3-6
10) Browser doesn't freak our
Signed-off-by: Jason Robb <jrobb@sekls.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
could not confirm the problem, but small change and
highlighting terms on result list and couldn't find any
regressions in highlighting.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since translator rebuild HTML tags with double quotes for attributes
values, use double quotes in english template too and escape them with
backslash.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
It works well!!
Test:
1) Intall translation (de-DE, es-ES)
2) to Go to item search, in english, do a search that gives results
3) Switch language, repeat search, result's table does not render
4) Apply patch
5) Install translation again
6) Repeat 3, now results are displayed
No koha-qa errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12844 removed the call to C4::Budgets::GetCurrency.
The use of this module can be completely removed from C4::Output.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It makes sense and no runtime errors found.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
The hbyymmincr autoBarcode builder looks up all barcodes that begin with
any number of letters ( the branchcode ) and a two-digit year directly
afterward ( e.g. MPL15 ), then grabs the last four digits as the
increment counter. The problem is, this does not take months into
account, so unlike the description that says the system is limited to
10,000 items a month, it is limited to 10,000 items per *year*.
This situation can easily be corrected my adding the month into the
lookup ( e.g. MPL1501 ).
Test Plan:
1) Enable autoBarcode, set to hbyymmincr
2) Catalog an item, let the barcode.pl plugin generate
the next barcode.
3) Catalog an item with the barcode MPL15009999
4) Catalog another item, use the barcode.pl plugin to
generate the next barcode.
5) Note the barcode is generated ends with '0001' instead of the
correct increment
6) Apply this patch
7) Repeat step 4
8) Note the barcode now ends with the correct increment
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jeanne Heicher <nppublib@pa.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Problem confirmed - the continuing number bit was not reset
to start counting from 1 again on the beginning of a new month.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Without this patch
perl -wc C4/VirtualShelves.pm
failed:
Constant subroutine C4::VirtualShelves::SHELVES_MASTHEAD_MAX redefined
at /usr/share/perl/5.20/constant.pm line 156.
Constant subroutine C4::VirtualShelves::SHELVES_COMBO_MAX redefined at
/usr/share/perl/5.20/constant.pm line 156.
Constant subroutine C4::VirtualShelves::SHELVES_MGRPAGE_MAX redefined at
/usr/share/perl/5.20/constant.pm line 156.
Constant subroutine C4::VirtualShelves::SHELVES_POPUP_MAX redefined at
/usr/share/perl/5.20/constant.pm line 156.
Constant subroutine C4::VirtualShelves::SHARE_INVITATION_EXPIRY_DAYS
redefined at /usr/share/perl/5.20/constant.pm line 156.
Subroutine GetShelves redefined at C4/VirtualShelves.pm line 103.
Subroutine GetAllShelves redefined at C4/VirtualShelves.pm line 159.
Subroutine GetSomeShelfNames redefined at C4/VirtualShelves.pm line 189.
Subroutine GetShelf redefined at C4/VirtualShelves.pm line 230.
Subroutine GetShelfContents redefined at C4/VirtualShelves.pm line 262.
Subroutine AddShelf redefined at C4/VirtualShelves.pm line 315.
Subroutine AddToShelf redefined at C4/VirtualShelves.pm line 353.
Subroutine ModShelf redefined at C4/VirtualShelves.pm line 394.
Subroutine ShelfPossibleAction redefined at C4/VirtualShelves.pm line
454.
Subroutine DelFromShelf redefined at C4/VirtualShelves.pm line 545.
Subroutine DelShelf redefined at C4/VirtualShelves.pm line 589.
Subroutine GetBibliosShelves redefined at C4/VirtualShelves.pm line 603.
Subroutine ShelvesMax redefined at C4/VirtualShelves.pm line 628.
Subroutine HandleDelBorrower redefined at C4/VirtualShelves.pm line 648.
Subroutine AddShare redefined at C4/VirtualShelves.pm line 683.
Subroutine AcceptShare redefined at C4/VirtualShelves.pm line 703.
Subroutine IsSharedList redefined at C4/VirtualShelves.pm line 731.
Subroutine RemoveShare redefined at C4/VirtualShelves.pm line 750.
Subroutine _shelf_count redefined at C4/VirtualShelves.pm line 764.
Subroutine _CheckShelfName redefined at C4/VirtualShelves.pm line 788.
C4/VirtualShelves.pm syntax OK
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It's preferable to limit the permission to delete shelves.
Apply both patches before testing, then follow this test plan
Currently a public list can only be deleted by its owner.
This means lists can exist infinitely.
This will introduce a new permission for list. With this permission, a
staff member will be allow to delete any public lists.
Test plan:
1/ Add the manage_shelves permission to a patron.
2/ Login with this patron
3/ Go on the public list view
4/ You should be able to delete all public lists
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Currently a public list can only be deleted by its owner.
This means lists can exist infinitely.
This will introduce a new permission for list. With this permission, a
staff member will be allow to delete any public lists.
Test plan:
1/ Add the manage_shelves permission to a patron.
2/ Login with this patron
3/ Go on the public list view
4/ You should be able to edit all public lists
Followed test plan. Works as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Labeling a phone number field "mobile phone" eliminates the usefulness
of having the labels "primary" and "secondary." Generic labels let the
user populate the fields according to their importance rather than their
type.
To test I recommend editing a patron record so that the values in the
patron record contain a label matching the table column:
borrowers.phone : 555-555-1234 (primary - phone)
borrowers.phonepro : 555-555-5678 (secondary - phonepro)
borrowers.mobile : 555-555-9012 (other - mobile)
View this patron's information in the various affected templates and
verify that the labels correctly match the data:
- OPAC "your personal details" (opac-memberentry.pl)
- Submit changes to primary, secondary, and other phone via the OPAC.
In the staff client, view the confirmation for those changes.
- Patron details in the staff client (moremember.pl)
- Patron entry/edit in the staff client (memberentrygen.pl)
- Patron duplicate confirmation in the staff client
(you can navigate directly to
/members/moremember.pl?borrowernumber=XXXX&print=brief)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds POD to the new /svc/barcode service, and also implements some
error handling.
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If we add a script to Koha that can be passed a barcode, we will be able
to easily embed item and patron barcodes into html printable slips and
notices. This can be very helpful for librarians, as it means scanning
an image instead of typing in the barcode manually.
This patch adds a barcode image generator that can be passed a barcode
and an optional type ( defaults to Code39, all GD::Barcode types should
work ). This image can be embedded in html slips and notices.
( e.g. <img src="/cgi-bin/koha/svc/barcode?barcode=<<items.barcode>>"></img> )
Test Plan:
1) Apply this patch
2) Browse to /cgi-bin/koha/svc/barcode?barcode=123456789 on your server
3) Note the barcode image
Signed-off-by: Brandon <brandon_h27@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The browse by last name letters on the patron search for the patron card
creator doesn't work quite right. If extended patron attributes are
disabled, it works fine, but if they are enabled, they are searched even
when using the browse last name. Thus, if a searchable attribute has a
"D" in it, and one clicks the "D" link for the last name browser, that
patron will show even if he or she has no "D" in his or her hame!
Test Plan:
1) Enable extended patron attributes
2) Add a new searchable patron attribute
3) Create a new patron with the last name "Ace"
4) Add the value "D" to the attribute for this patron
5) Browse to the patron card maker, start a new patron batch
6) Click "Add item(s)" to bring up the patron search
7) Click the letter "D" in the patron search box
8) Note that "Ace" shows in the results list
9) Apply this patch
10) Repeat step 7
11) Note that "Ace" no longer shows in the results list
12) Perform a regular search by putting the letter "D" in the "Name:"
field, and hit the "Search" button
13) Note this time the results *do* have Ace in them
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Well described for a tricky bug. Reproducible. Fixed with this patch.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
This works as described, no problems or regressions found.
When a basket/shelf is downloaded, items are embedded, but not when
sending it by email.
We would expect to get the same file.
Test plan:
On Opac and intranet:
1/ Add records with items to your basket and send it by email.
Verify the file contains items.
2/ Add records with items to a list and send it by email.
Verify the file contains items.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
By returning the object itself instead of a boolean, we can chain
methods together while retaining the exact same functionality.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since new_from_dbic is not meant as a public method, this patch adds
a prefix to the name of this internal routine. For the same reason I
removed it from t/Borrower.t.
Removed one use overload-line in Objects (not used).
Resolved a few typos.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch also adds 1 test.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The idea behind this is to have a pair of base classes on which to build
our new generation of Koha objects. Koha::Object is a base class, which
in it's most basic form, is to represent a row in a table. For example,
Koha::Borrower inherits from Koha::Object. So too could Koha::Biblio
and Koha::Item for example.
Koha::Objects is to represent a way to fetch and manipulate sets of
objects. For example, Koha::Borrowers has a method to get a
Koha::Borrower object by id and a method to search for an get a list
of Koha::Borrower objects. Right now Koha::Objects has only the
essentials but can easily be extended and those enhancements will be
passed down to all the child classes based on it.
By using these classes as a base, we will add consistency to our
code, allow us to keep our code DRY, reduce bugs, and encapsulate our
database access among other benefits.
Test Plan:
1) Apply this patch
2) prove t/Object.t t/db_dependent/Object.t t/db_dependent/Objects.t
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
No matter what the selection of OPACShowHoldQueueDetails is, if it is
enabled it displays a line "Holds and priority:" even if you've opted to
hide one of those!
Test Plan:
1) Apply this patch
2) Test each setting of OPACShowHoldQueueDetails
3) Ensure each setting displays the correct fields ( or lack thereof )
Signed-off-by: Christopher Brannon <cbrannon@debian.localdomain>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Imagine this scenario: we have one record with four items. Two of those
items are checked out, one of those items is a waiting hold, and one of
those items is available. We would expect to see this on the search
results page. Instead, we will see both non-checked out items as
unavailable due to waiting holds.
This is due to a semantic issue GetReserveStatus.
C4::Search::searchResults uses GetReserveStatus to get the reserve
status of each item, but unlike all other calls to the sub, this one
passes in not only itemnumber, but biblionumber.
When no reserve is found for the available item, the subroutine uses the
biblionumber to grab what is essentially an arbitrary reserve to use for
the status. This makes no sense and this functionality should be
entirely removed from the subroutine so regressions like this will be
prevented in the future.
Test Plan:
1) Create one record with 4 items
a) check two of the items out to patrons
b) set one of the items as a waiting hold
c) leave the fourth item as available
2) Run a search where this record will be in the results list
3) Note that the results list 2 items on loan, two unavailable
4) Apply this patch, reload the search results
5) Note that the results list 1 available, 2 on loan, 1 unavailable
Signed-off-by: John Andrews <jandrews@washoecounty.us>
Signed-off-by: Sheila Kearns <sheila.kearns@state.vt.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Note: This is for the staff search result list!
Works as expected.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
1) Removed 'use C4::Context;' because it can lead to introduction
of circular reference in the near future
2) Put fastmmap initialization code into an eval {} block, to catch
various kinds of errors which can still occur during it's init in
some [less usual] Koha setups and/or more unusual circumstances
3) Do not include UID in the sharefile name (it will be constructed
using namespace + database name + database host instead).
Test plan addendum:
s/and UID//
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Koha::Cache package does not take into account that, when using
fastmmap caching variant, mmaped cache file created in /tmp
(typically: /tmp/sharefile-koha-koha), would only be further
accessible to the one given OS user - the one which created it.
In many Koha setups, in the circumstances when various system scripts
are executed by 2+ users with diffrent UIDs (like multi-tenant servers,
for example) this may cause many kinds of issues. Observable symptom
is usually the appearance of the below error when searching, or looking
at MARC Framework pages and a few other places:
Open of share file /tmp/sharefile-koha-koha failed: Permission denied
at /usr/lib/perl5/Cache/FastMmap.pm line 640.
This patch:
- disables initialisation of fastmmap caching subsystem unless it is
explicitly requested by the user (CACHING_SYSTEM=fastmmap)
- disables fastmmap cache usage for command line scripts
(i.e. when GATEWAY_INTERFACE environment variable is not defined)
- adds the database name, host name and an ID of the OS user to the
mmaped file name created in /tmp, to prevent various kinds of
unintentional conflicts and/or permission problems from happening
To test:
1) remove the /tmp/sharefile-koha-* file[s] (if any)
2) do something which would lead to its re-creation (e.g., performing
any search in OPAC should be sufficient to cause that)
3) observe that /tmp/sharefile-koha-koha got created
4) remove it
5) apply patch
6) redo step 2)
7) observe that aforementioned file is no longer created in /tmp
8) set CACHING_SYSTEM environment variable to 'fastmmap'
9) redo step 2), observe that /tmp/sharefile-koha-* file got created
and that it's name now contains hostname, database name and UID
10) ensure that everything still works like it should and that there
are no regressions of any kinds anywhere in the system ;)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
my $bar;
my $foo = $bar->{borrowernumber} ||= {};
$foo->{one} ||= 'something';
$foo->{two}++;
What does $bar contain?
$VAR1 = {
'borrowernumber' => {
'two' => 1,
'bar' => 'something'
}
};
Not really obvious.
Maybe something I did not see is hidden.
Test plan:
Verify the digest for DUE and PREDUE work as before.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If a link to a patron record ends with #reserves, the holds tab is selected
on page load, but the holds table does not load.
Test Plan:
1) Build your holds queue
2) From the holds queue report, open any patron link
3) Note the patron's reserves do not load
4) Apply this patch
5) Clear your browser cache
6) Repeat step 2
7) Note the holds table now loads
Signed-off-by: Sean McGarvey <seanm@pascolibraries.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The tests highligh the problem: if the parent_ordernumber attribute is
not set on inserting an order, the object returned by the method does
not contain the value (undef).
Test plan:
Verify the tests are consistent and
prove t/db_dependent/Acquisition/CancelReceipt.t
should return green.
You can also verify that receive partially an order and cancel the
receipt work as expected.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The acquisitions search is exhibiting the same behavior as bug 11410.
Results are always fixed in order of biblionumber, among other possible
issues ( including the ampersand issue ).
Test Plan:
1) From an open basket, choose "Add to basket"
2) Run a search for "From an existing record"
3) Note the "View MARC" URLs are fixed in order of biblionumber
4) Apply this patch
5) Refresh the page
6) Note the results are no longer fixed in order of biblionumber
Signed-off-by: David Cook <dcook@prosentient.com.au>
Works as described.
I think the code could be a bit tidier, but I think it makes sense to
use buildQuery here. It'll detect CCL, CQL, and PQF queries, as well
as parsing a regular keyword search as one would expect when searching
the catalogue.
It also has the added bonus of performing relevance searching,
so long as QueryAutoTruncation is off, and so long as library staff
avoid using the "*" truncation wildcard (see bug 12430).
While there are simpler ways to fix this acq bug, I think this was
probably the best move, as it adds a bit to the consistency of what
librarians can expect from their search results.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Same result with and without the patch but I agree with the changes.
BuildQuery should be called before SimpleSearch if QP is not used.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
C4::Acquisition::ModReceiveOrder updates the aqorders with
budget_id=NULL if no budget_id given in parameter.
Actually the same budget_id should be used.
In tests (especially t/db_dependent/Acquisition/TransferOrder.t),
ModReceiveOrder is not called with a budget_id param and set to NULL the
budget_id value.
test plan:
prove t/db_dependent/Acquisition/TransferOrder.t
should return green
Note that this bug should not appear using the interface.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The fix makes sense, and running
$ prove t/db_dependent/Acq*
returns all green. koha-qa.pl also likes it.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Booksellers.t and Koha_template_plugin_Branches.t both had
function calls to ::set_userenv added to them. This patch handles
those additions.
TEST PLAN
---------
1) Branch a new git branch
2) prove -v t/db_dependent/Bookseller.t
-- It should work.
3) prove -v t/db_dependent/Koha_template_plugin_Branches.t
-- It should work.
4) Apply only the first patch.
5) Repeat steps 2 and 3.
-- They should both FAIL!
6) Apply the second patch as well.
7) Repeat steps 2 and 3.
-- The should both work.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
There were multiple calling conventions for C4::Context's
set_userenv routine. So the following commands were used to
find discrepancies:
grep "::set_userenv" `find .`
grep "\->set_userenv" `find .`
The first grep demonstrated that the smaller change is from
:: to -> as only C4/Auth.pm, installer/InstallAuth.pm, and
t/db_dependent/Circulation.t would need to be modified. This
patch corrects C4::Context's set_userenv routine to be object
call based (use ->) by using a shift to ignore the first
parameter, and modify the three files found with :: calls.
As the result of trying to roll a distribution,
t/Circulation_barcodedecode.t was discovered to be faulty. The
cause being incorrect parameters! This was hidden when there
was no shift in the set_userenv routine. However, with its
correction, the test broke.
This led me to read the POD documentation for the function
set_userenv in C4::Context and realize it was outdated as
well. It has been revised to match the current version of
the function.
Then intentionally bad parameters passed to the set_userenv
routine in C4::Context were hunted down. The biggest problems
were missing surnames or branch names.
Rebase required because of shibboleth change in C4/Context.pm
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Test plan:
1: Go to your patron
2: Go to change username and/or password.
3: Change password to something with spaces in the middle. Notice it is invalid.
4: Apply this patch.
5: Change password again using spaces in the middle. Notice it is accepted.
6: Change password with leading and/or trailing spaces, notice they are not accepted.
Applied bothe patches. Followed test plan. Patch behaves as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
