Before patch you will see in acqui/booksellers.pl all the baskets ever
created.
After the patch you will see in acqui/booksellers.pl only the basket
with expected items.
Test plan :
* Create a basket with some orders lines
You should see this basket in acqui/booksellers.pl
* receive or cancel all the line in this basket
This basket shouldn't appear any more in acqui/booksellers.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Simply revert order of 2 lines in Items.pm. Previous line write to
variable used in next line as function argument.
To Test:
Give an item a special restricted value, define one if you have to
in the authorised values.
Observe that, without this patch, statuses are not shown in the
OPAC in parentheses. My example was an item that had a restricted
value of "Library Staff Only"
It should have been shown under status on the detail page of the
OPAC, but was not.
Apply the patch, observe that restricted values are now shown
for your item, for example:
Available (Library Staff Only) in the status column.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and test plan.
Simple change fixing a display problem, no string changes.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Moving the warn line below the line that returns if amount<=0.
If amount<=0, a false warn is now raised because of the return after it.
We should only warn here if we do not return.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested with fines.pl on overdue.
Before this patch:
Reducing fine for item 199709 borrower 23 from 44 to -1 - MaxFine reached.
This did not happen however because of the return.
After this change: no false warning.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
If a patron has over time accumulated fines greater than the amount
defined in MaxFine, the patron will never get more fines even if they
have previously paid off those fines.
This bug was introduced by the patch for Bug 7420.
Test Plan:
1) Create a patron
2) Create a fine of 10.00 for that patron
3) Pay off the fine
4) Set MaxFines to 5.00
5) Check out an item to the patron, backdate the due date
so the item should generate fines.
6) Run fines.pl, observe that no fine was created
7) Apply the patch
8) Rerun fines.pl
9) Observe that the fine was created correctly
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test Plan:
1) Enable IndependantBranches
2) Set HomeOrHoldingBranch to holding branch
3) Delete an item whose holding branch is your logged in branch, and
whose home branch is not
4) Apply this patch
5) Repeat step 3, it should fail
6) Try to delete another items whose home branch is your logged in
branch, and whose holding branch is a different branch. This
deletetion should succeed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Change is logical, only homebranch should determine if the item
can be deleted.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch restores the line exporting GetOrderNumber that I accidentally suppressed.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Restores a line that was deleted by the first patch.
Was not sure if patches should be squashed.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Revised patch according to QA comments. No more dependent from bz 9780.
At present, merging records breaks the link order/record, except
if an item of the deleted record is used in the order.
This is a serious issue for libraries creating items on receipt.
This patch moves existing orders from deleted record to destination record.
It creates a new function Acquisitions::GetOrdersByBiblionumber,
that could be used by other patches later.
To test :
Check the problem :
1. Set syspref AcqCreateItem = Create an item when receiving an order
1. Create a basket with one order
2. Put the record used by this order in a list
3. Put an other record in the list
4. Merge the 2 records, keeping as a reference the record NOT used in the order
5. In the order, you will see for that order "Deleted bibliographic information..."
6. Apply the patch
7. Repeat steps 1-4
8. In the order, you will see the title/author of the kept record.
9. Set syspref AcqCreateItem = Create an item when placing an order
10. Repeat steps 1-4 (an item will be created)
11. In the oreder, you will see the title/author of the kept record
(it is already the case at present. the patch should not alter this behavior)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Test plan, test suite and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The original implementation of QueryParser did not handle truncation
based on the QueryAutoTruncate system preference. This patch adds support.
To test:
1) Apply patch.
2) Turn on UseQueryParser.
3) Set QueryAutoTruncate to "automatically."
4) Search for "har". Note that it returns results with words
like "Harry" (i.e. with right truncation).
5) Search for "har*". Note that it still returns results with right
truncation.
6) Set QueryAutoTruncate to "only when * is added."
7) Search for "har". Note that it returns only records that have the
exact word "har" in them (most likely there will be none unless you
have Hebrew items).
8) Search for "har*". Note that once again it returns results for "Harry"
(i.e. right truncated results).
9) Sign off.
This patch also reindents a hash in Koha/QueryParser/Driver/PQF.pm
because it was hard to read before.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Thx for fixing this Jared!
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Making sure that the regex does not kill more than it should.
Amended: does now only look at separating colons(;) not commas(,).
Amended: two index expressions in direct context replaced by same regex for
consistency.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
When manual history is disabled in subscription history section
if a serial has been previously set as missing and is received
or set as expected, late or claimed, it will be deleted from missinglist
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Regex needs a followup. More comments on Bugzilla.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
I just add use utf8; to the Search.pm and the problem
was solved .
Test plan :
1- Add bib records with non-latin characters
2- search for some of these records
3- try to refine your search using Subject / Author
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work fixing URLs in facets. Now they work correctly.
No errors.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
I tested facets with the 22 Arabic records provided on
bug 9579 successfully. Before the patch the links are not
correct, after applying the patch the links work as
expected.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Remedied by:
- in Circulation.pm changing AnonymiseIssueHistory so that it returns ($rows, $err_history_not_deleted) instead of $rows
- consequential change to misc/cronjobs/batch_anonymise.pl to handle updated return value, and fail if there is an error
- consequential change to tools/cleanborrowers.pl although this still fails silently (raised as bug 9944)
- update of opac-privacy.pl to check return value and pass on error
- update of opac-privacy.tt to display error if appropriate
Note bug 9942 remains unfixed, which is a similar issue upon issue return.
To test:
1. OPAC
- enable privacy mode (preference OpacPrivacy)
- leave anonymous patron set to zero (preference AnonymousPatron)
- attempt to delete user history
- observe error
- check history - still there
- change anonymous patron to a valid user
- attempt to delete user history
- observe success message
- check history - gone
2. cleanborrowers.pl
- test it functions as before. bug 9944 has been raised for it continuing to silently fail.
3. batch_anonymise.pl
- enable privacy mode (preference OpacPrivacy)
- leave anonymous patron set to zero (preference AnonymousPatron)
- run script (I use --days -1 for testing)
- script should fail with a Carp message
- change anonymous patron to a valid user
- run script as before
- script returns quietly
- check history - gone
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The SQL query build in C4::Items::_koha_modify_item performs an update on a row of items table identified by itemnumber.
Actually the query is build using a hash of datas :
for my $key ( keys %$item ) {
$query.="$key=?,";
push @bind, $item->{$key};
}
But this hash contains 'itemnumber' key, so you get an update including the primary key.
It is actually harmless but may be dangerous.
This patch simply skips itemnumber key in above loop.
Test plan :
Check you can create and modify items.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This bug was reintroduced by the patch for bu 5911: Transport Cost Matrix
Test Plan:
1) Place a hold on a record
2) Run build_holds_queue.pl
3) Verify the hold is showing in the holds queue
4) Suspend the hold
5) Re-run build_holds_queue.pl
6) Note the hold is still in the holds queue
7) Apply patch
8) Re-run build_holds_queue.pl
9) Note the hold is no longer in the holds queue
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes test plan and QA script.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch replaces an earlier patch by Marcel de Rooy, which
had become outdated because lots of new dependencies were
added since the patch was made.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Bug 9902 introduced an issue in the C4::Items::PrepareItemrecordDisplay
routine. The existence of $defaulvalue hashref should be tested before
getting to the branchcode key.
Test plan:
Before applying the patch, an error occurred when you try to create an
order from a staged file.
After applying the patch, the error does not appear anymore.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Adding a FIXE at a line that uses $sth->{NAME} for possible utf8 problems.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Adds a comment, no danger from that.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch makes ParseLetter somewhat more restrictive in removing
punctuation characters from the end of a table field.
Based on the assumption that we want to remove punctuation from fields in
biblio and biblioitems (like ISBD).
ParseLetter should not remove e.g. a parenthesis in itemcallnumber, but still
removes e.g. a colon (:) at the end of a title.
Removed an unneeded global and lookahead from the regex.
Test plan:
1) Add a colon (:) to the end of a title.
2) Add a colon to the end of item copynumber.
3) Place a hold on that item. Check it in. Confirm hold.
4) Check the email or print notice generated. There should be no colon at the
end of the title, but the colon in the copynumber should still be there.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I compared checkout notices with lots of different fields before
and after applying the patch. For example the ) at the end of a
field in branches is now longer removed. Other fields looked ok
before and after.
Passes all tests and QA script.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
If you do not have ccode or location governed by authorized value
(you can release this default connection in the marc structure),
these item values are not passed through in the items section,
created by buildKohaItemsNamespace for XSLTParse4Display.
This simple patch checks if the authorized value hash on ccode or
location returns something and passes the original value in otherwise.
Test plan:
Temporarily disconnect ccode and location from authorized values
in MARC structure.
Edit an item, put some values in location and ccode.
Look at this record via opac search (XSLT enabled). Toggle the value of
OPACItemLocation to show ccode or location before call number.
Restore authorized values-connection when applicable.
Note: Since bug 9995 adjusts OPAC XSLT Results, it may be helpful
to apply these
patches when testing this.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works as described for the XSLT result list.
The text is shown when OpacItemLocation is set to show collection
or location.
Note: Displaying location and collection without using authorised
values doesn't work in other places like the detail page item table.
So this will need more work to be fully functional.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
A user might create a SQL report that relies on non-existent authorised value categories.
Because of a typo, or just because they copy&pasted the report from the Wiki.
Use cases are:
- The user creates a report from SQL
a) Uses bad authorised values
b) Clicks 'Save Report'
c) Koha lists the problematic authorised values
d) The user decides to
e-1) Save it anyway, it gets saved
e-2) Edit the report, it gets back to where it chose 'Save Report'
- The user edits an already saved report (Update SQL)
a) Uses bad authorised values
b) Clicks 'Update SQL'
c) Koha lists the problematic authorised values
d) The user decides to
e-1) Save it anyway, it gets saved
e-2) Edit the report, it gets back to where it chose 'Update SQL'
- The user tries to run a saved report that contains bad authorised values, Koha advertises the problem and provides the user with a button 'Edit SQL' to fix things.
To test, just create a report from SQL using invalid authorised values like this (misspelled 'branch'):
SELECT *
FROM itemtypes
WHERE hola=<<Test branch1|branchee>> AND
hola2=<<Test branch2|brancha>>
Regards
To+
Notes:
- I added several comments on the code.
- Fixed an annoying warning of uninitialised variable also (refactored some tiny bits to do it).
- Added the following methods
- C4::Reports::Guided::GetReservedAuthorisedValues
- C4::Reports::Guided::GetParametersFromSQL
- C4::Reports::Guided::IsAuthorisedValueValid
- C4::Reports::Guided::ValidateSQLParameters
- C4::Koha::IsAuthorisedValueCategory
- Those methods could have been used to refactor this guided reports code as its *a bit messy*. I chose to do it in a new bug of course :-D.
- Fixed some trivial perlcritic -5 errors
- Removed some debugging stuff left by mistake
- Fixed some POD problems
- Optimal SQL-driven IsAuthorisedValueCategory method
- Thanks to Owen and Jared for their patience heh.
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described. No koha-qa errors.
Test:
Tried with examples (from help and test plan) reports, correctly
identifies invalid authorized values, and no problem with
authorized ones.
NOTE: Online help for this does not states that partial values
need to be between '%' in a SQLish way. Perhaps this could be
addressed inserting % in values or adding a checkbox (partial|exact).
Or changing help.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
To test:
Use attached XSLT stylesheet for OPAC Results
* set your OPACXSLTResultsDisplay to use the attached stylesheet. The path is the FULL PATH, from /, to the file.
* be sure to copy MARC21slimUtils.xsl to the same folder, or change the path in the attached one to point to the correct path on your filesystem.
Verify that the OPAC results now show the holding branch instead of the home branch.
Possible fail states:
* no branch is shown (only call numbers, if given)
* the wrong branch is shown
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test Plan:
1) Stage a MARC record file that will have matches with existing records
2) Delete the bib from Koha that was matched on
3) Attempt to import the records into Koha, the import will hang
4) Apply the patch
5) Reload manage-marc-import.pl and attempt to import again, this time it should succeed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
When QueryWeightFields is enabled, the searching query is created with several options.
In C4::Search::_build_weighted_query, when no index is defined, the query is build with fuzzy and stemming options. When an index is defined, theses options are missing, only unconditional right truncation is used.
The consequence is that when QueryStemming is disabled, a search with index can give more results (due to right truncation) that a search without.
This patch adds stemming and fuzzy on search with index, conditioned with QueryFuzzy and QuerryStemming sysprefs.
Also changes world list search (wrld) weight to r6 in order to set fuzzy search to r8 and stemming search to r9 (like search without index).
Test plan :
- Go to searching preferences (admin/preferences.pl?tab=searching)
- Set QueryAutoTruncate to "only if * is added"
- Set QueryFuzzy and QuerryStemming to "Don't try"
- Set QueryWeightFields to "Enable"
- Go to advanced search page
- Select an indexe (ie Title) and perform a search on a short word
=> Look at zebrarv log and see that query does not contain right truncation : @attr 5=1
- Set QueryFuzzy to "Try"
- Perform same search
=> Look at zebrarv log and see that query contains fuzzy : @attr 5=103
- Set QueryFuzzy to "Don't try" and QuerryStemming to "Try"
- Perform same search
=> Look at zebrarv log and see that query contains rigth truncation on stemmed word : @attr 5=1
Signed-off-by: koha.aixmarseille <koha.aixmarseille@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
This patch makes Fuzzy and Stemming influence search results on weighted
queries when using an index. Side-effect is however that the results for a
search like index=term* (add truncation manually too) could be LOWER than the
the number of hits for index=term. Further comments on Bugzilla.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test Plan:
1) Catalog a new record with an ISBN
2) Add some items to the record
3) Download the record as MARCXML
4) Delete the itemnumbers from the 952 fields in the record,
Change the barcode fields to unused barcodes
5) Use xml2marc to save as a standard MARC file
6) Import the record using the 'Stage MARC for import' tool
Use the settings:
Record matching rule: ISBN
Action if matching record found: ignore
Action if no match found: ignore
Item processing: always_add
Check for embedded item record data?: Yes
How to process items: Always add items
7) Import, note the bib is ignored, and the items are not processed
8) Undo import into catalog
8) Apply this patch
9) Import this batch into the catalog
10) Note the items were processed and are now added to the matching
record
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Tested with UNIMARC record. I followed the test plan, just changing 952 by 995
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test Plan:
1) Switch off the IndependantBranches syspref
2) Log into the OPAC
3) Place a suggestions
4) Instead of seeing your suggestion, you will see "There are no pending
purchase suggestions."
5) Apply this patch
6) Reload the page
7) You should now see your suggestions
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Decodes userid on two places in checkauth of C4/Auth.pm
Test plan:
Include some non-Latin characters in your userid (loginname). Arab, Chinese?
Login into opac and check user page.
Go to staff (no new login), check your login name at various places.
Logout, login via staff.
Do the same.
Go to opac again (no new login), check user page.
Optionally: Remove all your sessions from table. Do a login. Check sessions.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Works as described. No errors.
This patch fixes this problem, but I wonder if
there is a general solution that handle all as utf8.
Tested in opac and staff.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Bug 6554 patched output_html_with_http_headers to encode utf8 data, and Templates.pm to expect utf8 data to be encoded.
(At least) the staff login screen outputs directly to STDOUT (Auth.pm does, WHICH IS WRONG!) and wasn't fixed to do the encoding first.
This patch makes it use output_html_with_http_headers and solves the problem.
Changed 'use' for 'require' as jcamins and marcelr suggested.
Regards
To+
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Error 'Modification of a read-only value attempted' triggered
on login because of manipulation of $_ in the map
Moved the mod to a loop as recommended in the doc for map
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Searching for stdid: Standard ID, srchany: RAW (any) somehow did not work
anymore.
Probably my fault :) Note that these two fields are in Cataloging Z3950 search
and not in Acquisition.
Fixing encoding problems: When adding -utf flag for CGI in acqui/z3950 and
cataloging/z3950, the decoding statements in C4/Breeding, Z3950Search should be
removed.
Test plan:
Search in Cataloging with:
Standard ID: 9782358670043 on LOC
RAW (any): musee [add an accent aigu on first e] on LOC -- Add diacritic!!!
Search in Acquisition
Somewhere, does not matter, but use a diacritic.
A note: My git version still has a hard time with utf8. Need to upgrade to version 1.7.10 to resolve this..
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described. No errors
Without patch z39.50 search for example Std ID OR musee gives no results,
with patch there are.
No problems in acq search.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Good catch, passes all tests and QA script.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
If a lost item fee is owed and partially paid off when an item is
returned and a refund is processed, Koha tries to pay off existing
fees before adding any leftover balance as a credit on the account.
However, those fee payments aren't actually processed, due to a bug
where the accountnumber was quoted as a string literal, and thus the
for the fee payment would fail. This did not result in an DB error,
as the query was still valid SQL. Checking the return value of the
query would have revealed that the accountline had not been updated.
History:
This bug was introduced on April 23, 2007 with the commit
'reintroducing fixaccountforlostandreturned as requested by rosalie'.
Commit id 111d590e9c
On July 30, 2009 the error was flagged with a FIXME and remained
in that state until now.
Commit id 51e8fc2cb6
Test plan:
1) Create a test patron
2) Check out an item to that patron and give it a due date in the past
3) Run fines.pl to generate the fine for the item
4) Mark the item long overdue on the item tab (not in edit items)
5) Pay for the lost item
6) Check the item back in
7) Note the incorrect fines. Only the lost fee balance due is refunded,
not the entire lost fee, but no other fees are paid off.
8) Apply the patch
9) Repeat steps 1-6, then not the fines are paid correctly
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Totel due is correct after applying the patch.
All tests and QA script pass.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test Plan:
1) Create a new serial with a default location, call number, and library
( the library will need to be any but the one you are logged in as )
2) Click the "Recieve" button for this serial
3) Click "Click to add item"
4) Note those values are not populated
5) Apply the patch
6) Reload the page
7) Click "Click to add item"
8) Note those values are now populated
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
All tests pass!
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This seems to restore the former behaviour.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
billingplace and freedeliveryplace are missing in C4::Acquisition::NewBasketgroup.
Test plan :
- Go to a vendor basket groups
- Create a new basket group
- Enter a name
- Choose a billing place
- Do not choose a delivery place in combobox but enter a text in delivery place textarea
- Enter a comment
- Save
- Edit created basket group
=> Check that billing place and free delivery place are ok
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works according to test plan, delivery place is now
correctly saved into the databas and was before lost.
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This bug was due to a difference in field names used in the item data
for items versus patrons. This patch adds a ternary to discern between
the two.
To test:
Before applying patch:
1. Create a batch of patroncards with one duplicate.
2. Run the de-duplication on the batch.
3. Note that all patrons beyond the first in the batch are now
deleted.
After applying patch:
4. Repeat steps 1-2.
5. Note that only the duplicate patron is removed.
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Tested successfully with both patron card batches and label batches.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Add indentation for readability
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Some patron infos were hard coded instead
of using the variables defined in SIPtest.pm
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Removing binmode, now encoding data in output_with_http_headers.
Replaced output_string by output_as_chars in XSLTParse4Display.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No errors.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
In current implementation (mostly commented out in this patch)
uses heuristic to guess which strings need decoding from utf-8
to binary representation and doesn't support utf-8 characters
in templates and has problems with utf-8 data from database.
With this changes, Koha perl code always uses utf-8 encoding
correctly. All incomming data from database is allready
correctly marked as utf-8, and decoding of utf8 is required
only from Zebra and XSLT transfers which don't set utf-8 flag
correctly.
For output, standard perl :encoding(utf8) handler is used
so it also removes various "wide character" warnings as side-effect.
Test scenario:
1. make sure that you have utf-8 characters in your biblio
records, patrons, categories etc.
2. try to search records on intranet and opac which contain
utf-8 characters
3. install language which has utf-8 characters, e.g. uk-UA
dpavlin@koha-dev:/srv/koha/misc/translator(bug_6554) $
PERL5LIB=/srv/koha/ perl translate install uk-UA
4. switch language to uk-UA and verify that templates
display correctly
5. test search and Z39.50 search and verify that caracters
are correct
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I followed the test plan, adding utf-8 characters to library names,
patron categories, titles, and authorized values. I tried the uk-UA
translation and everything looked good.
When performing Z39.50 searches for titles containing utf-8 characters I
got results which were still occasionally contaminated with dummy
characters [?] but I assume this is Z39.50's fault not the patch's.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Already signed, add mine.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Currently, if you install the Norwegian translations and run
through the web installer in Norwegian, choosing NORMARC as you
marcflavour, the marcflavour syspref is set to MARC21.
To test:
- Apply the patch
- Install nb-NO
- Run through the web installer, choosing nb-NO as the language
- Choose NORMARC as the MARC dialect
- When the web installer is done, check the value of the
marcflavour syspref. It should be NORMARC, not MARC21.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Did a regression test installing UNIMARC too.
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
For limiting XISBN API use, XISBNDailyLimit syspref is used to compare
with daily use count of the API. This count is stored in
services_throttle table. But this table content is never initialized,
not in installer nor in updatedatabase. So count is never increased and
API is used without limit.
This patch add an insert of service type in services_throttle if not
existing. So service throttle will be initialized.
Test plan :
- Check that you don't have a line in services_throttle for
service_type=xisbn
- Activate FRBRizeEditions and XISBN sysprefs
- Set a small number in XISBNDailyLimit (ie 5)
- Go to a biblio page (with ISBN)
- Look at services_throttle table
=> you should have a line for service_type=xisbn with service_count=1.
- Refresh biblio page untill limit is reached
=> service_count should be equal to limit for service_type=xisbn
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Passes test plan correctly.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Fixes problem, tested according to test plan.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Exporting to Bibtex from OPAC returns a software error.
This is because call to C4::Biblio::GetMarcAuthors does
not return only authors but also authority link.
This patch replaces this call by a direct read of
MARC::Record, like for other Bibtex datas.
C4::Biblio::GetMarcAuthors is really destinated to a
direct use in a template.
Also, actually all author subfields are joined with
'and'. According to Bibtext format, authors should be
"firstname surname and ..." or "surname, firstname and
...". I have choosen second one because in non-UNIMARC
it corresponds to $a content.
For example UNIMARC :
700 $aDoe $bJohn
700 $aDoe $bJanne
Gives : Doe, John and Doe, Janne
For example MARC21 :
700 $aDoe, John
700 $aDoe, Janne
Gives : Doe, John and Doe, Janne
Test plan :
Without patch :
Exporting to Bibtex from OPAC returns a software error.
With patch :
Exporting to Bibtex from OPAC succeeds.
Authors are composed using : $a, $b and ... for UNIMARC, $a ... for other marc flavours.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Works as decribed. All record export that produces
error pre-patch, now export without error.
No koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixes error and output of additional authors.
Main entry in 100 is still missing.
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
If XSLTResultsDisplay is enabled and items in your search results lack a
shelving location or a ccode errors will appear in the log complaining
of "uninitialized value in hash element." This patch adds a check on
these values to quiet the errors.
To test, find or create a record with items which have no shelving
location and/or no collection code. Perform a search the results for
which will include your record. Check for errors in the log.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Cleans up logs for result list quite a bit.
Passes all tests and QA script.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
