Bug 11912: (refactoring followup) make GetMarcISBN implement its advertised API
The current implementation of GetMarcISBN contradicts the documented API.
It currently returns an array of hashes with only one key (marcisbn)
which doesn't add any value to it.
I chose to fix GetMarcISBN to honour the API instead of changing thex
docs, because it seems a really silly change.
To test:
- Run:
prove t/db_dependent/Biblio.t
=> SUCCESS
- catalogue/detail.pl should correctly show ISBNs.
- opac/opac-detail.pl should correctly show ISBNs in both prog and bootstrap.
- opac-opac-sendshelf.pl should correctly show ISBNs in the email.
Sponsored-by: Universidad Nacional de Cordoba Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 11912: fix problem where GetMarcISBN wrongly prepends a space to ISBNs
This patch makes the logic inside GetMarcISBN simpler and
fixes the issue.
To test:
- Run the regression tests:
prove -v t/db_dependent/Biblio.t
=> FAIL
- Apply the patch
- Run:
prove -v t/db_dependent/Biblio.t
=> SUCCESS
- Verify that opac-detail.pl and catalogue/detail.pl look as usual regarding ISBN
- Sign off
Sponsored-by: Universidad Nacional de Cordoba Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
blou [Wed, 2 Oct 2013 19:05:38 +0000 (15:05 -0400)]
Bug 10986: add system preference to limit the list of languages in advanced search
In Advanced Search, the list of available language is long and will only
get longer. For a library offering books in 2-3 languages, that is
offering too many options to the user (most of the small libraries we
deal with only offer documents in two languages).
Code changes:
Languages.pm: Extract getAllLanguages to make a more customizable
getLanguages (have getAllLanguage call it, so rest of codebase is
oblivious to the change). Build array returned based on system pref if
corresponding argument is set.
search.pl and opac-search.pl: call getLanguages instead of
getAllLanguages.
TESTING
0) All language codes are iso 639-2 (three characters)
1) in OPAC, Advanced search, open Language box, acknowledge 30+ items.
2) in Intranet, go to system preferences AdvancedSearchLanguages,
enter "ita|eng"
3) back in OPAC, refresh screen, acknowledge only Italian and English
are listed.
4) in Intranet, click Search then click "More options" to make the
Language box appear. Acknowledge limited options.
5) Regression Test: Back to the preference, empty the field then save.
Go back to the OPAC and Intranet search, refresh the page, then the
Language drop-box will now contain 30+ items.
Bug 10951: (follow-up) use Koha.Preference() template function
This patch uses the TT helper function Koha.Preference() to
retrieve the value of NoLoginInstructions rather than passing
it to all templates as a template variable.
blou [Fri, 4 Oct 2013 17:25:33 +0000 (13:25 -0400)]
Bug 10951 - Adding NoLoginInstructions to system preferences
On a failed login, the default message is harcorded into opac-auth.tt.
It would be preferable to allow for a preference to override that message (for example: ...Please bring an ID to t
The changes modify
-opac-auth.tt to allow for custom value
-admin/preferences/opac.pref to add it to the preferences with a description
-C4/Auth.pm for the loading of the preference
-sysprefs.sql
-updatedatabase.pl
TESTING
1) in OPAC, logged out, try login in by entering no or wrong credentials. Acknowledge the "Don't have a p
2) Apply the patch
3) Regression Test: Redo step 1. Same (default) message should appear.
4) Log in to intranet,
- select NoLoginInstructions in system preferences.
- Enter new (xml) message. Possible:
<h5>Welcome to Koha, please bring your passport to the front office</h5>
- and save
5) refresh the OPAC, try login again with invalid credentials. The new message should appear.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Jonathan Druart [Thu, 9 Jan 2014 16:53:04 +0000 (17:53 +0100)]
Bug 11489: (OPAC prog theme) show facets only if there is a result to display
If all results are hidden, the facets are displayed.
With this patch, the facets are hidden too.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Michot <nmichot@voila.fr> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script. Tested:
- Record with 1 lost item, result list = 1
- Verified without both patches 404 error page is shown
- Verified with 1st patch, no results page is shown
- Verified with 2nd patch, the still showing facets are gone
- Record with 1 lost item, result list > 1
- Record is hidden from result list, but
- result count is wrong
- result numbering is wrong
> This is an old problem, just noting
- Record with 1 lost and 1 available item, result list = 1
- Detail page is shown, only lost item is hidden
- Record with 1 lost and 1 available item, result list > 1
- Only available item is shown in result list
Also checked that the lost item shows up with hidelostitems off.
Kyle M Hall [Tue, 7 Jan 2014 17:19:37 +0000 (10:19 -0700)]
Bug 11489: in OPAC search, display "no results" when the only search result is suppressed
If hidelostitems is enabled, and the result of an opac search is a single
lost item, then the OPAC will display a 404 error, rather than a
"no results" screen.
Test Plan:
1) Catalog a record/item such that it is the only result for some search
e.g. Give it the title 'zxcvb'
2) Enable hidelostitems
3) Mark this item as lost
4) Perform an OPAC search that should result in a redirect to this record
5) Notice you a redirected to a 404 error
6) Apply this patch
7) Repeat step 4
8) Note you new get a "No results found!" page instead
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org> Signed-off-by: Michot <nmichot@voila.fr> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 9416: (follow-up) reconcile with work done on bug 11699
This patch teaches the ordering receiving process how to
set vendor and internal order notes.
One observation: I'm not sure it's entirely useful to set
a note to communicate to the vendor during receiving --
how is it to be sent to them, and why?
Bug 9416: (follow-up) fix neworderempty and templates
This followup answer QA remarks :
- neworderempty.pl updated so that the 2 new variables are passed
to the template
- modordernotes.tt fixed to make the translation easier
- in CSV headers, to make clear that no change are made for the moment,
rename "note" to "internal note"
Additionnaly, "Publisher code" was wrong in the csv headers. I changed
it to "Publisher" (the field in database is publishercode, but the
content is a real publisher name, not a code)
I did not change "Note:" in modordernotes.tt, because it is just under
a h1 tag which specifies the type of note the librarian is editing.
Test plan :
- edit an existing order, and try to change/add/delete the vendor note,
and the internal note. Check the changes are properly saved
- export a basket and a basketgroup in CSV. Check the columns headers
are "Publisher" and "Vendor note"
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed some tabs. Passes QA script and tests.
Tested:
- add notes when creating an order
- edit notes modifying an order line
- edit notes using the links on the basket summary
- check basket CSV export
- close basket
- check basket group CSV export
- edit notes on order receive page using the links
- edit notes on receive
Note: Translatability of templates could be improved by a follow-up.
It's better not to divide up sentences with if/else structures.
Mathieu Saby [Mon, 17 Feb 2014 00:11:42 +0000 (01:11 +0100)]
Bug 9416: add new order vendor note field
Currently, there is a single note field in each order. It would be
useful to have 2 notes fields:
- one for the staff (ex: "catalog this book as soon as possible")
- one for the vendor (ex: "urgent", "only the 2d volume"...), which
could later be printed in basketgroup pdf for example
This patch adds a new note made for vendor in each order. The existing
note is renamed "internal note".
The behavior of the 2 notes are the same
Changes in database structure:
- new column aqorders.order_vendornote
- column aqorders.notes renamed aqorders.order_internalnote
To test :
[1] Make a complete acquisiton process (creating the order > looking at
the basket > looking the order > receiving); and try to use the 2
notes (internal note / vendor note)
[2] Check the changes made on one page (eg detail of the order) are
saved and visible on an other page (eg receipt page)
Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on last patch.
Jonathan Druart [Wed, 5 Mar 2014 12:07:53 +0000 (13:07 +0100)]
Bug 11699: fixed saving notes entered when receiving orders
Revised test plan:
1/ Create an order with 2 items
2/ Receive 1 item and enter a note for the order
3/ Verify the note is not saved
The note should be visible on the Mod Order Details screen,
but it isn't there.
4/ Apply patch
5/ Receive the second item and enter a note for the order
6/ Verify the note is correctly saved
The note is visible on the Mod Order Details screen.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Works as described. The note now saves correctly and also remains when
you undo a receipt.
Note: it would be nice to show the note on the receive page as well. Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This relevance sets title as phrase in priority and then any index.
This patch adds title as words list before search on any index, so
that records with all searched terms in title, even not well ordered,
are more relevant.
Test plan :
- Enable QueryWeightFields syspref
- Perform a search, with sort by relevance, with two words ofen
contained in title, but never one near the other.
For example: 'History France'
=> Records with both words in title are first. For example:
"Histoire de France" and "La France : 100 ans d'histoire"
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Relevance ranking and field weighting are hard to test,
as many MARC fields are indexed into the used indexes.
If we had an index that only indexed 245$a/200$a the
effect might be more visible.
I found no regressions by this patch, change reads
logical.
Bug 11508: fix untranslatable pull-down in auth_subfields_structure.pl
This patch replaces occurrences of CGI::scrolling_list with
untranslatable labels. It also fixes capitalization.
To test
1. Go to Administration > Authority types,
click 'MARC structure' of any auth type,
click 'subfields' for any Tag >= 010,
clic 'Edit subfields'
Check pulldowns 'Managed in tab' and 'Select to display or not'
2. Apply the patch
3. Reload and verify functionality of both pulldowns
4. Check that strings are not present on staff PO file
egrep "^msgid \"(Show all|Hide all|ignore)" misc/translator/po/fi-FI-i-staff-t-prog-v-3006000.po
5. Update language file
(cd misc/translator/; perl translate update fi-FI)
6. Check that strings are now present, repeat 4.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: drop-downs work identically. Show all, Hide all, and
ignore were added to the po files too.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Works as described and improves the page to manage authority
subfields.
Jonathan Druart [Tue, 29 Oct 2013 14:03:41 +0000 (15:03 +0100)]
Bug 9216: make columns.def file translatable
The SQL column headers is stored into the columns.def file.
This file is not managed by the translation script.
This patch makes possible the headers translation.
Note: The translation xml tags were added to avoid all lines being put
on a single line.
Test plan:
1/ update your po file
cd misc/translate;
perl translate -f columns update LANG # Replace by another language here
2/ translate header columns (search "columns.def" in your po file).
3/ install the translated columns.def
perl translate -f columns install LANG # Replace by another language here
4/ go on the report module > create a new report > next > next
5/ change the language
on the 3rd step, you should see the column header translated.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, no koha-qa errors
[on es-ES about a third of the strings translated!! :-) ]
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and fixes a long standing translation
problem.
Passes all tests and QA script.
Francesca Moore [Tue, 14 Jan 2014 23:03:51 +0000 (12:03 +1300)]
Bug 11231: remove reference to ambiguous notes column from two hold request reports
The 'notes' column has been removed from the pending holds and hold
ratios reports as they were not displaying in the first place.
1.apply patch
2.verify that both reports work
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Fridolyn SOMERS [Fri, 22 Nov 2013 10:00:21 +0000 (11:00 +0100)]
Bug 9578: avoid a search crash when attempting to sort results of invalid query
When searching with a sort (means not by relevance) and there is an error
in Zebra connexion (server is down or query is wrong), you get the message :
Error : Can't call method "sort" on an undefined value at /home/kohaadmin/src/C4/Search.pm line 405.
This patch corrects by not performing sort if there are no no results.
Steps to reproduce the error without patch:
In OPAC go to Advanced Search
Choose "Title" in first "Search for:" end enter "ccl=( and )"
Display "More options"
Set "Sort by" to "Title (A-Z)"
Click "Search" at bootom of page
Result:
Error:
Can't call method "sort" on an undefined value at /usr/share/kohaclone/C4/Search.pm line 430.
After applying the patch, try that search again. This time,
it should report not results found with out the error message.
Alternative Test plan :
- Set OPACdefaultSortField on something else than relevance
- Perform a simple search with a wrong CCL query. For example : ccl=( and )
=> You get the messge : No results found ...
Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Adds another check to prevent a bad Zebra error message.
Works as described, passes all tests and QA script.
This patch adds a regression test for the condition noted
in bug 9578, where attempting a sort of a Zebra search that
fails because of an invalid query crashes.
Jacek Ablewicz [Mon, 10 Feb 2014 09:09:21 +0000 (10:09 +0100)]
Bug 11680: (follow-up) fix unexpected tax rate changes on edit
Follow-up to fix similar issue on vendor edit.
If the tax rates in Acquisitions -> gist system preference
are entered with trailing zeroes, given vendor tax rate value
may not be correctly handled on vendor edit.
Test plan for this follow-up:
1) insert some tax rates with trailing zeroes in gist
system preference (e.g: '0|0.080|0.12|0.20|0.23')
2) add some vendors, choosing 8.0% 12.0% 20.0% 23.0%
as gst rate
3) try to modify them
4) note that vendors with 12.0% and 23.0% tax rates are
preserving previously choosen rates on edit, while
the ones with 8.0% and 20.0% do not (they are defaulting
to the first defined tax rate)
5) apply the patch
6) repeat 2) and 3)
7) all tax rates configured in system prefrence shall now
behave properly while editing vendors
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Jacek Ablewicz [Wed, 5 Feb 2014 10:16:14 +0000 (11:16 +0100)]
Bug 11680: fix case where tax rate changes unexpectedly on editing an order
If the tax rates in Acquisitions -> gist system preference are entered
with trailing zeroes, given order tax rate value may not be correctly
handled on order edit.
To test:
1) insert some tax rates with trailing zeroes in gist
system preference (e.g: '0|0.080|0.12|0.20|0.23')
2) place some new orders, choosing 8.0% 12.0% 20.0% 23.0%
as gst rate
3) try to modify them
4) note that orders with 12.0% and 23.0% tax rates are
preserving previously choosen rates on edit, while
the ones with 8.0% and 20.0% do not (they are defaulting
to the first defined tax rate)
5) apply the patch
6) repeat 2) and 3)
7) all tax rates configured in system prefrence shall now
behave properly while editing orders
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
All tests pass
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Confirmed the problem and that this patch fixes it.
Problem also exists for editing the default tax rate of a vendor.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Jonathan Druart [Thu, 4 Apr 2013 10:09:37 +0000 (12:09 +0200)]
Bug 10090: display item type description instead of code on acq ordered and spent pages
On ordered.pl and spent.pl, the itemtype codes are displayed, instead of
descriptions.
Links for the ordernumber should be changed. In ordered.pl, we are
redirected to the receive page. In spent.pl, the links are deleted.
Signed-off-by: Broust <jean-manuel.broust@gmail.com>
Revisited patch: The link to orderreceive was broken, so I undo the
changes.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works alright, itemtype descriptions are shown.
The removed link was potentially 'dangerous' as you shouldn't
get to the receive page for an order, without providing an invoicenumber
first.
Passes all tests and QA script.
Jacek Ablewicz [Mon, 10 Mar 2014 09:53:52 +0000 (10:53 +0100)]
Bug 11914: fix two issues when creating an order from a suggestion
When order is being created from purchase suggestion:
- Budget/fund stored in suggestion record (if any) is not retained
on order page, system always defaults to 'Select a fund' even if some
fund was already chosen for a suggestion on the earlier stage.
- If there was a price given to, and stored within suggestion record,
initial prices calculations on order page are not working properly
('Replacement cost', 'Budgeted cost' and 'Total' show as 0.00 or blank).
As a workaround - to force correct price recalculation - user needs
to manually alter and then re-alter some price-related fields (e.g.,
quantity or vendor price).
This patch fixes both issues.
Test plan:
1) create a suggestion: choose some buget, enter something in 'Price'
and 'Quantity' fields,
2) try to make an order from this suggestion, to confirm/replicate
aforementioned problems,
3) apply patch,
4) make an order from previously created suggestion again, observe
that both issues are now resolved.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests and QA script.
Jonathan Druart [Mon, 28 Oct 2013 14:10:26 +0000 (15:10 +0100)]
Bug 11148: remove two superflous routines from Koha::DateUtils
There are 2 useless routines in the Koha::DateUtils
module:output_pref_due and format_sqlduedatetime. We can call
output_pref and format_datetime with dateonly = 0.
format_sqlduedatetime is only used in one place: opac-reserve.pl
Test plan:
1/ Verify on the opac-reserve.pl page that the date is correctly
displayed for for onloan items (you should use the "specific copy"
feature).
2/ Launch prove t/DateUtils.t UT file and verify all UT pass.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Due date on opac-reserve shown correctly. Unit tests pass.
Did a grep on both function names.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
No references to subs found. Passes koha-qa.pl, t and xt
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Kyle M Hall [Wed, 18 Dec 2013 13:37:40 +0000 (08:37 -0500)]
Bug 11416: fix case where serials item editor was incorrectly hiding fields
In serials/serials-edit.pl, if an item field is hidden from the OPAC,
it will not display in the editor, even if the field is marked as
visible in the staff intranet and editor. However, the field is still
displayed correctly in the items editor ( additem.pl ).:
Test Plan:
1) Select an item-level field ( e.g. non-public note )
2) Create a serial using the default framework ( or one of your choice )
3) For that framework, mark the chosen field as visible from the
intranet and editor, but not the opac.
4) Receive an item for this serial, note your field does not display
5) Use the biblio item editor to add an item ( additem.pl ), not the
field displayes
6) Apply this patch
7) Repeat step 4, not the field displayes
Signed-off-by: Kim Schwant <kim.schwant@courts.in.gov> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
PrepareItemrecordDisplay is only used for editor (-4 < hidden < 4)
Blou [Wed, 12 Feb 2014 17:03:08 +0000 (12:03 -0500)]
Bug 11752: display the correct frequency for serial subscriptions in OPAC details
This fixes bootstrap and prog by modifying the description displayed
in the OPAC's detail of serials.
RM NOTE: this patch does not cover the case where custom serial
frequencies have been defined.
TESTING to reproduce
- create/find a serial with a 1/week periodicity (4 in the database)
- Find it in the opac-detail.pl, click "more details" at the bottom
- validate the string. Before the patch, it will say:
"The current subscription began on 2013-12-06 and is issued every 3
weeks for 26 issues"
The "every 3 weeks" is clearly wrong.
In fact any periodicity chosen would display a wrong description, not
matching the staff interface.
After the patch, the display is corrected.
As a bonus, the "every 2 years" now has a description, where it had
none before.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Jonathan Druart [Wed, 5 Feb 2014 10:05:19 +0000 (11:05 +0100)]
Bug 11689: Take new serial missing statuses into account in more places
Bug 10851 introduced new missing status (codes 41,42,43,44), but in
GetSerials and _update_missinglist, they are not taken into account.
This patch corrects the issue.
To reproduce:
1/ Create a serial with 10 issues.
2/ Set different statuses on each one, with at least 6 missing statuses
(not only "Missing").
3/ Go on the subscription detail page, tab "Summary", the issues with a
new missing status are not listed in the missing issues list.
4/ On the "Issues" tab, all missing are listed (normally only 5 should
be listed.
5/ Apply the patch.
6/ Edit serial (to rewrite the missing list).
6/ Verify that steps 3 and 4 have now correct behavior.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes QA script and tests.
Julian Maurice [Fri, 28 Mar 2014 13:38:25 +0000 (14:38 +0100)]
Bug 12003: Do not calculate next pubdate for irregular subscriptions
Show 'Unknown' when planneddate and publisheddate cannot be calculated
Also fixes SQL query in misc/cronjobs/serialsUpdate.pl that was still
using "periodicity != 32" to exclude irregular subscriptions from
results
Test plan:
1) Create a subscription in the serials module. Make sure to choose:
Frequency = Irregular
2) Test the prediction pattern, first publication date is set to
"First issue publication date" field, others will show as
'unknown'
3) Save the subscription
4) Check the created issue - it will show a published date and a
planned date (same as "First issue publication date" field)
5) Receive the issue and check the next generated issue, planned
date and published date should show as 'Unknown'
6) Generate a next issue, planned date and published date should
also show as 'Unknown'
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described following test plan.
No koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Also tested:
- multi receiving generates mulitple issues without dates - 'unknown'
- staff detail page shows the dates empty, which is fine
- OPAC detail page shows the dates empty, which is fine
- serial collection page shows 'unknown' and those issues appear
on the 'manage' tab, as they did in the past
- Editing the issue from the serial collection page leaves the
date fields empty.
- Receving the issue, setting the status to 'Arrived' the Expected on
date is set to 'today' automatically. Date published has to be
entered manually (maybe something we could improve later
- subscription detail > issues tab shows Uknown.
- t/db_dependent/Serials/GetNextDate.t pass.
Bug 12098: (follow-up) put can_show_subscription() into use
This patch puts C4::Serials::can_show_subscription() into use.
Note that there is user-visible change: if a subscription has a
blank library, all users with serials permissions will be able
to view and/or edit it. It remains to be determined whether
we *want* such subscriptions to exist, or if they should only
be tied to specific libraries.
Jonathan Druart [Wed, 16 Apr 2014 14:58:36 +0000 (16:58 +0200)]
Bug 12098: Refactor can_*_subscription in C4::Serials
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested on top of patches for 12048 and 12080.
Subscription search
- superlibrarian, IndyBranches on/off - always sees all subscriptions
- superserials, IndyBranches on/off - always sees all subscriptions
- no superserials, IndyBranches on - only sees own subscriptions
Note: Subscriptions without branches will only show, when all subscriptions
are visible. In a future enh it might be good to enforce setting a
branch, when IndyBranches is used.
- no superserials, IndyBranches off - always sees all subscriptions
Subscription editing
- superlibrarian, IndyBranches on/off - can edit all subscriptions
- superserials, IndyBranches on/off - can edit all subscriptions
- no superserials, IndyBranches on - can only edit own subscriptons and
subscriptions without branch
NOTE: it would make sense to also allow Edit > Edit as new (duplicate)
here, so one can copy the subscription from another branch to modify
it for the own branch.
Passes tests in t, xt and QA script, also newly provided unit tests.
Bug 12080: restore effect of superserials permission
The superserials permission is meant to allow an operator
to see all subscriptions regardless of branch when IndependentBranches
is on without having to have full superlibrarian permissions. This
patch restores this behavior.
TEST PLAN
---------
1) Apply the patch for bug 12048 (as needed -- it may be pushed)
2) Ensure you have two users: superlibrarian, non-superlibrarian
with all access to the staff client except superserials.
3) Ensure you have serials belonging to a different branch than
the non-superlibrarian.
3) Log into staff client as superlibrarian
4) Click 'Serials'
5) Click the 'Submit' button in the search area.
-- note the number of results.
6) Log into staff client as non-superlibrarian
7) Click 'Serials'
8) Click the 'Submit' button in the search area.
-- note the number should be less, note the number.
9) Give the non-superlibrarian superserials access.
10) Home -> Serials
11) Click the 'Submit' button in the search area.
-- the number will still be the same at the one in step #8.
12) Apply the patch
13) Refresh the page
-- the number should now match the one in step #5.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12048: restore ability of superlibrarian to see other libraries' subscriptions
This patch fixes a regression in master and 3.14. When a user has
superlibrian permissions, a search on serials subscriptions should
display other libraries' subscriptions even when IndependentBranches
syspref is enabled.
To reproduce/test the bug/patch:
1. Enable IndependentBranches (i.e. 'Prevent' staff...)
2. Login as a user not having superlibrarian permission
3. Search for a serial subscription on:
/cgi-bin/koha/serials/serials-search.pl
4. Search a title which has at least 2 subscriptions: one in the user
branch, and one in another branch
5. On the result page, just 1 subscription is displayed: the one
attached to the userbranch
=> this is normal
6. Login as a user having superlibrarian permission
7. Repeat step 3-5.
8. You get the same result as 5. You should have seen all subscriptions.
That's what you get after applying this patch.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: I tested a variation. My superlibrarian was a branch that
was not the same as the non-superlibrarian. The serial was
the same branch as the non-superlibrarian. Without the
patch, the superlibrarian saw nothing, with the patch it
saw the serial as expected.
Also, remember the superserials permission can affect the
results. I successfully changed the branch of the
subscription, and then it ceased to show up with
superserials not granted to the non-superlibrarian.
I corrected the system preference name in the text here.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Superlibrarian permission now allows to see all subscriptions
independent from the branch.
Passes all tests and QA script.
But the superserials permission appears broken to me before
and after this patch. If I have superserials - the search
doesn't show all subscriptions. If I don't have superserials
I can still edit any subscription accessing the subscription
detail page through the serial collection page or accessing
the detail page directly by manipulating the URL.
Jonathan Druart [Wed, 3 Jul 2013 08:52:21 +0000 (10:52 +0200)]
Bug 10533: move JavaScript functions for basket groups to a separate file
This patch moves JavaScript functions used for managing basket groups
to a file. This has the effect of putting the last (active) use of
the YUI JavaScript library by the staff interface in one file:
koha-tmpl/intranet-tmpl/prog/en/js/basketgroup.js
Test plan:
- Try all actions for basketgroup ( drag/drop, add, delete, close, print,
reopen, edit, export as csv).
- Check that there is no regression on others acquisition pages:
* acqui/neworderempty.tt
* acqui/uncertainprice.tt
* acqui/addorderiso2709.tt
* acqui/basketheader.tt
* admin/aqbudgets.tt
* admin/aqcontract.tt
* admin/aqbudgetperiods.tt
* admin/aqplan.tt
* suggestion/suggestion.tt
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests and QA script.
Frédérick [Tue, 18 Mar 2014 20:11:44 +0000 (16:11 -0400)]
Bug 11955: Remove spaces in empty indicators when linking an authority to a biblio record.
This patch removes spaces in indicators which are imported when we link an
authority to a biblio record. The spaces made the indicators harder to edit
after the linking, because we had to delete the superfluous space character
before a new value could be entered.
To test:
1. Open some authority on editor, save with empty indicators.
They are saved as ind1=" " ind2=" " on auth_header tables, with spaces
2. Edit some record, link some tag with previous auth,
indicators now have a space on it (or ind1 at last)
3. Apply the patch
4. repeat 2, space is gone
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No koha-qa errors.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12071: improve generation of Z39.50 search links
This patch fixes two problems with the generation of
links to execute a Z39.50 search from the staff client
catalog and cataloguing search results page.
First, if using URI::Escape 3.30 or earlier, performing a simple search
with a double quote (e.g., "histoire algerie"), the Javascript is broken
in results page because of :
function GetZ3950Terms(){
var strQuery="&frameworkcode=";
strQuery += "&" + "title" + "=" + ""histoire%20algerie"";
Second, the encoding of non-ASCII characters in the search
term was broken.
This patch moves URI escaping from Perl to template with uri TT filter.
Test plan :
- To reproduce the issue with double quotes, the server
must be running URI::Escape 3.30 or earlier; the current
version of URI::Escape properly escapes double quote.
- In staff interface, perform a search with double quotes
that will return no result, ie "aaa xxx"
=> Without patch, javascript is broken
=> With patch, javascript is not broken
- Click on Z3950 button on results page
=> Without patch, the Title input is empty
=> With patch, the Title input contains the search terms
Additional test:
Do a search with something like äöü and then click Z3950
button on results page.
Without patch, encoding is broken in Z3950 form
With patch, encoding is correct.
Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed a few tabs. Passes tests and QA script.
I can't reproduce the Javascript problem, but I can reproduce
the Z39.50 encoding problem and can detect no regression.
Kyle M Hall [Fri, 15 Nov 2013 16:29:23 +0000 (08:29 -0800)]
Bug 11258: fix another case where holds queue made transfer requests that contradict the library holds policy
This patch fixes a problem where the holds queue generator
was making requests where the pickup library is the
same as the item's library but not the patron's branch,
even if there is a "Default holds policy by item type" rule that states
this item can only fill holds for patrons of the same library as the
item.
Test Plan:
1) Create a test record with 2 items with different itemtypes
2) Set the Default holds policy by item type for the first
item to "From any library"
3) Set the Default holds policy by item type for the second
item to "From home library"
4) Place a record level hold for a patron from another library,
but for pickup at the same library as the item is from
5) Rebuild the holds queue
6) View the holds queue, note the item is listed, though this
patron cannot place a hold on this item
7) Apply this patch
8) Repeat step 5, note the hold is no longer in the queue
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
automated tests pass, functional tests pass. Bug replicated, eradicated by patch.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I finally managed to reproduce this, patch works as described.
Passes tests and QA script, provided tests fail without patch, but
succeed with the patch.
This patch modifies the patron summary printout so that
only fines with an outstanding balance (either positive
or negative) are displayed. Also, the entire fines section
is displayed only if there is a non-zero balance.
This is consistent with the logic for displaying the loans
and hold requests tables, and avoids cluttering the summary
with historical fines.
Frédérick [Thu, 27 Feb 2014 20:54:01 +0000 (15:54 -0500)]
Bug 11869: Add more informations to the patron account printing page
This patch adds additional informations to the "Print summary"
and the "Print receipt" templates.
Additional information in "Print summary":
* Registration date
* Expiration date
* Library
* Category
* Fines and payments
TEST PLAN
---------
1) Go to a patron.
2) Make sure they have something checked out.
3) Manually add a fine.
4) Under the 'Print' button click 'Print summary'
-- the resulting preview should:
a) have the first for things listed above, and
b) have a new fines and payments section.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: The due date of the check out is not part of this patch,
and so I signed off. Similarly, anything required for
slips is configurable elsewhere now and thus comment 1
does not accurately reflect the intent of this patch.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works as described and passes all tests and the QA script.
Owen Leonard [Wed, 9 Apr 2014 16:15:56 +0000 (12:15 -0400)]
Bug 12058: make OverDrive search results page show cart, lists, and login links
The template for OverDrive search results in the Bootstrap OPAC doesn't
show the cart, lists, or login links because the template's checks of
related system preferences relies on [% USE Koha %], which is not
present. This patch adds it.
To test, enable the bootstrap theme and OverDrive integration
(OverDriveClientKey, etc.). Perform a search in the OPAC and click to
view results from your OverDrive library. Confirm that cart, lists, and
login links appear in the header.
Signed-off-by: Jesse Weaver <pianohacker@gmail.com>
Bug confirmed, and this patch fixes it.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 9448: (follow-up) prevent unauthorized operator from bypassing check on forgiving overdue fines
This patch adds a step to verify that an operator has the writeoff
permission before allowing them to forgive overdue fines during
checkin, which was possible if the operator manually added an
"exemptfines" URL parameter.
Bug 9448: (follow-up) tweak description of new permissions
"Fines and fees" is consistent with the description of the
main "updatecharges" permission; in some areas, "charges" by itself
can refer to loans, not fees.
Rephrases permission description a bit to make it clearer and easier to
translate.
Adds German descriptions as requested by katrin.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes QA script and all tests.
Tested with various permission combinations:
- superlibrarian
- updatecharges (full permission)
- only 'remaining permissions for updating charges'
It works as expected.
Note: I think we need a follow up to include the
'Forgive overdue charges' checkbox on the check in page
in the new permission.
Kyle M Hall [Thu, 21 Mar 2013 11:18:50 +0000 (04:18 -0700)]
Bug 9448: Add separate permission for writing off fees
Adds new sub-permissions to updatecharges, 'writeoff' for writing off
fees and 'remaining_permissions' for all other fee related activites.
Test plan:
1) Apply patch
2) Run updatedatabase.pl
3) Remove the 'writeoff' permission from your privileges
4) Attempt to write off a fee, you should not be able to
5) Re-add the 'writeoff' permission
6) Attempt to write off a fee, you should now be able to do so
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12079: ensure that CheckReserves() includes reserve_id in its response
This patch modifies _Findgroupreserve so that its one caller,
CheckReserves(), would include the reserve_id field in the
hold request it returns.
Failure to include reserve_id in every circumstance resulted
in bug 11947. This patch is therefore a complementary fix for
that bug, but is not meant to preempt the direct fix for
that bug.
To test:
[1] Verify that t/db_dependent/Reserves.t passes.
[2] Verify that the following test plan taken from
the patch for bug 11947 works for this patch
*without* applying the patch for 11947:
* have a few borrowers, say 4.
* have a biblio with a single item (you can scale this up, it should
work just the same.)
* issue the item to borrower A
* have borrowers B, C, and D place a hold on the item
* return the item, acknowledge that it'll be put aside for B.
* view the holds on the item.
Without the patch:
* the hold priorities in the UI end up being "waiting, 2, 1" when they
should be "waiting, 1, 2".
* in the database "reserves" table, they're really "0, 2, 3" when they
should be "0, 1, 2".
With the patch:
* the hold priorities in the UI end up being "waiting, 1, 2"
* in the database, they're "0, 1, 2"
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No koha-qa errors. Test pass
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Kyle M Hall [Mon, 6 Jan 2014 18:46:02 +0000 (13:46 -0500)]
Bug 11484: Add option to cleanup_database.pl to purge Z39.50 search records from reservoir
It would be good to be able to specifically target import records from
Z39.50 for cleanup.
Test Plan:
1) Apply this patch
2) Import one or more batch record sets into Koha
3) Perform some Z39.50 searches
4) Run this command: misc/cronjobs/cleanup_database.pl -v --z3950
5) Verify that only Z39.50 records were deleted
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12081: make tmpl_process3.pl delete ts temp files
This patch enable deletion of temp files used by
tmpl_process3.pl.
Just removed coments on existing code
To test:
1. Do a count of files on /tmp ( ls /tmp | wc -l )
2. Update preferred language
3. Count again, new files on /tmp
4. Apply the patch
5. Update again, check, no new files
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: I watched what temp files were actually in /tmp to make
sure other processes didn't magically increase/decrease
the number.
$ perl translate update {lang code}
generated 10 temporary files for me (2x5 po files). After
removing those ten files, and applying the patch, no
other files were generated.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
These lines has been commented by commit a399dcefad193fc21ef2dc1fe31d07686ab2da46 without any apparent good
reason.
Pasi Kallinen [Wed, 29 Jan 2014 07:37:18 +0000 (09:37 +0200)]
Bug 11630: improve parsing of age restriction markers
This patch makes the parsing of AgeRestrictionMarker values consider
the case where the marker is immediately followed by the age, e.g.
"K16" in Finland.
How I tested:
[1] Configure Age Restricition (see Syspref AgeRestrictionMarker) and
have a biblio record with e.g. PEGI 99 in age restriction field.
[2] Try to check out to a patron with age < 99
[3] Check out should be blocked
[4] Change entry in age restriction field to PEGI99
[5] Checkout should be possible
[6] Apply patch
[7] Checkout schould now be blocked
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>
Jonathan Druart [Wed, 9 Apr 2014 08:24:24 +0000 (10:24 +0200)]
Bug 12052: New syspref to display message on the OPAC patron summary page
Test plan:
Fill the OPACMySummaryNote with HTML code or just text.
The content should be displayed at the OPAC on the summary page for
patrons.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and QA script.
Rephrased the pref text a little bit, using 'logged in' instead of
'connected', also added " so the description appears correctly in the
pref editor.
Mason James [Mon, 16 Sep 2013 03:12:16 +0000 (15:12 +1200)]
Bug 10825: don't display enum/chron twice for items received via the serials module
TEST PLAN
---------
1) In the staff interface, display a bib that has one or more items
that were received in the serials module. The following query
can identify them:
-- in MySQL:
SELECT items.biblionumber,items.enumchron,serial.serialseq
FROM items,serial,serialitems
WHERE items.itemnumber=serialitems.itemnumber
AND serialitems.serialid=serial.serialid;
2) Note that in the holdings tab, the serial enumeration/chronology
is displayed twice.
3) Apply the patch
4) Refresh the screen
4) Now, the enum/chron should be displayed only once per item.
Signed-off-by: Mason James <mtj@kohaaloha.com> Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and QA script.
Template change only.
Mark Tompsett [Thu, 6 Mar 2014 06:29:39 +0000 (01:29 -0500)]
Bug 11797: fix odd number of elements in hash warning (MARC21)
This was discovered when someone triggered an authority search
on an authority record that was missing what is assumed the
default subfield for a given field.
It, however, also can be triggered in an OPAC authority search
by looking at the record that lacks the default subfield for a
given field.
TEST PLAN
---------
1) Create an authority record with 180$x and NOT 180$v.
See C4::AuthoritiesMarc::BuildSummary in the 1.. foreach loop
for known tags and default values. The default subfields are
the first letter of the $subfields_to_report string.
2) Trigger the bug:
Method 1: /cgi-bin/koha/opac-authoritiesdetail.pl?authid=#
Where # is the authority id of your tweaked record.
The error occurs in Normal view.
Method 2: Home -> Cataloging -> + New record
-> Click the 'Tag Editor' on 100$a
Editing of $a to $b and back may be required.
3) Notice there is an error log entry.
4) Apply the patch
5) Attempt to trigger the bug again
6) That specific error log entry is not generated.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Could generate the warning with a missing 151$a with both methods.
No warning anymore after applying this patch.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds unit tests for C4::AuthoritiesMarc::BuildSummary
for both UNIMARC and MARC21 and a regression test for the "Odd
number of elements in anonymous hash" warning.
To test:
[1] Run prove -v t/db_dependent/AuthoritiesMarc.t. It should
report one failure.
[2] Apply the main patch.
[3] Run t/db_dependent/AuthoritiesMarc.t again; it should pass.
Bug 5052: make it possible to pick a language if all choices are sublanguage
This was tricky to catch. In current implementation, Bug 6755
introduced in C4/Templates.pm as condition to send the array of
hashrefs of languages that (@$languages_loop<2), but with one
language group that condition is false, there is only one
element in that array.
This patch changes that condition to have more than one language
selected, grouped or not.
Also send $bidi value always, that was only sent if there is
more than one group language.
To test:
1. Translate to en-GB and en-NZ, or simply do mkdirs
on intranet-tmpl/prog and opac-tmpl/bootstrap
2. Go to Administration > System preferences > I18N
enable those languages on staff/opac
3. Check that language chooser is nowhere to be found
4. Apply the patch
5. Reload staff/opac, now you can see language chooser
NOTE: I made little changes on staff, but can't replicate
bootstrap colors for selected/unselected language. Someone
need to touch css files to make it happen. But that is
current behavior.
Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Good catch!
Robin Sheat [Mon, 17 Mar 2014 05:33:00 +0000 (18:33 +1300)]
Bug 11947 - renumber reserves when hold is confirmed
Currently when a reserve is moved to "waiting" status because it's
acknowledged on checkin, the reserve priorities aren't renumbered. This
causes things to go a bit haywire in the UI, in particular, some
reserves can unjustly end up with priority 1 when they shouldn't. It
also seemed to mess with the logic of who should get it next, but I
didn't look too closely at that.
This patch forces a renumbering so that all the priorities remain
copacetic.
Test plan:
* have a few borrowers, say 4.
* have a biblio with a single item (you can scale this up, it should
work just the same.)
* issue the item to borrower A
* have borrowers B, C, and D place a hold on the item
* return the item, acknowledge that it'll be put aside for B.
* view the holds on the item.
Without the patch:
* the hold priorities in the UI end up being "waiting, 2, 1" when they
should be "waiting, 1, 2".
* in the database "reserves" table, they're really "0, 2, 3" when they
should be "0, 1, 2".
With the patch:
* the hold priorities in the UI end up being "waiting, 1, 2"
* in the database, they're "0, 1, 2"
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Test plan confirms that the problem exists and that the patch corrects
it.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script, especially t/db_dependent/Reserves.t.
Improves priority calculation.
Owen Leonard [Fri, 11 Apr 2014 16:40:20 +0000 (12:40 -0400)]
Bug 12075: fix keyboard shortcuts broken by jQueryUI upgrade
The recent jQueryUI upgrade broke keyboard shortcuts in the staff client
because of changes to the jQueryUI API. This patch fixes the problem.
To test, apply the patch and clear your browser cache if necessary.
- View any page in the staff which includes header search tabs for check
out, check in, or catalog search (staff client home page or
circulation page for instance).
- Test the keyboard shortcuts: Alt-q for catalog search, Alt-u for check
out, Alt-r for check in.
- Each keyboard shortcut should select the correct tab.
Followed test plan, patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Confirmed that the shortcuts were broken before the patch
and now work again after applying it.
Fridolin Somers [Mon, 24 Feb 2014 11:15:55 +0000 (12:15 +0100)]
Bug 11846: Correct database update for restrictions with date 9999-12-31
The borrowers with indefinite restrictions have borrowers.debarred with '9999-12-31'.
Database update for this bug contained :
INSERT INTO borrower_debarments ( borrowernumber, expiration, comment )
SELECT borrowernumber, debarred, debarredcomment FROM borrowers WHERE debarred IS NOT NULL
For borrowers where borrowers.debarred is '9999-12-31', this value
is copied into borrower_debarments.expiration.
This is not correct because borrower_debarments.expiration must be
NULL for indefinite restrictions.
This patch corrects update 3.13.00.035 and also adds an update for
databases already updated.
Test plan :
- Use a database with version 3.13.00.000
- Set a borrower as restricted for ever (leave until empty)
- Use sources to master + patch
- Perform updatedatabase
- Look at borrower details, tab "Restrictions"
=> Without patch, you see Expiration 31/12/9999
=> With patch, you see Expiration Infinite
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
I tested both DB revisions by resetting Version of my database (and
adding a SetVersion after the revised older dbrev). This was possible
since the debarred field still exists in borrowers. (I have my doubts
about that, but that goes outside the scope of this report.)
Also note that routine _UpdateBorrowerDebarmentFlags puts back 9999-12-31
into borrowers for indefinite restrictions (which looks not very consistent).
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 12073: don't show link URLs when printing Bootstrap OPAC detail page
On OPAC Bootstrap detail page, by clicking Print link on the right the
page is printed. But the printed page contains HTML <a> anchors URL
attribute. It's useless, and unreadable. It isn't the case with prog
theme.
This patch hides all <a> href attributes when printing any OPAC page.
Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and improves the printed detail page's readability.
Currently there is no less file for the print.css.
Owen Leonard [Thu, 10 Apr 2014 19:50:40 +0000 (15:50 -0400)]
Bug 12069: redirect to staff login if you access members/mod_debarment.pl when logged out
members/mod_debarment.pl's call to checkauth should pass 'intranet' so
that if the user happens to be logged out they will be redirected to the
staff client login form, rather than the OPAC.
To test, apply the patch and log in to the staff client:
- Add a restriction to a patron's account.
- View the restrictions tab on the patron's account. You should see the
restriction and a "Remove" link for that restriction.
- In another tab, log out of the staff client.
- In the first tab, click the "Remove" link. You should be redirected to
the staff client login page.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Good catch! Works as described, passes all tests and QA script.
Bug 12076: better detect an untranslatable template construct
Per bug 6458, template constructs of the form
<li [% IF (foo) %]selected="selected"[% END %]...
are forbidden as they can cause problems with translated templates.
However, the tt_valid.t test currently doesn't catch the variation
where '-' is used to suppress extra whitespace:
<li [%- IF (foo) -%]selected="selected"[%- END -%]...
This patch corrects the issue.
To test:
[1] Temporarily add the following line to a template file:
<li [%- IF a -%]a="a"[%- END -%] />
[2] Run prove -v xt/tt_valid.t. Note that no error is reported.
[3] Apply the patch, and rerun the tt_valid.t test. This time,
an error should be reported.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works well, detects the forbidden pattern
No koha-qa errors.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests and QA script.
projects / koha.git / log