opac-account.pl does not include the login branchcode, whereas the other pages
available to users (opac-user, opac-memberentry, opac-passwd, opac-readingrecord,
opac-suggestions, opac-messaging, opac-shelves, etc.) on login DO provide
the login branchcode. Having the login branchcode available on opac-account.pl
would facilitate customization of the OPAC for individual branches.
To test:
1) Login to the OPAC and open /cgi-bin/koha/opac-account.pl
2) Inspect the body tag and observe the class attribute does not include
the login branchcode.
3) Apply the patch.
4) Repeat step 2.
5) Observe that the login branchcode is present.
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit 1bfcebfb7f)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit 2bfd9a95f0)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Yes, we are fixing these four typos here.
Test plan:
[1] Read the changes.
[2] Run t/Auth_with_shibboleth.t
[3] Run git grep recieved| grep -v -e 'recievedlist' | grep -v -e 'serials-recieve.tt'
Note: serials-recieve.tt is just history. Bonus points for the one who makes
us get rid of that column recievedlist.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
EDIT:
Rebased. Change in Accounts has been corrected already.
Removed the po file.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit b5c1a965b1)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit 327c2ba636)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
This patch makes Zebra index the 648$9 link for chronological terms on
bibliographic records. This way an authority search on chronological terms
will show the right number in 'Used in X records' message.
To test:
- Have a record with a 648 field, linked to an authority record (i.e. with an authid on 648$9).
- Search for the record, notice it is indexed.
- Perform an authority search for the chronological term
=> FAIL: the term is linked to our record, but koha shows '0' count.
- Apply the patch
- Run:
$ cd kohaclone
$ xsltproc etc/zebra/xsl/koha-indexdefs-to-zebra.xsl \
etc/zebradb/marc_defs/marc21/biblios/biblio-koha-indexdefs.xml \
> etc/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl
$ git diff
=> SUCCESS: Notice the shipped etc/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl
is up-to-date
- Run:
$ sudo cp etc/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl \
/etc/koha/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl
$ sudo koha-restart-zebra kohadev
$ sudo koha-rebuild-zebra -f -b -v kohadev
- Search for the record, notice it is indexed.
- Perform an authority search for the chronological term
=> SUCCESS: the term is linked to our record, usage count is 1
- Sign off :-D
I assume NORMARC is similar on this regard. Feel free to fail it if the NORMARC part of the
patch is wrong.
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit cb3f899826)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit 80955d365a)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Fixes a small typo introduced by Bug 17010
waitingreserves.p#[% tab %]
should be
waitingreserves.pl#[% tab %]
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit a1592ec10b)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit 45bd59064f)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
This patch implements the notices toggle event using a different method.
Using on() lets us bind the event to a parent element, allowing the
event to attach to elements which may not exist on the page yet.
Test plan the same as original patch:
1) have a patron with more then 20 notices sent
2) go to patron profile -> notices
-> without patch, the showing/hidding of notices content does work
correctly only on first loaded page
-> with patch, it should work correctly everywhere - try to use
paginator, searching, ordering....
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Using a DateTime object with a timezone of America/Santiago
was causing fatal errors for Koha::Calendar->is_holiday
and Koha::Calendar->exception_holidays, when the objects
were truncated to an invalid local time.
Using a floating zone allows us to use the same day, month, year
for comparison purposes without running into the possibility of
creating an invalid local time and thus a fatal software error.
Edit:
While the changes to is_holiday and single_holiday make sense (Jonathan agrees too)
I didn't manage to have them fail, because truncate is not failing in my trials, but
days_between. So to me, it narrows down to have exception_holiday return floating tz
datetime objects so it doesn't break days_between.
Anyway, it is ok to push this patch, and the regression test I provide covers this scenario
I'm describing.
To test:
- Apply the regression tests patch
- Run:
$ prove t/db_dependent/Holidays.t
=> FAIL: Unexpected error due to bad timezone/date combination
- Apply this patch
- Run:
$ prove t/db_dependent/Holidays.t
=> SUCCESS: Tests pass
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit 32354d8322)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit 5e9056a99c)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
This patch introduces a regression test for exception_holidays. This routine
returns a list of datetimes to be used in date comparison and some datetimes don't exist
in some timezones, so floating timezones should be used instead.
To test:
- Apply the patch on master
- Run:
$ prove t/db_dependent/Holidays.t
=> FAIL: The new test fails
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit c6a0848ff0)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit aa5c67486f)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit 36c608ab84)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit 317bd60f18)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Tax rates are stored in decimal(6,4) fields which means that 4 decimals
are allowed.
If a tax rate is 8.42%, it is stored as 0.0842
If a tax rate has more precision than that, Koha won't deal correctly
with it. We will need to update the DB structure.
With this patch, the tax rate will be displayed with the same precision
as in the DB. So if you enter 8.42, you will see 8.42% instead of 8.4%
without this patch.
Test plan:
Do a full acquisition workflow with a tax rate like 8.42% and confirm
that it is correctly displayed.
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit cb3d6625e8)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit ff33093591)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
The calls
output_pref({ dt => dt_from_string( $date ) })
are wrong and should be replaced with
output_pref({ str => $date })
For better error handling.
Here we fix the problem of items.onloan when searching
Test plan:
- Set items.onloan=0000-00-00 (UPDATE items SET onloan='0000-00-00')
This can come from old data or bad migration
- Execute a search
=> Without this patch you get
Can't locate object method "ymd" via package "dateonly" (perhaps you forgot to load "dateonly"?) at /home/vagrant/kohaclone/Koha/DateUtils.pm line 225.
=> With this patch you won't get the error
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit 167c74bfd3)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit a5ce343c9d)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
When doing a search, with SearchHistory pref switched on:
DBD::mysql::st execute failed: Column 'time' cannot be null [for Statement "
INSERT INTO search_history(
userid, sessionid, query_desc, query_cgi, type, total, time
) VALUES(
?, ?, ?, ?, ?, ?, ?
)
" with ParamValues: 0="7874", 1='12338a0bd8da63e32c79ee84f8493a07', 2="kw,wrdl: d", 3='q=d', 4='biblio', 5=6104, 6=undef] at C4/Search/History.pm line 34.
Since MySLQ 5.7, undef does not mean "the default value".
To let the DBMS set the default value (CURRENT_TIMESTAMP), the parameter should not be passed
Test plan:
OPAC+Intranet, swith the 2 SearchHistory syspref on
Do a search
=> Without this patch, you will get an error in the log and the row will not be inserted in the table.
=> With this patch, everything must go fine
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Not verified with MySQL 5.7. But this looks good to me.
Works under Jessie.
Signed-off-by: Mason James <mtj@kohaaloha.com>
ttf-dejavu was missing from the build dependencies.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Mason James <mtj@kohaaloha.com>
See the bug description for the details.
Test plan:
Use this script to create a new koha installation, using MariaDB
You should not display
"user koha_kohadev doesn't have enough privilege on database koha_kohadev "
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Confirm that this still works (with MySQL).
Signed-off-by: Mason James <mtj@kohaaloha.com>
So let's rename it!
Test plan:
Edit a $t in any framework, you should be able to unfold the "Advanced
constraints" part
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Mason James <mtj@kohaaloha.com>
members/moremember.pl will set mobile number as smsalertnumber in template if
smsalertnumber is not defined. This will cause incorrect display for SMS number
in patron's Details-tab. This confusion between smsalertnumber and mobile is
already fixed in Bug 14683, but members/moremember.pl was not fixed yet.
This is a minor issue since it won't occur for manually added new patrons due to
fixes already pushed in Bug 14683, but in case patron's smsalertnumber is null
in database, this bug can be replicated:
To test:
1. Set EnhancedMessagingPreferences to "Allow" and make sure SMSSendDriver
has been set.
2. Add a new patron, give it a mobile/other phone number.
3. Run a SQL query:
update koha.borrowers set smsalertnumber=NULL where borrowernumber=XXX;
(replace XXX with your new patron's borrowernumber)
4. Go to patron's details tab and observe that SMS number shows the mobile/
other phone you provided earlier.
5. Apply patch.
6. Refresh patron's details tab.
7. Observe that smsalertnumber is now empty, as it should be.
Followed test plan, works as expected.
Signed-off-by: Marc <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Mason James <mtj@kohaaloha.com>
To test:
Set 'delimiter' system preference to 'tabs'
Export a report as csv
Open the file in text editor and note fields separated by character 't'
Apply patch
Export report as CSV
Open file in text editor and note tabs are used to separate fields
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
tabs now, no errors.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
If the AllowRenewalIfOtherItemsAvailable sys pref is set to allow, and a
borrower has an item checked out that has many items {30+} AND many
holds {70+) on it, loading the checkouts table for this borrower takes
FOREVER to load. The load time takes forever, because of the
factoring that happens to determine if an item is truly
available for renewal.
This patch swaps the use of GetMemberDetails for GetMember
and reorders the subroutine calls to check each items' renewability
from fastest to slowest.
In a test case, the results of pre patch were:
Start of loop: 2016-08-24T11:05:14
End of loop: 2016-08-24T11:05:29
Resulting in 15 seconds being spent in the loop
Post patch results were:
Start of loop: 2016-08-24T11:08:43
End of loop: 2016-08-24T11:08:48
Resulting in only 5 seconds being spent in the loop!
Test Plan:
1) Apply this patch
2) Note there are no changes in functionality for the renewals column of
the patron checkouts table.
If you wish to go further and test the performance benefit:
1) Create a record with 50 items and 100 holds ( 50 waiting, 50 unfilled )
2) Check out one of the waiting holds to a patron
3) Time the amount of time it takes for the checkouts table to load
4) Apply this patch
5) Repeat step 3, you should see an improvement in load time
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
If the period is entered without spaces wrapping the hyphen
You can't get any result
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
I can't reproduce the error, search still works after applying the patch
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Mason James <mtj@kohaaloha.com>
When you order from a staged file you're getting duplicate warnings that
are inaccurate. For example, when you order a file of 50 DVDs for
example and they don't have ISBNs they're matching on the books. And
then you have to order them one by one.
This patch replaces the use of FindDuplicates with Koha's match point
system. This means you can select from the same match points defined
and used in the batch record importer, or you can opt to skip matching
altogether!
Test Plan:
1) Import a record with a title, isbn and author.
2) Delete the from the record and stage it again
3) Attempt to add it to a basket via the staged record
4) You should note the gives you the "No records imported" message
5) Apply this patch
6) Create a matcher for ISBN
7) Create a matcher for Author/Title
8) Attempt to add the record to your basket using the ISBN matcher
8) Koha should find no match and import the record to the basket
9) Stage the record again
10) Attempt to add the record to your basket using the Title/Author matcher
11) You should recieve the "No records imported" message.
Signed-off-by: Barbara Fondren <bfondren@roundrocktexas.gov>
Signed-off-by: Nicole C Engard <nengard@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Then we need to remove the "available" part from the query.
They are really awkward patches...
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
When a ccl query is used, the buildQuery subroutine does not handle
the available limit (not an index).
This available limit is handle later in the subroutine.
This affect the author links on the detail page for instance (an=xx).
A much better solution would be to keep an 'available' zebra index up-to-date.
Test plan:
(OPAC or staff interface, it does not matter)
- Launch a search, click on a result and then on an author link to
launch another query (an:xx)
- Limit to available items without the 'facet'
=> Without this patch you won't get any results
=> With this patch applied you should get relevant result (regarding the
known bugs 16970, 13715, 13658, 5463, etc.)
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Bug 14686 added in a dbrev:
(13, 'upload_general_files', 'Upload any file'),
(13, 'upload_manage', 'Manage uploaded files');
But these were not added in userpermissions.sql somehow :)
So, what now?
This patch:
[1] adds them to userpermissions.sql as should have been done,
[2] adds a dbrev to add them for newer installs that did not run the
14686 dbrev.
Test plan:
[1] Run this sql statement:
DELETE FROM permissions WHERE code = 'upload_general_files' OR
code = 'upload_manage'
[2] Run the db rev.
[3] Check if you see Tools/Upload (with sufficient perms).
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Since we are pretty bad to maintain INSTALL files, I'd suggest to point
to the wiki.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>