When opac-details calls parametrized_url, it triggers an uninitialized
warning when you would have a record without e.g. author, like:
Use of uninitialized value in subroutine entry at /usr/share/perl5/URI/Escape.pm line 184.
This is (imo) actually a bug in URI::Escape; it should check its args.
But we resolve the warning here by adding the "// q{}" in parametrized_url.
NOTE: Along the way we do something similar in the arrParamsBusc loop.
If the variable is undefined, jump to the next one. (Consistent with the
approach in the if-part preceding it.)
Test plan:
[1] Run t/Output.t again. Should pass now.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This test will reveal that we need to resolve a warning too.
Test plan:
[1] Run t/Output.t without the second patch.
[2] The test will fail on the warning raised by an undefined value.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If you have multiple languages installed, the notices and slips page
uses the same HTML id multiple times, once for each language. This
prevents eg. the SMS character count javascript from working, because
each of the textareas has the same id.
Test plan:
Test the sms characters counter, with and without TranslateNotices
Make sure other features on this page still work correctly
QA: Make sure this change of id did not break something else.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On reports/itemslost.pl you must now see the descriptions instead of the
code for itemtype and location
Signed-off-by: delaye <stephane.delaye@biblibre.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In subscription-add.pl, the two params aren't passed to
NewSubscription() but they are to ModSubscription()
== Test plan ==
1. Enable syspref "makePreviousSerialAvailable"
2. Create a minimal subscription with a value in the "Item type" and
"item type for older issues" fields.
3. Edit the subscription
4. You should see that the two fields are empty. This is the bug.
5. Apply this patch
6. Do step 2 and 3
7. You should see that the two fields have the right value
8. Express the joy of a successful and easy sign off.
(this is important, otherwise the sign off spell won't work!)
Signed-off-by: delaye <stephane.delaye@biblibre.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The plugins handling code expects plugins implementing an 'uninstall' method for
cleanup purposes. It executes this method, and then moves on with removing the
configuration entries in the storage, and the plugin itself.
But the 'plugins-home.tt' template makes the tool display the 'Uninstall'
link in the dropdown ONLY when the plugin has the 'uninstall' method.
This patch fixes the issue.
To reproduce:
- Install the KitchenSink plugin [1]
=> SUCCESS: The 'actions' dropdown for KitchenSink shows an 'Uninstall' option
- Edit the code for the plugin:
$ sudo vim /var/lib/koha/kohadev/plugins/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm
- Remove the uninstall sub
- Restart everything:
$ restart_all
- Reload the browser
=> FAIL: There's no 'Uninstall' option in the actions dropdown.
- Apply this patch
- Restart everything
$ restart_all
- Reload the browser
=> SUCCESS: The 'actions' dropdown for KitchenSink shows an 'Uninstall' option
- Sign off :-D
[1] https://github.com/bywatersolutions/koha-plugin-kitchen-sink/releases
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes [% KOHA_VERSION %] from the <script> tag for some
third-party JavaScript sources. [% KOHA_VERSION %] should only be used
for Koha's JS resources.
To test, apply the patch and enable the SocialNetworks and
NovelistSelect* preferences.
In the OPAC, view the detail page for a bibliographic record. In the
right-hand sidebar you should see social network icons for Google+ and
Twitter. Clicking either of them should trigger a sharing popup window.
If you have Novelist credentials and can enable the feature for the OPAC
you should see Novelist content in the place specified in your
preferences.
If you don't have Novelist credentials, put some random text in the
NovelistSelectProfile system preference. Looking at the detail page in
the OPAC, view source. You should see a link to Novelist JS around line
1020 of the source. Clicking the link should show JavaScript. This
confirms that the path is correct, thus the bug has been fixed.
Note: The QA tool will complain that [% KOHA_VERSION %] is missing. This
is a false positive.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should not ask for 'cancel this hold'. Remove corresponding TODO.
Fix qa warning on old bootstrap style:
btn btn-mini => btn btn-default btn-xs
I removed above change, qa tool complaint is wrong (refers to staff, we
are on opac)
Test plan:
Create an article request and cancel it on opac-user.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The same pattern was used in other files, this patch fixes it.
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Koha didn't check for a linked authorised value category for
Koha didn't check for a linked authorised value category for
items.materials correctly which led to displaying false information
on the detail page.
To test:
- before applying the patch:
- make sure sample data and configuration is loaded
- edit any item
- write 2 in the $3 materials specificed
- check the details page normal view - it will display 'restocking'
- apply patch
- check display, it should now show "2"
- link 952$3 (MARC21) to ORDER_CANCELLATION_REASON
- check display again, it should now show 'restocking'
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Template smart-rules.tt in administration contains some if/elsif/else with translatable strings.
For example :
[% IF rule.onshelfholds == 1 %]
Yes
[% ELSIF rule.onshelfholds == 2 %]
If all unavailable
[% ELSE %]
If any unavailable
[% END %]
Adding span to translatable strings will allow to have the same translation than :
<select name="onshelfholds" id="onshelfholds">
<option value="1">Yes</option>
<option value="0">If any unavailable</option>
<option value="2">If all unavailable</option>
</select>
This is important to allow editing an existing circulation and fine rule.
Actually for example in french some strings are translated differently :
msgid "%s Yes %s If all unavailable %s If any unavailable %s"
msgstr "%s Oui %s Si tous indisponibles %s Si aucun indisponible %s"
msgid "If any unavailable"
msgstr "Si au moins un exemplaire est indisponible"
Test plan :
1) Look at PO files, for example fr-FR and see there is :
msgid "%s Yes %s If all unavailable %s If any unavailable %s"
msgid "If any unavailable"
2) Apply patch
3) update PO files
4) Look at PO files, for example fr-FR and see there is now only :
msgid "If any unavailable"
5) Install translation
6) Go to Administration > Circulation and fine rule
7) Check that when editing an existing rule, edition comboboxes are set on the correct value
8) Create a default holds policy by item type and check that correct values are displayed in table
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch updates the database update script replacing the "pile of
poo" emoji with the "wrapped gift" emoji.
To test, apply the patch and go to Administration -> System preferences
-> Local use. Set the "Version" preference back to trigger a database
update. Go through the database update process and confirm that the
"Convert DB tables to utf8mb4" upgrade message includes a gift emoji.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When bibliographic records are merged, the suggestions.biblionumber
field should be replaced with the new record.
Ideally we should have kept an history of the merges, to know what was
the original record. Now we cannot fix the broken links.
Test plan:
1) Create a suggestion in OPAC
2) Accept the suggestion in staff
3) Add order from this suggestion
4) Go to cataloguing search and search for the record and another
5) Merge the suggestion record with the catalog record - catalog record wins (should be the more common case when a patron suggests something that already exists)
6) Verify that after merging, the new title displays in the acquisition record
7) Verify that the suggestion info no longer displays in basket
From Katrin's test plan:
8) Verify that the new title doesn't display in suggestions. The old title will still show as suggested (not updated)
=> This is the title from suggestions.title, I think it makes sense to show this one.
Maybe we should open a new bug report to improve the display of the suggestion, and link to the bibliographic record
Signed-off-by: Lucie Gay <lucie.gay@ens-paris-saclay.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch fixes very weird behaviours introduced by
commit 0ab22e1c7c
Bug 18789: Send Koha::Patron object to the templates
The patron variable was only set when no action was defined.
This patch restores the feature the easiest way possible (less changes)
even if it is not the best one.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This sets a valid email and changes the tests
to expect it was sent.
prove t/db_dependent/Passwordrecovery.t
-- noise before patch
-- no noise after patch
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch tests the required parameters and redirects with a 400 HTTP
code if parameters are invalid.
It also removes the need for the passed biblioitemnumber which is not
used at all.
A (now) useless sub is removed too.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It is no longer used.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The biblioitem's info can be retrieved with Koha::Biblio->biblioitem
Test plan:
1. Use the age restriction to restrict checkouts for a given patron
2. Check some items of a biblio out, go to "Items" tab, then "View
item's checkout history" link. Compare views with and without patches
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Just a preliminary step to clean the code a bit in CanBookBeIssued.
The effective item type is already set from GetItem and we do not need
to deal with that again.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This subroutine is only used once and can be replaced easily with a
Koha::Biblioitems->search call
Test plan:
Test this on top of bug 19941 and confirm that the correct item types
are displayed
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The subroutine GetBiblioItemByBiblioNumber considers that we have a 1-N
relation between biblio and biblioitems, which is wrong (it's 1-1).
So the calls can be replaced with Koha::biblio->biblioitem, it will ease
the read of the code.
Test plan:
1. Use the ILSDI service to display info of a bibliographic record,
biblioitems fields must be displayed
2. Search for items, biblioitems info must be displayed as well in the
result table
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Here we are, patronflags is used in a couple of places where (almost) all flags
were really useful: C4::SIP::ILS::Patron->new and circulation.pl
This patch only deal with the circulation code as I am not convident
enough with SIP code.
The change does not seems trivial because of the complexity of the
existing code, but the logic is the same. We send a variable to the
template depending on the situation of the patron.
I guess only code eyes ball could catch issue in this patch quickly.
Maybe we need to find a good place in a Koha module to move this code
and provide code coverage (especially when C4::SIP::ILS::Patron will
reuse it).
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch replaces the easy occurrences of patronflags.
These calls only need the CHARGES->amount value, that is the non issues
charges. Luckily we now have a Koha::Account->non_issues_charges that
deal with that.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The change is trivial here, we only want to pass gonenoaddress, lost and
is_debared to the template.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is oldamound/amountold variable that is sent to the template but
never used later. Let remove it now to avoid useless replacement.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I added a magnigying glass icon in the staff detail view that links to
the authority records.
Test Plan:
1) On the Koha staff page, create a new authority. The type of authority
will be: Topical Term.
2) When creating authority, in tab 1 under -HEADING--TOPICAL TERM enter
the topical term or geographic name entry element and then save the
new authority e.g. science.
3) In circulation, search the catalog for a random book. Click the title
of the book and you will be taken to the book details.
4) Edit the record and in tab 6, scroll down the - SUBJECT ADDED
ENTRY--TOPICAL TERM and repeat this tag (the icon next to the title).
5) Edit the Topical term or geographic name entry element by clicking
the button on the right of the bar.
6) In the Search main heading ($a only) enter your topical term e.g.
science.
7) Press search, and then in the table that pops up, click 'choose'.
8) Save your edits and the new topical term will be in the 'Subject(s)'
list of the book details.
9) Notice that there is no magnifying glass icon.
10) Apply this patch
11) Notice that there is now a magnifying glass icon next to the topical
term.
12) Click on the magnifying glass and it will take you directly to the
authorities records
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a black version of the Koha logo for use in OPAC
customization.
To test, apply the patch and add this CSS to your OPACUserCSS system
preference:
.navbar-inverse .navbar-inner {
background: #CCC none;
}
#logo {
background: transparent url(/opac-tmpl/bootstrap/images/koha-logo-navbar-black.png) no-repeat scroll 0;
}
Refresh your OPAC and the top navigation bar should be changed from
black to grey, and you should see a black version of the Koha logo.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
A follow-up on a preceding report introduced a join instead of a
subquery. This made the categorycode ambiguous.
Test plan:
See former patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
[1] Run the script with -doit and -cat [some_category] and verify that
the printed total is correct.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Charles Farmer <charles.farmer@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Instead of updating patrons over all patron categories, it would be
helpful if we could filter on a specified category.
Test plan:
[1] Select two patrons A and B in say categories C1 and C2.
[2] Change the msg prefs for A and B away from defaults.
[3] Run borrowers-force-messaging-defaults.pl -doit -cat C1
Verify that patron A changed and patron B did not.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Charles Farmer <charles.farmer@inLibro.com>
Amended: Replace -category by --category. (marcelr 20180314)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently, if outputting a CSV file using runreport.pl, you need to look at the report used to know what each column means. It would be nice if we could include column headers.
Test Plan:
1) Apply this patch
2) Try using runreport.pl with --format csv --csv-header
Signed-off-by: David Bourgault <david.bourgault@inlibro.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries want to keep a history of cardnumber changes for a
patron. This is a feature that another ILS has.
Test Plan:
1) Apply this patch
2) Enable the BorrowersLog
3) Modify a patron, update his or her cardnumber
4) Notice the entry in the action log containing the old and new cardnumbers
5) Edit a patron, leave the cardnumber the same
6) Note there is no cardnumber change entry in the action logs
7) Disable BorrowersLog, modify a patron cardnumber
8) Note there is no cardnumber change entry in teh action logs
Followed test plan, works as expected
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries need to be able to send additional patron data from the
extended patron attributes in made up SIP2 fields for the patron
information and patron status responses.
Test Plan:
1) Apply this patch
2) Create 3 new patron attributes with the codes CODE1, CODE2, CODE3.
Make a least one repeatable.
3) Create a patron, add those attibutes for the patron, make sure there
are at least two instances of the repeatable code
4) Edit your SIP2 config file, add the following within the login stanza:
<patron_attribute field="XX" code="CODE1" />
<patron_attribute field="XY" code="CODE2" />
<patron_attribute field="XZ" code="CODE3" />
5) Using the sip cli emulator, run patron_information and
patron_status_request messages for the patron
6) Note the values you set for the patron attributes are sent in the
corrosponding fields!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Daniel Mauchley <dmauchley@duchesne.utah.gov>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: added parentheses on line 488 when assigning hashref to array.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Added divs to report-menu.inc as well. Should work on any reports page
with sidebar now.
Signed-off-by: claude <claude.brayer@cea.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan
1. Open tools page and click on any of the links with a sidebar
2. Note the layout of the sidebar
3. Open reports page and click on any of the links with a sidebar
4. All the sidebars should have the same layout as the tools one
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
