The QA follow-up which adds GetURL to the TT branches
plugin means that GetItemsInfo no longer needs to be changed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
[1] Fix capitalization
[2] Move logic for getting the home library name URL to the
Branches TT plugin
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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>
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>
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
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Bug 6254: QA FIX: remove trailing whitespaces
This patch removes trailing whitespaces/tab and fix the fields order in
the updatedb entry (according to the kohastructure.pl).
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Retested with all 3 themes, works as expected.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch changes the default behavior for the 'force' value.
If the pref is set to force, no item is preselected and the item list is
shown.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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>
Same test plan as previous patch but with the bootstrap theme set.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
1/ Use the usual way for ordering dates in table
2/ Add a confirmation dialog box on deleting a file
3/ Add some UTs
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(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).
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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>
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
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
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>
The MARC export tool now includes the option to specify a file
containing record IDs to export. When run on the command line,
this is specified using the --id_list_file switch.
Note that the list of IDs acts as a filter on other criteria
for selecting records to import. For example, if you export
all bibs belong to a given library and also specify an ID file,
the bibs must both belong to the library and be in the ID file.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No errors
Tested writing txt file with biblionumbers, loading in tools and exporting
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test:
1. Edit a bib record, add 100.000 chars text to 500a
2. Go to Tools -> Export data (or run tools/export.pl on
the command line)
3. Verify that exporting as XML includes the record
4. Verify that exporting as MARC does not include the record,
and that you get the following warning:
export.pl: record (number 2025) length 102668 is larger than the MARC spec allows (99999 bytes) at...
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This piece of TT code:
[% SWITCH lang %]
[% CASE ['en', 'eng'] %]English
[% CASE ['fr', 'fre'] %]French
[% CASE ['it', 'ita'] %]Italian
...
[% CASE %][% lang %]
[% END %]
is parsed by the TTparser.pm wrong. In the po-files, it shows up as:
...
All the "CASE [ ... ]" codes are shown as "ERROR".
This happens if any TT statement contains a ']' in it - the TTParser
looks for anything that starts with [% and ends with ].
This patch fixes it so that it expects TT directives to end
with '%]'.
To test:
1) cd misc/translator/
2) perl translate update xx-YY
3) for x in po/xx-YY-*.po; do cp "$x" "${x/.po/.po.bak}"; done
4) apply patch
5) perl translate update xx-YY
6) for x in po/xx-YY-*.po; do diff -Nurd "$x" "${x/.po/.po.bak}"; done
the only changed lines should be those that apply to msgid's with
ERROR-parameters.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No errors
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In the two FOREACH loops introduced by the patch, wrap
the module and action names with quotes. This fixes a
problem where parsing the template crashes with the following
error:
Template process failed: file error - parse error - .../viewlog.tt line 83: unexpected token (RETURN)
[% FOREACH actx IN [ ADD DELETE MODIFY ISSUE RETURN CREATE ] %] at .../C4/Templates.pm line 132.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When viewing the logs, the user can see module and action,
such as "SYSTEMPREFERENCE", "MEMBERS" or "CREATE", "MODIFY", etc.
These texts are not translatable.
This patch allows translating those. It also adds the missing "CREATE"
action to the pulldown.
To test:
1) Go browse the system logs. Note the contents of the "Action" and
"Module" -pulldowns, and the contents of those columns in the log table.
2) Apply patch
3) Go browse the system logs again. The pull-downs should work, and
show the same values as before (plus "Create" for Action), and the
Action and Module -columns in the log table should not be in ALL CAPS.
4) cd misc/translator
5) perl translate update xx-YY
6) Check that the po/xx-YY-i-staff-t-prog-v-3006000.po contains the
values for the pull-downs in it. (Look for eg. "System prefs")
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Trim leading and trailing whitespace in the text generated
by the translate_card_element block to avoid generating
unescaped multi-line strings, which breaks the JavaScript
To test:
[1] Test actions in the patron card creator that generate
JavaScript alerts, such as hitting the delete button
without first selecting a batch or profile.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
1) cd misc/translator
2) perl translate update xx-YY
3) check that there's no msgid that contains the patron card label
element title texts in po/xx-YY-i-staff-t-prog-v-3006000.po
4) apply patch
5) perl translate update xx-YY
6) check po/xx-YY-i-staff-t-prog-v-3006000.po that it contains the
msgid. (search for "BLOCK translate_card_element")
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. Tested updating po file, translating and installing
language, checked on tools page.
No errors
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Also removes a commented line that changed the value of $confirm.
If it would default to 1, we do not need it at all.
I am not saying that we need it, but just documenting that we have it.
Signed-off-by: Marc Véron <veron@veron.ch>
Small change in documentation.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The code introduced by bug 2546 uses an undefined variable (line.title).
It should be ACCOUNT_LINE.title.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
1) Create an account with lots of different charges, fines, fees, etc.
2) Look at the accounts tab in the prog OPAC theme
3) Compare the page to bootstrap theme
4) Verify display is now the same
In my tests I found some things that could still be improved,
but for the goal is to make all OPAC themes behave the same.
Signed-off-by: Marc Véron <veron@veron.ch>
Tested by changing accounttype in table accountlines to all possible
values like Pay, Pay00, Pay01 etc. Both themes display the same values,
e.g. "Payment, thanks (cash via SIP2)" for Pay00
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Prior to this patch, the column for displaying the action links
was too narrow, leading to an ugly display. This patch groups
"action" links into a menu as was done with Bug 11763.
This patch also converts the date column sorting configuration to use
header class instead of an index.
This patch also corrects a couple of HTML markup errors: An
improperly-closed <input> and an improperly closed <option>.
To test, view the invoices page and confirm that the "Actions" menu
button works corectly. Test the functionality of each menu options:
Details, Close, Reopen, and Delete. Confirm that sorting by billing date
still works correctly.
Much nicer user interface. Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
$ git grep authoritysep
This showed:
1) the updatedatabase.pl script, as expected,
2) lots of po files,
3) a test file that was missed.
TEST PLAN
---------
1) prove -v t/db_dependent/Search.t
2) Run koha QA test tools
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work (both patches). Test pass. No koha-qa errors
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test Plan:
1) Apply patch
2) Run updatedatabase.pl
3) View some records with authorities
4) Note your previously set authority separator should still be in use
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No koha-qa errors.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
