There were some issues in the previous patch. This patch fixes the
following:
- rename $value with $original_value
- remove $at_least_one_constraint_failed and $values_ok which make the
code unnecessarily complicated
- the constraints have to be checked only if no original value is passed
- _buildColumnValue created a key to the default value hashref, it broke
the test:
last BUILD_VALUE if exists( $default_value->{$source} );
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Unique constraints should be checked when creating random data. Otherwise
we get failures when the generated data already exists on the DB.
This patch takes advantage of ->unique_constraints() to do the job,
looping through all the unique constraints defined for the source.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Theres was two missing heading columns Location and Fines in the Check out section of a Patron
Tested both patches together. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Mason James <mtj@kohaaloha.com>
There was two missing heading columns (location and fine) and one hidden heading missing column (this hidden column is needing for sorting the table) it was taking the due_date column for the hidden column, so I added them
Both patches tested together. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Mason James <mtj@kohaaloha.com>
The original patch correctly unmasks the global variable (by
removing the 'my' on the marc2ris function, but wrongly introduces
a new global variable.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Variable $itype is used an all C4/Ris.pm to switch
between marc falvors, but is local and not passed along
as argument.
As a quick solution, is defined as global
To test:
1) On UNIMARC setup, export a record as RIS,
check that author (and other fields) are displayed
incorrectly
2) Apply the patch
3) Export again, improved results
4) Run t/Ris.t
There are other problems in this script, needs maintenance
(e.g. no Modern::Perl friendly)
Signed-off-by: Victor do Rosário <jvr@fct.unl.pt>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Mason James <mtj@kohaaloha.com>
The inventory tools automatically check in items, this patch adds it as
an option.
Test plan:
1/ Check an item out, fill a file with its barcode, and use this file in
the inventory tools.
2/ Check the new checkbox and confirm that the item is not checked in
3/ Repeat again and don't check it, the behavior should be the same as before
this patch.
Signed-off-by: Jason Robb <jrobb@sekls.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Added a missing </li>.
Patch works as expected.
Signed-off-by: Mason James <mtj@kohaaloha.com>
NOTE: Before patch "./misc/cronjobs/batch_anonymise.pl --help" had no
message, and neither did the anonymizing tool in the staff client.
After the patch, both had informative messages.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Mason James <mtj@kohaaloha.com>
There are at least 2 wrong behaviors if the AnonymousPatron pref is not
defined (0 or empty string).
1/ If you use the clean borrower tools, you will get a successful
message when the nothing happened (the history has not been anonymised).
2/ At the OPAC, if a patron ask for delete his reading history, he will
get an error message "The deletion of your reading history failed,
because there is a problem with the configuration of this feature.
Please help to fix the system by informing your libr ary of this
error". IMO this should not happen, the history should be anonymised.
With this patch, the old_issues.borrowernumber field will be set to NULL
if the AnonymousPatron pref if not defined.
Test plan:
1/ Fill the pref with "" or 0
2/ At the OPAC, go on the privacy tab and click on the "Immedia deletion" button.
You should get a green and friendly message. Confirm that the history
has been anonymised.
3/ Use the "Batch patron anonymization" tools (tools/cleanborrowers.pl)
to anonymize the checkout history.
Confirm that a) it works and b) you get a message.
Try again with AnonymousPatron set to a valid patron. You should not see
any changes with the current behaviors.
NOTE: This patch tweaks C4/Circulation.pm and provides tests.
applying just this, and running prove success. Reverting just
C4/Circulation.pm fails, as expected.
Tested OPAC stuff with both patches applied.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Mason James <mtj@kohaaloha.com>
to test..
1/ run t/Creators.t test from git repo, get a FAIL
2/ apply patch
3/ repeat step 1, get a PASS
mason@xen1:~/g/k/3.16.x$ sudo koha-shell -c 'export PERL5LIB=/home/mason/g/k/3.16.x ; cd /home/mason/g/k/3.16.x ; prove -v t/Creators.t' k316x1
t/Creators.t ..
1..16
ok 1 - use C4::Creators;
ok 2 - use C4::Creators::PDF;
ok 3 - testing new() works
ok 4 - testing pdf file created
ok 5 - testing Add() works
ok 6 - testing Bookmark() works
ok 7 - testing Compress() works
ok 8 - testing Font() works
ok 9 - testing FontSize() is set to 12 by default
ok 10 - testing FontSize() can be set to a different value
ok 11 - testing Page() works
ok 12 - testing StrWidth() returns correct point width
ok 13 - testing Text() writes from a given x-value
ok 14 - testing Text() writes to the correct x-value
ok 15 - testing End() works
ok 16 - test file /tmp/4YjPQDExeS created OK
ok
All tests successful.
Files=1, Tests=16, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.48 cusr 0.05 csys = 0.57 CPU)
Result: PASS
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Mason James <mtj@kohaaloha.com>
The regex /|date>>/ will match much more than you like :)
The unescaped pipe is bad, but you also need to remove the >> because
the split a few lines above it removes them already.
This allows you to recover from an error like this one, running another
report with a string parameter:
The given date (india%) does not match the date format (us) at
Koha/DateUtils.pm line 144.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended for possible spaces around the word date.
The issue is that SQL expects ISO dates, but the user may wish to view dates according to the dateformat system preference.
By detecting a date preference, the non-ISO dates can be converted to ISO dates before being stuffed back into the SQL query to be executed.
TEST PLAN
---------
1) Add a report with date parameters.
-- I used 'Holds placed in date range' from
http://wiki.koha-community.org/wiki/SQL_Reports_Library
2) Set your dateformat to YYYY-MM-DD
3) Run the report
-- Note the SQL reads
"... BETWEEN '{date formatted in YYYY-MM-DD}'..."
-- If there is supposed to be data, there is some.
4) Set your dateformat to MM/DD/YYYY
5) Run the report
-- Note the SQL reads
"... BETWEEN '{date formatted in MM/DD/YYYY}'..."
-- If there is supposed to be data, there is none.
6) Apply patch
7) Repeat steps 2-5
-- The SQL will always read YYYY-MM-DD (ISO) format.
-- The report will have data, if there is some.
8) koha qa test tools.
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Adding a QA follow-up.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Script memberentry.pl contained a similar line.
Solution is simpler here.
Test plan:
[1] Add, change or clear the sms number at staff side.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit bdf4894c50)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit c323e07c0c)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
This is an issue discussed on older reports already in the past.
Column mobile in borrowers is actually 'Other phone', not necessary a
mobile number. The name of the field is confusing. (Renaming it is
outside the scope of this report.)
The field that we are editing here is smsalertnumber. It should not be
compared with mobile at all.
What could be the side-effect of this correction?
===
First, the change is only relevant for libraries with pref SMSSendDriver
enabled.
In the past patrons editing their message preferences saw mobile (read:
other phone) in their smsalertnumber field (if the latter was still empty).
If they saved it, it was copied to smsalertnumber.
This change does not affect these patrons. They just have the same number
in two columns. No big deal.
What if a patron does not yet have a smsalertnumber? In that case no sms
is sent in Letters.pm. So no change in behavior. If he submits
opac-messaging now, he will no longer copy his other phone to smsalert [we
cannot assume that it was mobile anyway!]. If he enters a mobile number,
it will be saved correctly in the right field.
Conclusion: this change will not break things or hurt anyone. It only
prevents unwanted copying other phone to smsalertnumber.
Also modified the compare to prevent uninitialized warnings.
And removed a commented warn.
Test plan:
[1] Add, edit or delete the SMS number on opac-messaging regardless of
the value of Other Phone (in the badly named mobile field).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 9b8d7168be)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit bc72046421)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Enables to clear SMS number.
To test:
1. Go to opac-messaging.pl
2. Insert SMS number and submit
3. Clear SMS number and submit
4. Observe that the sms number did not change
5. Apply patch
6. Clear SMS number and submit
7. Observe that the sms number changes
Sponsored-by: Vaara-kirjastot
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Adding a follow-up.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 5b1c7e4c35)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 227d7b950e)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
I have been working with messaging preferences and I noticed a weird issue in Firefox on Ubuntu.
On messaging preferences page, the table is unsorted and the content in rows are generated randomly
on every page refresh. When you select/deselect checkboxes and refresh the page (without posting the changes),
Firefox will remember your choices. Now the issue is that when the table is unsorted and the rows keep
changing on page refresh, Firefox has trouble remembering your choices. This makes it appear as if the
checkboxes are magically changing values on each page refresh.
Here is a patch that prevents this problem by sorting the messaging settings.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 46ac35f8e1)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 6c44d1f464)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
If an item is on reserve for two courses but one of those courses is
disabled, both courses are still listed on opac-detail.pl!
Test Plan:
1) Enable course reserves
2) Create two courses
3) Place one item on reserve for both courses
4) Disable one of the two courses
5) View the record details for that record/item
6) You should see both courses listed in the course reserves column
7) Apply this patch
8) Reload the page
9) You should now only see the active course in the course reseves column
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 73e9dcb70f)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 9c31f1af9b)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
When getting records from OAI-PMH, an error must be returned if there is no results.
See : http://www.openarchives.org/OAI/openarchivesprotocol.html#ErrorConditions
Test plan :
- Enable OAI webservice
- Perform a query that will return no results. ie : /cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=marcxml&from=2099-12-30&until=2099-12-31
=> Without patch you get a response with :
<ListRecords/>
=> With patch you get a response with error code :
<error code="noRecordsMatch">No records match the given criteria</error>
- Check a good query returns still results
- Same test with ListIdentifiers verb
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 64992a05ce)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 3d8e059513)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit abd71d017e)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit c7dfbfedd3)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Add subfields l, n and o for better UNIMARC compliance
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Note: I just did a code audit here, as I don't know enough about
UNIMARC to know if the 4XX fields should have these subfields.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 503dd60369)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 84ee44110a)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
When AutoBarcode is activated and you have set AcqCreateItem to 'on
order' there is a Javascript error when you try to generate a barcode
for the item:
TypeError: document.f is undefined
http://localhost:8080/intranet-tmpl/lib/jquery/jquery.js
Line 11
Test plan:
0/ a. Set AutoBarcode to hbyymmincr
b. Set AcqCreateItem to 'on ordering'
c. Set the plugin barcode.pl to the barcode field for the default
and the ACQ frameworks
1/ Go on the add items page (cataloguing/additem.pl) and confirm that
the plugin works as expected.
2/ Go on the New order page (acqui/neworderempty.pl) and confirm that
the plugin works as expected.
Followed test plan, works 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@theke.io>
(cherry picked from commit 5b521eb394)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 272650cb3f)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
If IdependentBranches is ON, to edit/delete items from other branches
you need to be superlibrarian.
Currently a "simple" staff user cannot edit them from the edit item page
but from the catalogue detail page.
The edit links should not be displayed on this table.
Test plan:
O/ Set IndependentBranches to "Prevent".
Create a record and add 2 items:
Set homebranch to L1 for item I1.
Set homebranch to L2 for item I2.
1/ With a superlibrarian user, you should be able to edit both items.
2/ With a "simple" user attached to L1, you should only be able to edit
I1. The edit links should not be displayed for I2.
Note that the checkbox is displayed on the catalogue detail page (item
list), but on the batch tools, it won't be possible to select non-modifiable
items.
TODO: Add a server-side check. Indeed it is still possible to edit an
item if the user know the url.
Followed test plan. Works 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@theke.io>
(cherry picked from commit bcab241639)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 28fe340ea7)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
This patch makes the tests non dependent on the DB and test the 3 marc
flavours.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 6e0b61e2ac)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 27ba1a6fa1)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
The unit test is db dependent (as Jonathan correctly remarked),
since the sub checks a preference.
Test plan:
Run t/db_dependent/Biblio/TransformHtmlToXml.t
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: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit d1335a766d)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 74e46b7467)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
The pref are double encoded.
From bug 12411:
"This will fix the encoding issues existing in 3.14 and 3.16.
The issue still appear in master but is fixed by bug 11944."
They should not have been pushed together.
Test plan:
1) You need an accentuated language installed.
2) Go to NoLoginInstructions pref, and add some accentuated message like
"Hélo médames é mècieüx"
3) refresh opac home page, message should be gibberish
4) apply patch. Message should be ok now.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Works as expected.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 813a047e23)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 270187404e)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
On creating an item type, if it already exists, it will replace the
existing one.
This patch prevent that and display a message to the interface.
Note: The fields are lost.
Test plan:
1/ Create an item type 'AAA', description 'AAA'
2/ Edit it, update the description with 'BBB'
3/ Create an item type 'AAA' with a description 'CCC' => you should get
a warning "already exists".
Works well, no errors
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com>
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Warning message is triggered.
Adding, editing and deleting item types still works.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit eb12ee1e22)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
The special regex chars are not escaped in C4::HTML5Media.
Test plan:
1/ Set 856$u=http://www.mrqe.com/lookup?talented+mr.+ripley
2/ Enable the pref HTML5Media
3/ Go on the detail page
It should not explode.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 085d766a05)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
On the edit items page, there is some weird JS code: if the user clicks
on the delete link and then cancel, the item is deleted anyway.
It's caused by the following JS code in browser.js
$('a[href*="biblionumber="]').click(function (ev) {
ev.preventDefault();
window.location = $(this).attr('href') + '&searchid=' + me.searchid;
});
Test plan:
- Do a search with multiple results
- Go to the detail page (make sure results browser shows up!)
- Use the "Edit items" link from the toolbar
- Delete an item (try both way)
- Choose "cancel"
- Delete an item (try both way) and confirm the deletion
You should see the browser after the deletion and the item should have
been deleted correctly.
- Edit an item (try both way)
You should see the browser (did not work before this patch)
Note: Before this patch, the 2 first columns didn't contain the
edit/delete item links, now it's only the 1st one.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Much better!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit f7214859df)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
The ind_tag of TransformHtmlToXml is unused.
Some calls to this function incorrectly revert indicator and ind_tag (which
is not a problem when both are empty..)
Patch of Srdjan Jankovic, amended and signed off by Marcel de Rooy.
The following calls are fixed:
call in acqui/addorder.pl: switched indicator with ind_tag
call in acqui/addorderiso2709.pl replaced too
acqui/finishreceive.pl replaced too
These calls are fine:
two calls in cataloguing/additem.pl are fine
call in serials/serials-edit.pl is fine
call in tools/batchMod.pl is fine
The folllow-up patch adds a simple unit test.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
With AcqCreateItem=='placing an order', tested if adding an order still
worked (covered both addorder.pl and addorderiso2709.pl).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 22b4106398)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Bug 10404 adds the use of String::Random to catalogue/search.pl but bug
11369 removes it without removing the import line.
Test plan:
git grep String::Random catalogue/search.pl
should not return anything
Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 90285259e8)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
The previous patch wants to select the barcode option when the user is
on the item search for label, in all cases.
So even if 'title' is selected, a search done, and there is no result,
the barcode index is selected anyway.
In this case, the title option should be kept.
Test plan:
Confirm that the barcode option is the default choice, but other values
are kept if the search does not return any result.
Followed test plan, behaves as expected. Tested with all choices.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 1f0ff90360)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Test case:
* Go to "Tools -> Label creator -> Manage batches"
* Click on the "New batch" button
* Click on the "Add item(s)" button
* A search window should open. The "Barcode" value should be selected in the the selectbox.
Followed test case. Patch behaves as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Adds a new line for the holiday's description instead of the string
\r\n.
Test plan:
1. In tools -> Calendar look at some holiday's description
(Do a new holiday with description of multiple lines if
there is not already)
2. Notice that there is characters \r\n if someone has put
a newline in the holiday's description
3. Apply patch
4. See that the new lines show there now nicely
Sponsored-by: Vaara-kirjastot
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended slightly: no need to replace title.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
The crux of the issue is that if you are using item level itemtypes, but
are allowing biblio levels holds, those holds do not have items.
So, in CanItemBeReserved, when Koha counts the number of holds to
compare against the given rule, it will always give 0 ( except of course
for found holds, and the occasional item-level hold ).
So the query is saying "link each of these reserves to the reserved
item, and count the number of reserves this patron where the itemtype is
DVD". However, since these are all record level reserves, there are no
items to link to, and so when it looks for all reserves this and item
whose itemtype is DVD, it finds zero reserves!
This patch solves the problem by looking first at the item level
itemtype, and if it does not exist, then it looks at the record
level itemtype. For installations using record level itemtypes, the
behavior remains unchanged.
Test plan:
1) Enable item level itemtypes
2) Create two records with one item each of a given itemtype
3) Create a single issuing rule and limit the holds allowed for that
itemtype to 1
4) Place a record level hold on your first record
5) Attempt to place a record level hold for the same patron on your
second record. You should not be able to but you can!
6) Apply this patch
7) Repeat step 5, note you can no longer place the hold!
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
This patch adds unit tests for the previous changes and centralize the
timezone handle into the Koha::DateUtils module.
Like that the behavior will affect all date manipulations using this
module (should be all dates in Koha).
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Test plan:
1. Create a new serial record or pick an existing one;
2. Add a "New subscription" and set the "First issue publication date"
and "Frequency" values so that the "Planned date" for a given issue
hits a day where a transition to Daylight Saving Time (DST) occurs
ex:. 1979-04-01 in Europe/Lisbon (http://www.timeanddate.com/time/change/portugal/lisbon?year=1979)
... use this website page as a source http://www.timeanddate.com/time/dst/2014.html
to find a suitable transition to DST in your timezone in the current year.
3. From the "Subscription detail" page in Koha for the given record click
the "Serial collection" link on the left side context menu.
Expected result:
Prior to applying the patch the error described in this bug report should occur.
After the patch is applied the "Serial collection" page should load correctly.
Signed-off-by: Colin Campbell <colin.campbell@ptfs-europe.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
There is no permission needed to access the patronimage.pl script.
This means anybody cans access to the patron's images.
Test plan:
Add an image to borrowernumber 42 and call
/cgi-bin/koha/members/patronimage.pl?borrowernumber=42
If you are logged in with borrowers permissions, you will see the image,
otherwise you will get a blank page with a 403 header.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Conflicts:
members/patronimage.pl
Test plan:
Verify that the circulate_remaining_permissions perm is enough to upload
.koc file.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 2fcc02321f)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Mason James
Jonathan Druart
Tomas Cohen Arazi
genevieve
Tomas Cohen Arazi
Bernardo Gonzalez Kriegel
Jonathan Druart
Marcel de Rooy
Mark Tompsett
Joonas Kylmälä
Lari Taskula
Kyle M Hall
Fridolin Somers
Julian Maurice
Paul Poulain
Srdjan
Jonathan Druart
Frédérick
Rolando Isidoro
Liz Rea
Alex Arnaud