Bug 12041 made xt/author/podcorrectness.t consider files in the 'Koha' namespace.
Some of them where failing. This patch fixes some of those POD problems.
Best regards
To+
Test:
1) run prove xt/author/podcorrectness.t
it fails
2) apply patch
3) run again, now it's ok
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Before patch test fails. After it, it pass
No koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Mathieu Saby [Wed, 9 Oct 2013 18:28:09 +0000 (20:28 +0200)]
Bug 11021: Suppress unneeded fields in unimarc_complet default Framework
First patch, for "complete" framework, used by academic libray
900, 901, 910, 918, 920,950,960,970,980,987 fields were useless. I removed them.
I kept only the fields mentionned in Sudoc documentation http://documentation.abes.fr/sudoc/formats/loc/index.htm
916 field is not cited in that page, but it belongs to Sudoc format.
I kept also 2 fields specific to Electre in 2013 :
902 niveau de lecture (Electre)
903 indexation (Electre)
I also added to the name of the 9XX fields I kept the mention (Sudoc) / (Electre) / (Koha), so it could be easier for librarians to know what is the purpose and the origin of each field
I don't make an updatedatabase, because some libraries could still be using these fields for good or bad reasons.
To test :
1) take a fresh Koha with unimarc marcflavor
2) in web installer, select french language, unimarc marflavor and "Grilles de catalogage complètes".
3) check default framework in Administration > MARC Frameworks : it should be without 900,901,910,918,920,950,970,980,987
Signed-off-by: Gaetan Boisson <gaetan.boisson@biblibre.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Magnus Enger [Thu, 5 Jun 2014 07:58:36 +0000 (09:58 +0200)]
Bug 12367 - Import patrons still says "MD5 hash"
The password hashing algorithm was changed in Bug 9611,
but on Tools > Import patrons, in the text on the right
hand side, it still says:
"'password' should be stored in plaintext, and will be
converted to a MD5 hash"
This has no practical effect, of course, but to someone
evaluating Koha it might give the false impression that
password security is lower than it really is.
To test:
- Look at Tools > Import patrons and verify that it says
"a MD5 hash"
- Also look at the help page and see the same text
- Apply the patch
- Check that both the tool and the help now says
"a Bcrypt hash"
I'll do a patch for the docs too.
Signed-off-by: David Cook <dcook@prosentient.com.au> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Juhani Seppälä [Tue, 17 Jun 2014 10:05:10 +0000 (13:05 +0300)]
Bug 12261: Staff client next/previous links lead to unknown record
When using Staff client next/previous links after a search :
If the current record is the last of the results, clicking on "next"
will lead to the page of an unknown record with message :
The record you requested does not exist (NaN).
To test:
1) Do an intranet catalog search that has more than 1 results.
2) Click on the last search result and then click the "Next"-button from
the top-left navigation.
3) Confirm that you get thrown to a page with the message: "The record
you requested does not exist (NaN).".
4) Apply patch.
5) Repeat steps 1 - 2.
6) Confirm that the navigation button for "Next" is greyed out.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This patch fixes the problem with last result in both single pages of
search results and multiple pages of search results.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Zeno Tajoli [Fri, 20 Jun 2014 09:47:00 +0000 (11:47 +0200)]
Bug 12299: Translate marc21_relatorterms.sql into Italian
To test:
- Apply this patch.
- Reset your DB (DROP DATABASE, CREATE DATABASE -- whatever method you
prefer)
- Install it-IT templates on command line
- Run the webinstaller using it-IT
- Follow the steps and choose all under 'opzionali'
=> SUCCESS: no errors
=> Sign this
=> Extra: see the authorised value 'RELTERMS' and check if you like the
translation
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Tested loading file.
Two errors fixed:
a) duplicate line ... ('RELTERMS','con', 'Conservatore')
b) missing semicolon ... ('RELTERMS','voc','Cantante')
With that file loads Ok
No koha-qa errors
Ooops, forget the fix. Resubmited
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Adds an optional SQL file to the Italian installer - works as expected.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Removed BOM from file.
Owen Leonard [Thu, 22 May 2014 16:22:44 +0000 (12:22 -0400)]
Bug 12255 - Amazon cover images have useless image alt text in bootstrap
"item-thumbnail" is not a useful alt text for an Amazon book cover
image. Better would be the link's title text, "View on Amazon.com." This
patch makes this correction. (Rather than "View at Amazon.com" which
doesn't sound correct to me).
To test you must have the OPACAmazonCoverImages system preference
enabled. Log in to the OPAC and view your list of checked-out titles.
The alt text for cover images should be "View on Amazon.com." Test in
both prog and Bootstrap.
NOTE: You'll need one to be overdue in order to trigger both
cases. Examine the HTML for both tabs in the person details
page.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This fixed the cover alt texts for Amazon covers in the patron
account for checkouts, overdues and holds.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Fridolin Somers [Fri, 20 Jun 2014 12:54:07 +0000 (14:54 +0200)]
Bug 12458 - Holidays calendar has wrong colors for weekly and yearly repeatable
In Tools / Calendar, the colors in the calendar for weekly and yearly repeatable are different from the color of the "Key" legend.
This patch sets the colors used in the "Key" legend to the cells if calendar.
Test plan :
- Go to Tools/Calendar
- Add a weekly repeatable holiday
- Check its color in calendar is the same as the text "Holiday repeating weekly"
=> Without this patch, it's green instead of yellow
- Add a yearly repeatable holiday
- Check its color in calendar is the same as the text "Holiday repeating yearly"
=> Without this patch, it's yellow instead of orange
- Check the color of others holydays types are OK
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
I'd like to see today's date a clearly different color from the
weekly repeated holiday, because now they're close in color.
But this patch does exactly what it says and should so I'm signing
off.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Legend, headings and calendar colors now match.
No problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Marcel de Rooy [Thu, 22 May 2014 07:40:05 +0000 (09:40 +0200)]
Bug 7143: Release team 3.18
See http://wiki.koha-community.org/wiki/Roles_for_3.18
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No errors.
Order is alphabetical?
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Nicole C. Engard [Tue, 17 Jun 2014 14:43:18 +0000 (09:43 -0500)]
Bug 12434: Fix Typo in Smart Rules Help
This patch fixes a typos in the help file on the circ and
fine rules.
To test:
Visit admin > circ and fine rules
Click help in the top right
Confirm that period is not spelled peiod
Signed-off-by: David Cook <dcook@prosentient.com.au> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
David Cook [Fri, 6 Jun 2014 04:01:17 +0000 (14:01 +1000)]
Bug 9093 - 008 forgetting what material type was chosen
This patch adds material type checking to the MARC21 008 tag editor,
based on value from the leader. That is, the 008 tag editor
will choose an initial material type based on the leader 06
(and if necessary the leader 07 position)
_TEST PLAN_
1) Create a new record or open an existing bib record
2) Change position 6 from its current value (probably "a") to
"c" or "e" or "g" or "m" or "p". (See the end of this message
for a comprehensive list of 06 values to try.)
3) Open the 008 tag editor
4) Note that it still says BKS even though it should say "MU"
or "MP" or "VM" or "CF" or "MX".
5) Apply the patch
6) Repeat steps 2 and 3.
7) Note that the 008 tag editor now shows the correct material
type based on the leader.
8) For more comprehensive checking, try switching position 6
back to "a" and changing position 7 to "b" instead of "m".
9) Note that it will switch from "BKS" to "CR".
10) Fin
Comprehensive mapping:
Field 008/18-34 Configuration
If Leader/06 = a and Leader/07 = a, c, d, or m: Books
If Leader/06 = a and Leader/07 = b, i, or s: Continuing Resources
If Leader/06 = t: Books
If Leader/06 = c, d, i, or j: Music
If Leader/06 = e, or f: Maps
If Leader/06 = g, k, o, or r: Visual Materials
If Leader/06 = m: Computer Files
If Leader/06 = p: Mixed Materials
http://www.loc.gov/marc/bibliographic/bdleader.html
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, nice job.
koha-qa complains for a tab char, removed on followup.
Mode change on TT file (+x), removed.
No other errors
NOTE: It would be desirable to update LEADER values
to reflect changes on 008.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Awesome work David.
Bug 12226 - A user with the database username/userid can access staff with full permissions
This patch implements 2 suggestions on comment #3
- Prevents creation of a new user with same userid
of database user
- When checking password, if userid matches database user,
only check against pass on config file
To test:
1. Create a new user with same login as database user
any password different from real db user
2. Check that you can login on staff using this user/pass
and you are superlibrarian
3. Apply the patch
4. Login again using new pass, it must fail
5. Login again using db pass, you are now superuser,
but system does not warn you :( No problem, that's
for having one borrower with that login
6. Delete user with same login as db user
7. Try to create one again as in 1, system must return
an error of duplicate login!
8. Check for no regressions on user/pass authentication
Resubmited, has an error
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
This works nicely and as described.
Also editing the former 'superuser' will force you to
change the userid in order to save any other change.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Katrin Fischer [Thu, 19 Jun 2014 15:39:56 +0000 (17:39 +0200)]
Bug 12454: Can't add new patron categories
To test:
- Add a new patron category
- After saving, the new patron category won't show up in the list
- Apply patch
- Try to add a new patron category again
- It should now save correctly and show up in the list of patron
categories.
Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Robin Sheat [Tue, 8 Apr 2014 05:51:01 +0000 (17:51 +1200)]
Bug 12041 - improve Koha::Cache
This makes Koha::Cache behave better by default. It will use memcached
if available to do shared caching, if that's not available it will fall
back to in-memory caching. It also allows for a singleton accessor to
allow a single cache to be shared within a process.
* Added tests to confirm UTF8-cleanness.
* Added minor fixups to stop warnings.
Test plan:
* The t/Cache.t file runs successfully with and without the
MEMCACHED_SERVERS envvar set (and memcached running in the
environment.)
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Galen Charlton [Tue, 27 May 2014 17:57:33 +0000 (17:57 +0000)]
Bug 11891: (follow-up) set DBIC storage flags correctly
Since we're passing an existing DBI database handle to
DBIC, and that handle doesn't have RaiseError set to true
by default, don't let DBIC override that -- for now.
Test plan: verify that the DB-dependent test suite passes.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Galen Charlton [Wed, 18 Jun 2014 22:25:22 +0000 (22:25 +0000)]
Bug 11891: (follow-up) remove custom storage class
For now, just rely on the normal DBIx::Class cleanup handler;
otherwise, the following warning is displayed in logs:
(in cleanup) Can't locate object method "_preserve_foreign_dbh" via package "Koha::Storage" at .../Koha/Storage.pm
Using the default DBIC storage class also means that we
don't have to manually do things like set the SQL limit dialect;
meaning that we don't get the following warning message:
DBIx::Class::ResultSet::find(): Your storage class (Koha::Storage) does
not set sql_limit_dialect and you have not supplied an explicit
limit_dialect in your connection_info. DBIC will attempt to use the
GenericSubQ dialect, which works on most databases but can be (and
often is) painfully slow. Please file an RT ticket against
'Koha::Storage' . at /home/gmc/koha/C4/Members.pm line 840
Test plan: same as main patch
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Kyle M Hall [Tue, 4 Mar 2014 18:26:03 +0000 (13:26 -0500)]
Bug 11891 - Make Koha::Schema use C4::Context->dbh
Right now there is no connection between the database handles used by
C4::Context::dbh and Koha::Datbase/Schema. This makes it impossible to
use transactions in unit tests to temporarily modify the database to
test subroutines that take advantage of Koha::Database. This patch fixes
that issue.
Test Plan:
1) Apply this patch
2) prove -v t/db_dependent/ILSDI_Services.t and
prove -v t/db_dependent/Items.t and
prove -v t/db_dependent/Circulation_issue.t should
all start passing
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Galen Charlton [Mon, 26 May 2014 18:39:11 +0000 (18:39 +0000)]
Bug 11891: set up tests to require that Koha::Database uses same DB handle as C4::Context
This patch removes changes in two cases to work around the fact that
Koha::Database and C4::Context were not using the same DBI database
handle.
To test:
[1] Run prove -v t/db_dependent/ILSDI_Services.t and
prove -v t/db_dependent/Items.t. Both tests
should fail.
[2] Apply the main patches and run step 1 again. This
time, both tests should pass.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Thu, 20 Feb 2014 15:06:36 +0000 (10:06 -0500)]
Bug 11801: In transit hold items incorrectly labels as "Waiting to be pulled" on request.pl
If an item needs to be transferred to fill a hold, the hold will be
listed as 'Waiting to be pulled" while it is in transit.
Test Plan:
1) Place a hold for pickup at another library
2) Check in the item, confirm the hold transfer
3) View the holds for that record ( request.pl )
4) Note the priority is "In transit" and the status is 'Waiting to be
pulled".
5) Apply this patch
6) Reload the holds page
7) Note the status is now "Item being transferred to $branch"
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Tue, 20 May 2014 14:30:02 +0000 (16:30 +0200)]
Bug 12293: Correct display for patron messaging preferences on OPAC - bootstrap
This patch is a follow-up for bug 11125, it fixes the bootstrap theme.
Test plan:
1) Remove 'sms' from message_transport_types table.
2) Go on OPAC "My messaging" tab => table columns are out of alignment with table heading.
3) Apply patch => table is correctly displayed.
Signed-off-by: Axelle Clarisse <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
With and without 'sms' existing the display of the table is now correct.
Template only change.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Owen Leonard [Mon, 9 Jun 2014 12:58:30 +0000 (08:58 -0400)]
Bug 12380 - can't tab to save buttons on add item
Many form elements on the add item page are giving a tabindex of "1" by
the script. This seems to make it impossible to tab through the add item
form fields onto the save buttons. I don't see a reason to set an
explicit tabindex of "1," so this patch removes it.
To test, apply the patch and open an item for editing. Try tabbing
through the add item form fields. It should be possible to tab through
the fields and onto the submit buttons at the bottom. Test again when
adding a new item.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12338: Remove smartmatch operator from C4/Serials.pm
This patch removes the use of the 'when' smartmatch operator from
Serials.pm
Regards
To+
Sponsored-by: Universidad Nacional de Cordoba Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jacek Ablewicz [Tue, 3 Jun 2014 07:24:23 +0000 (09:24 +0200)]
Bug 12343 - TransformKohaToMarc() is adding MARC subfields in random order
TransformKohaToMarc() function in C4/Biblio.pm iterates through it's
argument - which is a hashref - using 'each'. Perl is not guaranteed
to return hash keys in any particular order (not to mention that
in more recent perl versions, explicit hash key order randomization
is to be expected).
As a consequence:
1) For biblio records added via acquisition (order from a new/empty
record, order from a suggestion), freshly created MARC biblio records
doesn't always have 260 $b and 260 $c stored in the proper order
2) Holdings data exported for zebra indexing as 952 fields may have
subfields generated in more-or-less random order. While it probably (?)
does not affect zebra indexing/searching in any significant way,
end result is prone to be somehow ugly (which can be a potential
issue e.g. for people running Z39.50 server) and is not guaranteed
to be consistent; different records - or even different items in the
same record, can have 952 subfields generated in indiscriminate order.
This patch fixes abovementioned issues via introducting explicit
sorting (by subfiled code/letter) for subfield pairs before they
are added to the MARC record.
To test:
1/ Try to confirm and reproduce both issues (use perl 5.18.1 if possible
for more randomly ordered results).
2/ Apply patch.
3/ Redo the tests; ensure that both issues are now fixed and that there
are no apparent regressions of any kind (especially regarding to 952 fields
generated for zebra [re]indexing).
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Bug 12396 - MTT FIX: Due notices (DUEDGST) are multiplicated and all of them are sent to everybody who is about to receive ODUEDGST.
So the first patron receives correct letters, but the followings received
all the previous ones AND his letters.
Eventually you end up with !n letters in message_queue where n = amount of patrons
receiving due messages as digest and having something due.
Eventually we got 4 000 000 ODUEDGST-letters of which 1 100 000 were sent to our patrons :)
This is madness!
Test plan:
0/ Delete the content of the message_queue table.
1/ Pick 3 patrons and set them to receive due messages as digest.
2/ Check 1 item out for 3 separate patrons and specify a due date today.
3/ Launch the advance_notices.pl script.
4/ Before this patch, you got 6 notices (1+2+3 [!n]). Now, you get 3 notices, 1 for each patron.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Problem exis.
Patch work as described following test plan.
No koha-qa errors
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Galen Charlton [Wed, 28 May 2014 18:28:29 +0000 (18:28 +0000)]
Bug 11169: (follow-up) only count orders that have been placed
This patch ensures that only orders that have been placed (i.e.,
orders whose basket is closed) are counted in the OPACAcquisitionsDetails
display.
To test:
[1] Turn on OPACAcquisitionsDetails and set AcqCreateItem to 'ordering'.
[2] Create an order for a record, but do not close the basket.
[3] View the record in the OPAC. It should not display any order count.
[4] Close the bakset.
[5] View the record in the OPAC again. This time, it should display
the count of items on order.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Galen Charlton [Wed, 28 May 2014 17:45:11 +0000 (17:45 +0000)]
Bug 11169: (follow-up) add more unit tests
This patch adds direct unit tests of the new biblionumber filter
for SearchOrders. It also moves the ordernumber filter test
to the rest of the SearchOrders tests.
To test:
[1] Verify that prove -v t/db_dependent/Acquisition.t passes.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Thu, 8 May 2014 09:23:38 +0000 (11:23 +0200)]
Bug 11169: Display acquisition details in the OPAC
This patch adds a new system preference 'OPACAcquisitionDetail'.
If it is enabled, information about items on order will be displayed on
the OPAC detail page.
Test plan:
- switch on the OPACAcquisitionDetails pref.
- set the AcqCreateItems pref to 'receiving'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the "Holdings" tab contains the
line "X item are on order." (at the bottom of the table containing the
item list).
- receive the items.
- verify the number of items has decreased.
- set the AcqCreateItems pref to 'ordering'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the item list contains the items
with the "on order" status.
- receive the items.
- verify the received items no longer have the the "on order" status.
To test completely this feature, you should verify there is no
regression on the pref OpacMaxItemsToDisplay, OpacSeparateHoldings and
OpacSeparateHoldingsBranch.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Also removed some blank lines from the original patch and bumped up
the DBRev.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Mason James [Wed, 28 May 2014 01:59:20 +0000 (13:59 +1200)]
Bug 3144 - anti-spam for opac-suggestions
this patch adds a negative-captcha feature to the purchase suggestions form
some info for the curious...
http://nedbatchelder.com/text/stopbots.html
https://github.com/subwindow/negative-captcha
http://www.rubydoc.info/github/subwindow/negative-captcha/frames
to test this patch...
1/ apply patch
2/ enable 'suggestion' and 'AnonSuggestions' sysprefs
3/ attempt to add a 'purchase suggestion' in OPAC
adding the suggestion should succeed
4/ edit the koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-suggestions.tt file,
to reveal the hidden 'negcap' field
replace line 87 opac-suggestions.tt, from...
<li id="negcap" style="position: absolute; left: -2000px;">
to ...
<li id="negcap">
5/ attempt to add another suggestion, and populate the 'negcap' field
adding the suggestion should fail
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Amended patch: Remove the bug report number in the comment since git log
cans provide the same result.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Kyle M Hall [Tue, 20 May 2014 18:58:32 +0000 (14:58 -0400)]
Bug 12295: fix Javascript error when merging authorities
Attempting to merge authorities results in the following error:
Uncaught SyntaxError: Unexpected token u authorities-home.pl:284
showMergingInProgress authorities-home.pl:284
(anonymous function) authorities-home.pl:297
o jquery.js:2
p.fireWith jquery.js:2
e.extend.ready jquery.js:2
c.addEventListener.B
This was the result of the upgrade of jquery-cookie by the patch
for bug 11369; newer versions of jquery-cookie changed the return of
$.cookie('foo') from null to undefined when the cookie is not present.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No test plan, no errors.
Test
1. search some authorities
2. click merge, on browser dev console pops reported error message
'Unexpected token u authorities-home.pl...'
No way to marge auths
3. with pach applied, merging works again
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Kyle M Hall [Wed, 21 May 2014 11:14:50 +0000 (07:14 -0400)]
Bug 12025 - Inventory tool fails with "Could not reads headers", or sometimes a timeout
For libraries with large numbers of records, using a file of barcodes in
the inventory tool without selecting filters to limit the catalog
selection to compare against can result in an error of "could not read
headers" or a page timeout.
When you upload a file of barcodes, and do not specify any filters on
the rest of the form, it effectively runs GetItemsForInventory() such
that *every* item in the database is returned. On a large enough
database, this takes so long that the script times out.
The current documentation in the manual implies that if you upload a
file of barcodes, the *only* thing it does is set the date-last-seen
field. This is not entirely true; it also tries to compare the list of
scanned items to what is expected to be seen in the list of items.
The work-around for libraries with a large number of item records is to,
when uploading a file of barcodes, to also set the filters (e.g.,
library, shelving location, call number range, etc.) to
specify the range of items that the file of barcodes corresponds to.
This patch adds a warning when a librarian attempts to upload a
barcode list file for comparison without selecting any filters
to limit the catalog selection.
Test Plan:
1) Apply this patch
2) Browse to the inventory tool
3) Click the "Choose File" button, select a file
4) Click the "Submit" button
5) You should see a warning message
6) Click "Cancel"
7) Select one of more filters
8) Click the "Submit" button
9) This time the script should proceed without triggering the warning.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described following test plan.
No errors
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Viktor Sarge [Mon, 2 Jun 2014 10:07:07 +0000 (11:07 +0100)]
Bug 12336 - [SIGNED-OFF] Author of reserved book is not displayed in opac-user.pl
This patch adds a line in opac-user.pl passing author info to opac-user.tt
Thanks to cait for helping me out and showing me how to solve this with half the amount of code.
Test plan:
* Reserve a book.
* Go to the opac and log in as the patron you reserved the book for.
* Apply the patch with change to opac-user.pl
* Revisit the opac and refresh it.
* See if author now shows up
Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
Created a hold. Author is not shown n the public catalogue before
applying the patch, but it does show after applying the patch. Way
to go, Viktor!
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Thu, 22 May 2014 15:24:52 +0000 (11:24 -0400)]
Bug 12280 - "Others..." reason for suggestions not showing in Bootstrap OPAC
If you accept or reject a suggestion using the "Others..." option and
entering a reason manually, the text is not showing up in the Bootstrap
OPAC theme as it does in CCSR and prog. This patch corrects the problem.
This patch also adds a missing [% USE AuthorisedValues %] which would
cause errors if the template tried to display a custom suggestion status
as defined in the SUGGEST_STATUS authorized value category.
To test, accept or reject a suggestion and specify a custom reason. View
that suggestion in the Bootstrap OPAC and confirm that the custom reason
is displayed.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Thu, 22 May 2014 13:14:18 +0000 (09:14 -0400)]
Bug 12308 - show all title subfields on the holds list
The patron summary page in the bootstrap OPAC does not show subtitle in
the list of checkouts, overdues, or holds. This patch corrects this.
To test, set your OPAC theme to bootstrap and log in to the OPAC as a
user who has items checked out, items overdue, and items on hold. At
least one of each of those should be a title which has a subtitle as
defined in Administration -> Keyword to MARC mapping. Subtitles should
appear correctly under the "Checked out," "Overdue," and "Holds" tabs.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Pushed to master by me in my role as OPAC module maintainer
David Cook [Wed, 21 May 2014 03:22:10 +0000 (13:22 +1000)]
Bug 11014 - Slip Print Problem in Chrome
Currently, slips cannot be printed in circulation, members, or the
self check out when using Chrome.
This patch adds a timer of 1ms which allows Chrome's custom code to
prevent "window.close" occuring before the user has dealt with the
print window.
This patch also allows admins to use the 'IntranetSlipPrinterJS'
system preference to override the slip printing code by centralizing
all the slip printing code in slip-print.inc, and including this JS
anywhere it's needed in the staff client.
I haven't used this include in the OPAC SCO but perhaps it would make
sense to do so as well (even if it isn't referred to in the syspref's
name).
_TEST PLAN_
1) Using Chrome on Windows (not sure if this is an issue on other OSes),
try to print a slip in the following locations:
Fines Tab -> Print button
koha-tmpl/intranet-tmpl/prog/en/modules/members/printfeercpt.tt:
2) Note that each time you try to print, a new print page is created
but closed before you have a chance to print.
3) Apply the patch
4) Repeat Step 1
5) Note that the print page now doesn't close until after you've
chosen to print or cancel.
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 21 May 2014 11:17:54 +0000 (13:17 +0200)]
Bug 12301: Remove warnings on translate scripts
Using perl v5.18, the following is warned on updating/installing
templates:
Smartmatch is experimental at ./translate line 54.
Moreover, the following should exist with previous perl versions:
perlcritic xgettext
Subroutine prototypes used at line 29, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 44, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 60, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 72, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 89, column 1. See page 194 of PBP.
(Severity: 5)
Variable declared in conditional statement at line 105, column 13.
Declare variables outside of the condition. (Severity: 5)
Subroutine prototypes used at line 127, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 136, column 1. See page 194 of PBP.
(Severity: 5)
Variable declared in conditional statement at line 190, column 7.
Declare variables outside of the condition. (Severity: 5)
Subroutine prototypes used at line 237, column 1. See page 194 of PBP.
(Severity: 5)
Bareword file handle opened at line 238, column 5. See pages 202,204 of
PBP. (Severity: 5)
Two-argument "open" used at line 238, column 5. See page 207 of PBP.
(Severity: 5)
Subroutine prototypes used at line 277, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 311, column 1. See page 194 of PBP.
(Severity: 5)
Bareword file handle opened at line 350, column 9. See pages 202,204 of
PBP. (Severity: 5)
Two-argument "open" used at line 350, column 9. See page 207 of PBP.
(Severity: 5)
Bareword file handle opened at line 353, column 5. See pages 202,204 of
PBP. (Severity: 5)
Bareword file handle opened at line 359, column 5. See pages 202,204 of
PBP. (Severity: 5)
Two-argument "open" used at line 359, column 5. See page 207 of PBP.
(Severity: 5)
perl -wc xgettext.pl
\1 better written as $1 at TmplTokenizer.pm line 474.
main::token_negligible_p() called too early to check prototype at
xgettext.pl line 52.
xgettext.pl syntax OK
Test plan:
Apply this patch and verify the warnings/errors does not appear anymore
and no regression is found on creating/updating/installing templates.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, no koha-qa errros.
Tested with perl v5.18.2
No warnings, no problem detected on create/update/install i18n files
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Tue, 27 May 2014 08:12:20 +0000 (10:12 +0200)]
Bug 12315: fix sending of duplicate advanced notices (and sending advanced notices to wrong patron)
Bug 10833 introduced a variable loop but does not reset it every
iteration.
So the first patron receives correct letters, but the following ones
received all the previous ones as well as their own notices
Test plan:
0/ Delete the content of the message_queue table.
1/ Define advanced notices sent 2 days in advance for 2 patrons.
2/ Check 1 item out for each one and specify a due date today + 2 days.
3/ Launch the advance_notices.pl script.
4/ Before this patch, you got 3 notices. Now, you get 2 notices, 1 for
each patron.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work well, no errors.
Tested following test plan, printing on screen or saving into db,
3 messages before, 2 after (advance_notices.pl -v -n -m 2 -c)
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Galen Charlton [Mon, 26 May 2014 04:19:19 +0000 (04:19 +0000)]
Bug 6254: (follow-up) work-around to fix a failing test case
This patch ensures that a patron category that is present
in the (English) sample data is used for the ILS-DI tests,
avoiding a situation where one part of AddMember was trying
to access a patron category via DBIC but failed because
it was not visible to it yet.
Note that this will become easier once C4::Context->dbh
and DBIC are using the same base DBI database handles.
Marcel de Rooy [Mon, 12 May 2014 10:47:01 +0000 (12:47 +0200)]
Bug 11826: (follow-up) enable printing warnings
Conform former (implicit) behavior the handler now prints warnings by
default (via STDERR to logfile).
This can be adjusted by: $engine->print_warns(0);
Test plan:
Generate some error on a XSLT file (e.g. wrong path).
Check if your log contains the associated error(s)/warning(s).
Marcel de Rooy [Mon, 10 Mar 2014 12:54:36 +0000 (13:54 +0100)]
Bug 11826: Use XSLT handler object in showmarc, Record.pm
Modifies showmarc and opac-showmarc to use new XSLT handler.
Removes cardview.pl as obsolete script.
Modifies C4/Record.pm and a typo in the test Record.t.
Test plan:
[1] catalogue/showmarc: Go to Cataloging. Search. Click Card.
[2] opac-showmarc: Go to opac detail, MARC view.
Open URL for plain view in new tab.
Change URL: Change viewas=html to viewas=card
[3] Verify that there are no references in the codebase to cardview.pl
[4] C4/Record.pm: Run the Record.t test in db_dependent.
This test uses marc2modsxml, triggering the change.
Additional: export to MODS from opac-detail.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Views Ok. Test pass. No more cardview. No koha-qa errors
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Marcel de Rooy [Mon, 10 Mar 2014 09:57:33 +0000 (10:57 +0100)]
Bug 11826: Use the XSLT handler in C4/XSLT module
Incorporate the new object into C4/XSLT module.
The handler object needed one adjustment to allow for passing URLs.
Removed the GetURI function; it is no longer needed.
Added some documentation lines.
Moved a file-level lexical upwards in the code for visibility.
Removed some tabs (on two lines).
Note: The handler could perhaps be moved up to the Context module, or
be saved in a global ('our') variable. But I would rather not do that
now, making testing not too complex at this moment.
Test plan:
Enable XSLT preferences for opac and intranet.
Check result and detail pages.
Check individual list display (virtual shelves).
Force an XSLT error by editing one of your xsl files. Check the
corresponding display.
Put an URL in one the XSLT prefs (could just be to your own server).
Check the display.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Running XSLTParse4Display in a loop showed no significant performance
change.
One pass cost me around 0.012 sec (except for the first pass).
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Results, detail, url and list view Ok
No koha-qa errors
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Marcel de Rooy [Fri, 21 Feb 2014 16:21:55 +0000 (17:21 +0100)]
Bug 11826: Add unit tests for Koha::XSLT_Handler
Test plan:
Verify if XSLT_Handler.t passes.
You could also sabotage the test by removing one of the test xsl files.
Or you could 'repair' the bad xsl file (test02). Remove the second line
redefining the xsl variable.
In all those cases the unit test should fail now.. Discard your changes :)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test pass. No koha-qa errors.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Marcel de Rooy [Fri, 21 Feb 2014 16:20:29 +0000 (17:20 +0100)]
Bug 11826: Add XSLT handler object to Koha namespace
In achieving the goals of umbrella report 6536 (Z3950 improvements), this
report adds a XSLT handler object to the Koha namespace.
A follow-up adds unit tests for this module.
This patch does not yet incorporate the new object into Z3950 search. So
it does not change any behavior and is therefore harder to test.
Test plan:
Run the unit tests of the follow-up patch on report 11826.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
I tested the new module in two additional ways:
[1] Made a simple script (four lines as below) that ran a larger xml file
with 1500 records through a test XSLT file modifying the title.
my $eng= Koha::XSLT_Handler->new;
open my $fh1, '<', '_example_file';
my @xml= <$fh1>;
print $eng->transform( join('', @xml), '_example_xsl_file');
[2] Incorporated the object into my local changes of Breeding.pm (based on
older work, not ready for submittal now).
Ran transformation on Z3950 search results. Worked well :)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test runs Ok. No koha-qa errors.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Robin Sheat [Mon, 26 May 2014 01:28:00 +0000 (13:28 +1200)]
Bug 12312 - correctly upgrade under Apache 2.2
As the way we need to reference Apache instance names has now changed
between 2.2 and 2.4, we need to try it out both ways to make sure we get
it right.
This also allows koha-create/koha-disable to try the .conf version of
the name if the first one doesn't work.
To test:
* Create an instance on an Apache 2.2 system with koha < 3.16
* Upgrade to 3.16 with this patch, saying 'yes' to the renaming question
** Make sure you don't see the warning: Warning: problem enabling $site
in Apache
* Do a 'service apache2 restart'
* Make sure you can still access the instance
* Make sure that /etc/apache2/sites-enabled/instance.conf exists as a link
to /etc/apache2/sites-available/instance.conf
* Check that koha-create and koha-remove behave like you'd expect.
Note:
* If you need to make debconf forget that it asked you the question
about renaming so that it'll do it again, then run:
echo "unregister koha-common/rename-apache-vhost-files" | sudo debconf-communicate koha-common
* 'debconf-show koha-common' will show you the current debconf
configuration.
Kyle M Hall [Thu, 17 Apr 2014 11:08:55 +0000 (07:08 -0400)]
Bug 11629: (folllow-up) fix various issues
Changed the syspref.sql file to remove one of the doubled
up UNIMARCAuthrityField100 that slipped in with an earlier
patch on this bug.
Passes all tests and QA script, also t/db_dependent/Circulation_issue.t
Tested with items that had
- no notforloan value set
- notforloan value not used in updateNotforLoanStatusOnCheckin
- the notforloan value defined in UpdateNotForLoanStatusOnCheckin
Also verified it works the same, when the item was checked out or
not checked out on return.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Kyle M Hall [Tue, 28 Jan 2014 16:43:50 +0000 (11:43 -0500)]
Bug 11629 - Add ability to update not for loan status on checkin
Some libraries would like to streamline the cataloging process my
automatically updating notforloan values on checkin. For example, an
item is set to notforloan of -1 ( ordered ). The item, is received,
processed, and checked in for the first time before being shelved.
The checkin automatically changes the nfl value from -1 to 0. The
same workflow could be used for damaged items as well.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Set the new system preference UpdateNotForLoanStatusOnCheckin
to the following:
-1: 0
0: 1
4) Create an item, set its notforloan value to -1
5) Check in the item, note its not for loan value is now 0
6) Check in the item again, note its not for loan value is now 1
7) Check in the item again, note its not for loan value reamins 1
Signed-off-by: Havilah Lyon <havilah@aflibrary.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on last patch.
Galen Charlton [Mon, 26 May 2014 02:48:41 +0000 (02:48 +0000)]
Bug 7720: (follow-up) fix issues in Bootstrap theme
- Fix breakage of tablesorting when OpacLocationBranchToDisplay
is set to both.
- When displaying the home library, ensure that its correct
name and URL are displayed
- Remove the attempt to display the "opac_info" tooltip for
the home library, as it is not currently retrieved.
RM NOTE: Rather than add a GetOpacInfo function or the like
to the TT Branches plugin, simpler would be adding a
plugin function that fetches a DBIC result object for
a given branchcode, thereby allowing any column in the
branches table to be fetched into the template.
Kyle M Hall [Mon, 11 Feb 2013 14:12:07 +0000 (09:12 -0500)]
Bug 7720: add options for controlling display of an item's home and/or holdings location
Currently, in opac-detail.pl, there exists a column named 'Location'.
This column lists the name of the holding branch, and the item's
location description. This can cause confusion to borrowers, as
they may assume that the holding branch is the *owning* branch
(homebranch) of an item.
This could cause a situation where a borrower waits for an
item to be returned to his or her library, only to find that
the library never owned that item, and it was transferred back
to its homebranch. It could also lead a borrower to falsely
assume that his or her home library does not own a copy of a
particular item because the borrower does not see an his or her
home library listed for any of the items on the record.
In addition, even when the holding branch is different
than the home branch, the item's shelving location is displayed,
even though that branch may not use that location.
This commit makes the item details table equivalent to the intranet
details page by adding a "Home Library" column, which displays the
item's home library, as well as the shelving location.
If singleBranchMode is enabled, this column disappears and the
"Location" column displays the shelving location only.
This commit adds two new system preferences:
OpacLocationBranchToDisplay, which defines whether
to display the holding library, the home library,
or both for the opac details page.
OpacLocationBranchToDisplayShelving, which defines
where the shelving location should be displayed,
under the home library, the holding library, or both.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described. Tested all variations.
No koha-qa errors.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Jonathan Druart [Mon, 12 May 2014 10:31:11 +0000 (12:31 +0200)]
Bug 12230: Set a maximum suspension days as a new issuing rule
This patch adds a new issuing rule: maxsuspensiondays.
A new column "Max. suspension duration (day)" appears in the main table
of the issuing rules.
If this value is filled, on returning an item, a patron won't be
suspended longer than this cap.
Test plan:
1/ Set "suspension in days" to 2.
2/ Check an item out to a patron and specify a due date to today - 10
days.
3/ Check the item in and verify the patron is suspended until today + 10
* 2 days.
4/ Remove the suspension.
5/ Set "Max. suspension duration" to 10.
6/ Check an item out to a patron and specify a due date to today - 10
days.
7/ Check the item in and verify the patron is suspended until today + 10
days.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Kyle M Hall [Thu, 5 Dec 2013 12:35:00 +0000 (07:35 -0500)]
Bug 6254: make it possible to set default privacy setting for new patrons
There is currently no way to set the privacy setting for newly created
patrons. This patch adds a new field "default privacy" to the patron
categories such that each patron category may have a different default
privacy setting.
Test Plan:
1) Apply this patch
2) Edit a patron category, change the default privacy to "forever"
3) Create a new patron of that category
4) Log into the catalog as that patron, verify the privacy setting
is set to "forever"
5) Repeat steps 2-4 with the settings "never" and "default"
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Bug 6254 [QA Followup 1] - can't set patron privacy by default
* Adds default privacy column to summary table
* Adds default privacy to delete category summary
* Adds "AFTER categorycode" to the database update
* Whitespace cleanup and formatting for affected code blocks
* Switch basic DBI queries to DBIx::Class to simplify code
* Adds reference to misc/cronjobs/batch_anonymise.pl to description
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Bug 6254 [QA Followup 2] - can't set patron privacy by default
Jonathan Druart [Tue, 14 Jan 2014 08:38:32 +0000 (09:38 +0100)]
Bug 7825: (follow-up) fix the force value for the bootstrap theme
If the pref was set to 'force', the item selection was not shown.
.copiesrow should be hidden before showing specific #copiesrow_ID
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Works on template level, tested with Boostrap and Prog theme
with all 3 possible seetings of OPACItemHolds:
1) no = offer only title level holds
2) yes = offer both title and item level holds
3) force = offer only item level holds
Also ran some additional tests on the Boostrap theme with
deactivated Javascript.
Note: I like this, but I think when "force" is selected the
item list needs to be shown by default. I am also not happy about
preselecting the first item.
Jonathan Druart [Mon, 13 Jan 2014 08:41:22 +0000 (09:41 +0100)]
Bug 7825: (follow-up) clarify the yes and no values
The value of the pref should be '1' (for yes) or '0' (for no).
The options could be kept as 'yes' and 'no': since the ImplicitTyping is
set, yes/no would become '1/0'. But I think it is preferable not to use
the yes/no value in order not to introduce a bug here if ImplicitTyping
is unset later.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Jonathan Druart [Mon, 26 Mar 2012 08:34:34 +0000 (21:34 +1300)]
Bug 7825: Changed OPACItemHolds syspref to be no|yes|force choice
Currently, the Koha system preference OPACItemHolds allows a library
system to choose to allow patrons to place bib and item level holds from
the OPAC, or to allow patrons only to place bib level holds only from
the OPAC.
This patch set adds a third option, "force", which *requires* that
patrons place item level holds from the opac, with no option of making a
bib level hold.
This patch modifies the system preference OPACItemHolds to be of the
type "Choice", with the choices being "no", "yes", "force". The patch
does not alter the currently set value of OPACItemHolds for database
updates, only adding the additional option.
Test Plan:
1) Set OPACItemHolds to "no". Check that OPAC holds behave as it is now
(no "Place On" column, no "Select a specific copy" table, making a
reserve is successful)
2) Set OPACItemHolds to "yes". Check that OPAC holds behave as it is now
( "Place On" column is there, "Select a specific copy" table shows when
"A specific copy" is selected, making a reserve is successful)
3) Set OPACItemHolds to "force". Check that OPAC holds behave as follows:
- no "Place On" column is present
- "Select a specific copy" table is opened
- making a reserve is successful
This patch is a squashed patch of the 3 following patches:
Amended opac-reserve.tt accordingly
Signed-off-by: Delaye Stephane <stephane.delaye@biblibre.com>
Bug 7825: Followup prevent submission without choosing an item
+ Fix some ergonomic issues in opac-reserve
Signed-off-by: Delaye Stephane <stephane.delaye@biblibre.com>
Bug 7825: Updatedatabase should only change the type and options values.
The value field should not be changed. We have to keep '1' for 'yes' and ''
for 'no'.
Original patch is from Srdjan Jankovic.
Signed-off-by: Koha team AMU <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on 4th patch.
Robin Sheat [Tue, 29 Apr 2014 06:17:59 +0000 (18:17 +1200)]
Bug 8970 - fix MARC import under plack
There were database handles being shared between a parent and a child
process, which is a big no-no, and was leading to crazy crashes. Fine
under CGI, but not in a persistent environment. This causes the child to
make a new database handle to use. Also some small cleanups.
To test:
* In a plack environment,
* Tools -> stage MARC records for import
* Use a reasonable size file (but not too big as it all goes into RAM -
I made one about 40MB.)
* Make sure that it works, and that the progress bars progress.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Tested with a 55M file, I reproduced the error and I confirm this patch
fixes it.
Jacek Ablewicz [Fri, 9 May 2014 09:30:28 +0000 (11:30 +0200)]
Bug 3050 - Add an option to upload scanned invoices #1/3
(part #1: new module w/ UT + script + template)
New feature, adds an ability to attach arbitrary files to
acquisition records (currently: to the invoices - but it can
be extended to baskets, basketgroups, budgets etc.).
Note: this code is (heavily) based on "Bug 8130 - attach PDF
files to a patron record" by Kale M Hall, main difference being
that new table (misc_files) and new module (Koha/Misc/Files.pm)
are intended to be a little more generic solution - they allow to
store and manage files associated with great many kinds of records,
from arbitrary tables.
Test plan:
1) Apply patch[es]
2) Run installer/data/mysql/updatedatabase.pl
3) Enable system preference 'AcqEnableFiles' in acquisition
4) New option 'Manage invoice files' appears in the invoice
detail page
5) Upload/view/download/delete some files for some invoices
6) Try to delete invoice with files attached (files should
get deleted as well)
7) Try to merge 2+ invoices with files attached; after merge,
all files previously attached to individual invoices being
merged should be attached to resulting invoice (merge destination)
8) prove t/db_dependent/Koha_Misc_Files.t
9) Ensure there are no regressions of any kind in invoice detail
page (acqui/invoice.pl).
Mathieu Saby [Sun, 18 May 2014 19:30:53 +0000 (21:30 +0200)]
Bug 12110: (follow-up) add French and German translation
This followup
- translates "vendor note" in French and German.
- replaces "Notes for vendor" with "Note for vendor" in English template
(as there can only be 1 note)
- fixes a typo in French template (Qte => Qté, for "Quantité")
Test plan :
[1] set OrderPdfFormat preference to "French 3-pages"
[2] Print a basketgroup containing an order with a vendornote, and check
the note is displayed and introduced by "Notes pour le fournisseur"
[3] set OrderPdfFormat preference to "German 2-pages"
[4] Print a basketgroup containing an order with a vendornote, and check
the note is displayed and introduced by "Lieferantennotiz"
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12110: Display the order vendor note in basket and basketgroup CSV and PDF
This bug adds the "vendor note" for each order in the PDF for
basketgroups. The note is displayed only if it exists, just under the
bibliographic information.
I added a separation line "--------" between bibliographic information
and the note, so that it could be visible at 1st glance.
It also replaces the internal note with the vendor in the CSV for basket
and basketgroup. It is more logical and useful for libraries to export
the note made for vendor, as those files are destined to be sent to the
vendor.
Test plan :
- fill a basket with some orders, some with internal notes, some with
vendor notes
- export the basket in CSV : only the vendor notes should be present
- put the basket in a basketgroup
- export the basketgroup in CSV : only the vendor notes should be
present
- Select "English-2 pages" template for basketgroups in Sysprefs
- export the basket in PDF : the vendor notes should be present under
the bibliographic information
- Select "English-3 pages" template for basketgroups in Sysprefs
- export the basket in PDF : the vendor notes should be present under
the bibliographic information
Bug 9088: if there is only one active order, pre-select it when creating new orderings
This patch makes the following changes to the template:
[1] If you add an order line, and you have one active fund (and zero or
more inactive funds), the only active fund is preselected.
[2] If you modify an order line while its fund is inactive, it now shows
the label (inactive) behind the fund name. (Note that other inactive funds
may come up when clicking 'Show all' as they did before.)
[3] Corrected some indentation in this template part.
Test plan:
[1] Add an order line while having one active fund. Is it selected?
[2] Add an order line while having two or more active funds. No fund
should be preselected.
[3] Modify an order line with an active fund. Is it still selected?
[4] Modify an order line with an inactive fund F2 (while having one active
fund F1; note that this test explicitly wants F1 to be before F2).
Check if F2 is selected and is labeled inactive.
[5] (Bonus points:) Modify an order line that refers to a deleted fund.
If you edit this order, the fund combo should say: Select a fund.
(Note: if you delete a fund, the budget_id in aqorders remains.)
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
I test against master 3.15.00.051
I test against all the three options of the AcqCreateItem:
placing an order
receiving an order
cataloging the record
All is OK.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
projects / koha.git / log