Bug 10177 rejects password with leading or trailing whitespaces, but
only on the member-password page.
It's not consistent to only do this check on 1 place.
This patch adds the check for the 2 other places: memberentry and at the
OPAC.
Test plan:
1/ Edit a patron and set a password with leading and/or trailing
whitespaces. You should not be allowed to do it (no server side check).
2/ Same at the OPAC ("Change you password" tab). Here there is a server
side check.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 1b8f3194e9)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
(cherry picked from commit a19c1257eb)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Note without this patch, you won't be able to access the SCO side.
So don't panic if you cant use SCO with just the first patch
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(cherry picked from commit 047f0a486b)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
This is an issue discussed on older reports already in the past.
Column mobile in borrowers is actually 'Other phone', not necessary a
mobile number. The name of the field is confusing. (Renaming it is
outside the scope of this report.)
The field that we are editing here is smsalertnumber. It should not be
compared with mobile at all.
What could be the side-effect of this correction?
===
First, the change is only relevant for libraries with pref SMSSendDriver
enabled.
In the past patrons editing their message preferences saw mobile (read:
other phone) in their smsalertnumber field (if the latter was still empty).
If they saved it, it was copied to smsalertnumber.
This change does not affect these patrons. They just have the same number
in two columns. No big deal.
What if a patron does not yet have a smsalertnumber? In that case no sms
is sent in Letters.pm. So no change in behavior. If he submits
opac-messaging now, he will no longer copy his other phone to smsalert [we
cannot assume that it was mobile anyway!]. If he enters a mobile number,
it will be saved correctly in the right field.
Conclusion: this change will not break things or hurt anyone. It only
prevents unwanted copying other phone to smsalertnumber.
Also modified the compare to prevent uninitialized warnings.
And removed a commented warn.
Test plan:
[1] Add, edit or delete the SMS number on opac-messaging regardless of
the value of Other Phone (in the badly named mobile field).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 9b8d7168be)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit bc72046421)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Enables to clear SMS number.
To test:
1. Go to opac-messaging.pl
2. Insert SMS number and submit
3. Clear SMS number and submit
4. Observe that the sms number did not change
5. Apply patch
6. Clear SMS number and submit
7. Observe that the sms number changes
Sponsored-by: Vaara-kirjastot
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Adding a follow-up.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 5b1c7e4c35)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 227d7b950e)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
When getting records from OAI-PMH, an error must be returned if there is no results.
See : http://www.openarchives.org/OAI/openarchivesprotocol.html#ErrorConditions
Test plan :
- Enable OAI webservice
- Perform a query that will return no results. ie : /cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=marcxml&from=2099-12-30&until=2099-12-31
=> Without patch you get a response with :
<ListRecords/>
=> With patch you get a response with error code :
<error code="noRecordsMatch">No records match the given criteria</error>
- Check a good query returns still results
- Same test with ListIdentifiers verb
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 64992a05ce)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
(cherry picked from commit 3d8e059513)
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
The call to AddMember_Opac does not take care of the messaging prefs
when enhanced messaging is enabled.
This patch adds the call to handle_form_action to do that.
Test plan:
Enable self registering patrons and enhanced messaging.
Check the (default) message prefs for the relevant patron category. At least
enable email for one notice.
Self-register a user with and without verification email enabled.
Check in both cases that the message prefs of the user conform to
those in the patron category. (So at least one enabled.)
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit f7ed250d61)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Get notes and subjects from MARC record
ONLY when XSLT is not activated.
It's useless doing it when XSLT is activated,
because XSLT takes care of it by its own.
=> With this patch, we are saving precious
milliseconds
I compared the display of some records in XSLT view with and without patch, was the same (as expected).
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
On a slower server, I saw a time save of 0.0274 to 0.0908 seconds (with XSLT).
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit 468d3d9c83)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Since Bug 14408, the method get_template_and_user can not have an empty template_name.
Pages calling with an empty value should use C4::Auth::checkauth()
This patch corrects opac/opac-ratings.pl
Test plan :
- Apply patch
- Set sysopref OpacStarRatings to 'results and details'
- Disable Javascipt on your browser (otherwise it will use ajax)
- Login at OPAC
- Go to a record
- Click on a button left of 'Rate me' to choose a rating, ie 4
- Click on 'Rate me'
=> The page is reloaded and you see 'your rating: 4'
- Loggout from OPAC
- Try to access URL : http://<serveur>/cgi-bin/koha/opac-ratings.pl
=> You see the loggin page
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit f1acb5615d)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
(cherry picked from commit 3d8af819a8)
Conflicts:
opac/opac-ratings.pl
Signed-off-by: Liz <wizzyrea@gmail.com>
This pref does not work at all, the interface let the user choose to
list all suggestions, but whatever he chooses the suggestion list is the
same.
This patch cleans a bit the suggestedby management.
There are a lot of cases to test, because linked to 2 prefs:
AnonSuggestions and OPACViewOthersSuggestions.
1/ AnonSuggestions = 0 and OPACViewOthersSuggestions = 0
- A non logged in user is not able to make a suggestion.
- A logged in user is not able to see suggestions made by someone else.
2/ AnonSuggestions = 0 and OPACViewOthersSuggestions = 1
- A non logged in user is not able to make a suggestion.
- A logged in user is able to see suggestions made by someone else.
3/ AnonSuggestions = 1 and OPACViewOthersSuggestions = 0
- A non logged in user is able to make a suggestion.
The suggestedby field will be filled with the AnonymousPatron pref value.
He is not able to see suggestions, even the ones made by AnonymousPatron.
- A logged in user is not able to see suggestions made by someone else.
4/ AnonSuggestions = 1 and OPACViewOthersSuggestions = 1
- A non logged in user is able to make a suggestion.
He is able to see all suggestions.
- A logged in user is able to see suggestions made by someone else.
In all cases a logged in user should be able to search for suggestions
(except if he is not able to see them).
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
All use cases tested, work as expected
No errors
Only comment is perhaps (in the future) a gracefull failure
when AnonymousPatron is not set, or has '0' value
Message is DBIx::Class::ResultSet::create(): Column 'suggestedby' cannot be null at ...
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
(cherry picked from commit be35039b55)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Liz <wizzyrea@gmail.com>
There is a SQL Injection vulnerability in the
/cgi-bin/koha/opac-tags_subject.pl script.
By manipulating the variable 'number', the database can be accessed
via time-based blind injections.
The following string serves as an example:
/cgi-bin/koha/opac-tags_subject.pl?number=1+PROCEDURE+ANALYSE+(EXTRACTVALUE(9743,CONCAT(0x5c,(BENCHMARK(5000000,MD5('evil'))))),1)
To exploit the vulnerability, no authentication is needed
To test
1/ Turn on mysql query logging
2/ Hit /cgi-bin/koha/opac-tags_subject.pl?number=1+PROCEDURE+ANALYSE+(EXTRACTVALUE(9743,CONCAT(0x5c,(BENCHMARK(5000000,MD5('evil'))))),1)
3/ Check the logs notice something like
SELECT entry,weight FROM tags ORDER BY weight DESC LIMIT 1
PROCEDURE ANALYSE
(EXTRACTVALUE(9743,CONCAT(0x5c,(BENCHMARK(5000000,MD5('evil'))))),1)
4/ Apply patch
5/ Hit the url again
6/ Notice the log now only has
SELECT entry,weight FROM tags ORDER BY weight DESC LIMIT 1
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Confirmed the problem and the fix for it.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
The sendbasket/sendshelf scripts and templates do not use email_sender
as a cgi parameter or as a template var. Probably a leftover from previous
changes.
Let's make Koha cleaner :)
Test plan:
[1] Send your cart from opac or staff.
[2] Send a shelf from opac or staff.
[3] Git grep email_sender. No results.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 0114465ced)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
The original concern of bug 14266 was to provide a compatibility for
<IE9.
But actually we don't need to trim the email address template side.
It will even better to trim it in the perl script, so that the email
will be trimed even if JS is disabled.
Test plan:
1/ Share a list and does not provide any email address
2/ Submit
=> The form is not submited, no alert/message is displayed (same as
before this patch).
3/ Share a list and provide an email address with spaces before and
after
4/ Submit
=> You should receive the email
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Test output compliant with expected test plan outcome.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit c7a8e4dd25)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
This patch sets $limit to be an empty string.
Test plan
=========
1/ login into the opac using your user account credentials
2/ in a terminal, run a `tail -f ` on your instance's opac-error.log
3/ go back to the opac, click on 'your reading history' tab to go to
opac-readingrecord.pl
4/ notice the warning - "opac-readingrecord.pl: Use of uninitialized
value $limit" appear in the `tail`ed opac-error.log
5/ apply the patch
6/ reload the page (opac-readingrecord.pl)
7/ page works but the warning in step #4 is no longer logged
8/ run qa test (i.e. koha-qa.pl -c 1 -v 2), there should be no error
Remarks: Testing result match expected test plan output. The QA tests
pass with "OK" for the commit.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit fd14184873)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
This is a followup for Bug 14186 that removes the extraneous tab
char on line 470, so that the patch can clear QA tools.
This patch sets $reservedfor to an empty string.
Test plan
=========
1/ in a terminal, run `tail -f ` on your instance's opac-error.log
2/ go to the opac and search from an item that exists on the Koha
instance.
3/ Select the title (if more than one title is returned) and click on
'Place hold' link to go to opac-reserve.pl
4/ notice the warning - "opac-reserve.pl: Use of uninitialized value
$reservedfor" appear in the `tail`ed opac-error.log
5/ apply the patch
6/ reload the page (opac-reserve.pl)
7/ page works but the warning in step #4 is no longer thrown up
8/ run qa test (i.e. koha-qa.pl -c 1 -v 2), there should be no error
Remarks: Testing result match expected test plan output. The QA tests
pass with "OK" for the commit.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 642e6012cd)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
This patch sets $reservedfor to an empty string.
Test plan
=========
1/ in a terminal, run `tail -f ` on your instance's opac-error.log
2/ go to the opac and search from an item that exists on the Koha
instance.
3/ Select the title (if more than one title is returned) and click on
'Place hold' link to go to opac-reserve.pl
4/ notice the warning - "opac-reserve.pl: Use of uninitialized value
$reservedfor" appear in the `tail`ed opac-error.log
5/ apply the patch
6/ reload the page (opac-reserve.pl)
7/ page works but the warning in step #4 is no longer thrown up
8/ run qa test (i.e. koha-qa.pl -c 1 -v 2), there should be no error
Remarks: The QA test failed - "forbidden pattern: tab char (line 470)".
Marking this as 'FAILED QA'
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 8fdd352bc9)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Same as previous patches for the OPAC.
Test plan is the same.
Tested with all patches applied. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 2504ade8eb)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
To test:
1)
Prepare an URL that put's a hold in OPAC (see comment #1), e.g.
[YOUR SERVER]/cgi-bin/koha/opac-reserve.pl?biblionumbers=1
2)
Set system preference 'RequestOnOpac' to 'Don't allow patrons to place holds on items from the OPAC.'
3)
Go diectly to this URL.
Result: The page displays to confirm hold (wrong)
4)
Apply patch
5)
Repeat step 3
Result: Redirect to 404 page (OK)
6)
Set system preference to "Allow"
7)
Repeat step 3
Result: The page displays to confirm hold (OK), like it would be from link in OPAC.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 20dc9ce5a1)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit a6c9bd0eb5)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
If you click a link from the Tag Cloud, the results page offers the
usual select menu to resort your results. However, doing so resubmits
the search as a standard keyword search.
Test plan:
1/ Click on a tag
2/ Confirm that the resort dropdown list does not appear.
Dropdown list disappears with tags as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit fc100688a4)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
This should fix the issue on other pages.
Test plan:
Try to download and export the basket (intranet+opac sides).
Re-tested for errors in comment #5, they do not longer appear.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 3adddd3410)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Bug 13425 tried to fix XSS in OPAC, by using url filter in template toolkit
on whole generated url. This doesn't work and create double encoded strings
in facets because we are creating url variable by concatenating query_cgi
(which did pass through uri_escape_utf8 on perl side) and other
parameters which have to be escaped in template.
Also, code like
[% SET limit_cgi_f = limit_cgi | url %]
doesn't do anything (at least doesn't apply url filter) so it's not needed.
This patch also fixes encoding of hidden fields used in sort by form.
And lastly, it tries to make facet changes for opac and intranet as same as
possible to simplify future maintencence of this code.
Test scenario:
1. find results in your opac which contain accented characters
2. click on them and verify that results are missing
3. apply this patch
4. re-run search and click on facets link verifying that there are
now results
5. test sort by form and verify that results are ok
6. verify that facets are still safe from injection by constructing url like
/cgi-bin/koha/opac-search.pl?q=123&sort_by='"><script>prompt('Happy_Holidays')</script>&limit=123
and verifying that you DON'T see prompt window in your browser
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 1ca9adaa56)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Conflicts:
koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-facets.inc
When responding to ListRecords and ListIdentifiers verbs, OAI server doesn't
return proper resumption token. At the end of a result set, OAI server
generates a resumption token even if there isn't anymore records. Consequently,
OAI harverster will send a new request, based on this invalid resumption,
token. OAI Server responds with an empty resultset, which is considered as an
invalid response by most of the harvesters.
TO TEST:
- Find in your DB, a day where a few biblio records have been created. The
number of created biblios must inferior to OAI-PMH:MaxCount.
- Let say this day is 2014-01-09. Send an OAI-PMH request to Koha OAI Server:
/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=marcxml&from=2014-01-09&until=2014-01-09
- At the end of the result, you will see a resumption token which looks like that:
<resumptionToken cursor="47">marcxml/47/2014-01-09/2014-01-09/</resumptionToken>
This is wrong. No resumptiion token should be sent since there isn't anymore
records to harvest.
- Apply the patch.
- Resend the OAI-PMH request. There is no resumption token at the end of the
result.
- You could test also with ListIdenfiers verb in place of ListRecord.
Signed-off-by: Christophe Brocquet <christophe.brocquet@obspm.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit f1ea9624bd)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
When a basket/shelf is downloaded, items are embedded, but not when
sending it by email.
We would expect to get the same file.
Test plan:
On Opac and intranet:
1/ Add records with items to your basket and send it by email.
Verify the file contains items.
2/ Add records with items to a list and send it by email.
Verify the file contains items.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit a0e5d77a71)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
No matter what the selection of OPACShowHoldQueueDetails is, if it is
enabled it displays a line "Holds and priority:" even if you've opted to
hide one of those!
Test Plan:
1) Apply this patch
2) Test each setting of OPACShowHoldQueueDetails
3) Ensure each setting displays the correct fields ( or lack thereof )
Signed-off-by: Christopher Brannon <cbrannon@debian.localdomain>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 295fb70f62)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Currently, mandatory fields in the borrower self-registration can be hidden.
This causes problems since the validator rejects the registration,
even though all required fields on the screen have been filled out.
This is especially a problem when using the system preference
"PatronSelfRegistrationVerifyByEmail", since it automatically makes
"email" a mandatory field.
This patch makes it so that a mandatory field cannot be hidden on
the self-registration page.
_TEST PLAN_
Before applying
1) Hide the "email" and the "emailpro" fields using the
"PatronSelfRegistrationBorrowerUnwantedField" system preference.
2) Make the "email" and the "emailpro" fields mandatory using the
"PatronSelfRegistrationBorrowerMandatoryField" system preference.
3) Note that you cannot see "Primary email" or "Secondary email"
on the self registration page.
(The registration page which can be found by turning
on "PatronSelfRegistration" and filling in
"PatronSelfRegistrationDefaultCategory". The link will be on
opac-main.pl on the right side of the screen under the login box.)
4) Note that you cannot submit a self-registration request as
the system tells you that you have not filled in all the mandatory
fields.
5) Apply the patch && refresh the self registration page
6) Note that you can now see "Primary email" and "Secondary email"
on the self-registration screen".
Signed-off-by: Abby <abbyrobnz@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit fd6176d0a5)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Added check for suggestions turned off. If off user is redirected to 404 error. If patron suggestions are off guest sugestions will also redirect to 404
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit bcbcad897a)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
The Unapi path to XSLTs is wrong in the OPAC.
Unfortunately, it's coded to work just for Git installs, which makes it
tough to test.
_TEST PLAN_
Before applying:
1) Go to
http://GIT-INSTALL/cgi-bin/koha/unapi?id=koha:biblionumber:1&format=oai_dc
2) If the biblionumber exists, it should show you the record in OAI_DC format.
3) Go to
http://REGULAR-INSTALL/cgi-bin/koha/unapi?id=koha:biblionumber:1&format=oai_dc
4) You should get a software error
Apply the patch.
After applying:
1) Refresh the page for
http://yourgitinstall/cgi-bin/koha/unapi?id=koha:biblionumber:1&format=oai_dc
2) It should work exactly the same as before.
Thorough testers:
1) Push the code to that regular test install
2) Try the link again. It will properly show the converted record now.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Verified that single install
intrahtdocs==/usr/share/koha/clone1712/intranet/htdocs/intranet-tmpl plus
"/prog/en/xslt/" is the location for the required xslt files.
Script unapi in git install is still fine.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit f1323e60a2)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Test plan:
Search for something
click on a facet with diacritic
click on another facet
remove the facet with diacritic
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 1c3b98e146)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
The suggestion table does not contain a 'branch' column name.
The script should pass 'branchcode' to C4::Suggestion::NewSuggestion.
Test plan:
0/ Enable the AllowPurchaseSuggestionBranchChoice pref
1/ Create a suggestion at the OPAC should not raise a DBIx::Class error.
I could reproduce the bug.
With patch bug is gone.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, thx for the quick fix.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
opac/svc/shelfbrowser.pl does not write http headers.
On a production server, this patch resolves a server internal error
(500):
Bad header= <div id="shelfbrowser">
I did not reproduce on my local instance, but this should be fixed.
Test plan:
Verify there is no regression on browsing a shelf (with "en" and translated
templates)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script, no regressions found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When OpacBrowseResults syspref is on, the detail page contains a results browser.
When search terms contains non-ASCII character, the search query is not well encoded in this browser.
This patch adds the URI-coding to search terms into session to avoid any encoding problem with diacritics and URI specific characters like ?,& ...
So that TT parameter 'busc' is already URI encoded and can be used to recreate seach URL.
Test plan :
- Set OpacBrowseResults on
- At OPAC, perform a search with a diacritique. For example 'déjà'
- Go to detail page of a result
=> You see browser under "Browser results"
- Click on "Back to results"
=> You get same results and same search term with correct encoding
Signed-off-by: Broust <jean-manuel.broust@univ-lyon2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug still present on master. I note that latin characters are taken by ISO-8859-1 encoding
(Perl's default) and that's why real UTF8 ones don't break (Perl notices they are UTF-8).
This patch simplifies the SQL query in Letters.pm for table
borrower_modifications.
It also addresses the only case this query is used in opac-memberentry.
An unused variable in Letters.pm is removed.
Test plan:
Enable selfregistration on opac.
Set verification by email to required in prefs too.
Self-register two new users.
Check the email notices generated.
Verify the new users with the tokens in their notice.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Much cleaner SQL
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Cleaner and works as described, no regressions found.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If the opacreadinghistory system preference is turned off it is still
possible to navigate directly to the OPAC reading history page if you
know the URL. This patch adapts the fix for Bug 10595 (OpacTopissue page
still accessible when system preference is turned off) for
opac-readingrecord.pl
To test, log in to the OPAC and test the following conditions:
- With opacreadinghistory, navigating directly to
/cgi-bin/koha/opac-readingrecord.pl should trigger a 404 error.
- With opacreadinghistory turned on there should be a working link to
"your reading history" in the left-hand sidebar menu.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and passes tests.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If the OPACPrivacy system preference is turned off it is still possible
to navigate directly to the OPAC privacy page if you know the URL. This
patch adapts the fix for Bug 10595 (OpacTopissue page still
accessible when system preference is turned off) for opac-privacy.pl
Because the OPACPrivacy preference is irrelevant if opacreadinghistory
is not turned on, the patch adds a check for both to determine whether
the page should be accessible.
Log in to the OPAC and test under the following conditions:
- OPACPrivacy is turned off, opacreadinghistory is turned off. Navigate
directly to /cgi-bin/koha/opac-privacy.pl. You should get a 404
error.
- OPACPrivacy is turned off, opacreadinghistory is turned on. Navigate
directly to /cgi-bin/koha/opac-privacy.pl. You should get a 404
error.
- OPACPrivacy is turned on, opacreadinghistory is turned off. Navigate
directly to /cgi-bin/koha/opac-privacy.pl. You should get a 404
error.
- OPACPrivacy is turned on, opacreadinghistory is turned on. A link to
both "your reading history" and "your privacy" should appear in the
left-hand sidebar menu. Both pages should work.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and qa script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This is the same issue as bug 12134.
Test Plan:
1) Add a manual restriction to a patron with expiration date in the past.
2) Go on the OPAC and connect (opac-user.pl)
3) Note the warning message
"Your account has been frozen until until XX/XX/XXXX ..."
4) Apply this patch
5) Repeat step 2
6) Note the warning message does not appear anymore
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described.
NOTE: If you set a debarment with date in the past in the GUI,
there will be no entry in borrowers.debarred and you won't be
able to see the problem. Set one with a date in the future and
then alter the date in borrower_debarments and borrowers.debarred.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This is the same issue as bug 12134.
Test Plan:
1) Add a manual restriction to a patron with expiration date in the past
2) Go on the OPAC and connect
3) Try to add an hold on a record (opac-reserve.pl)
3) Note the warning message
"Sorry, you cannot place holds because your account has been frozen ..."
4) Apply this patch
5) Repeat step 2
6) Note the warning message does not appear anymore
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Makes code cleaner, also works as described.
NOTE: If you set a debarment with date in the past in the GUI,
there will be no entry in borrowers.debarred and you won't be
able to see the problem. Set one with a date in the future and
then alter the date in borrower_debarments and borrowers.debarred.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch introduces the code lost in bug 10860 for the OPAC side.
Test plan:
Go on opac-readingrecord.pl and verify the tabs work as expected and the
"show all items" and "show 50 items" links.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The prefs language and opaclanguages used the comma to separate the
different values.
The new prefs OpacAdvSearchMoreOptions and OpacAdvSearchOptions should
do the same.
To reproduce the issue: update the language pref (or opaclanguages) and
refresh the page.
=> The pref values are not checked anymore and the language selection
(bottom of the page) does not appear.
Test plan:
1/ Verify that the behavior described above is fixed.
2/ Verify that the original test plan of bug 9043 still passes.
Note: The 2 OpacAdvSearchMoreOptions and OpacAdvSearchOptions pref
values are overwritten but the feature have just been pushed recently.
It should not affect a production environment.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I was able to reproduce the issue and verify that this patch corrected
the problem. Langage selection and OpacAdvSearchOptions worked
correctly.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch changes the way CanBookBeReserved() and CanItemBeReserved() return error
messages and how they are dealt with in the templates. This change makes it possible
to distinguish between different types of reservation failure.
Currently only two types of errors are handled, all the way to the user, from the CanItemBeReserved():
-ageRestricted
-tooManyReserves which translates to maxreserves
#############
- TEST PLAN -
#############
((-- AGE RESTRICTION --))
STAFF CLIENT
1. Find a Record with Items, update the MARC Subfield 521a to "PEGI 16".
2. Get a Borrower who is younger than 16 years.
3. Place a hold for the underage Borrower for the ageRestricted Record.
4. You get a notification, that placing a hold on ageRestricted material is
forbidden. (previously you just got a notification about maximum amount of reserves reached)
((-- MAXIMUM RESERVES REACHED --))
0. Set the maxreserves -syspref to 3 (or any low value)
STAFF CLIENT AND OPAC
1. Make a ton of reserves for one borrower.
2. Observe the notification about maximum reserves reached blocking your reservations.
((-- MULTIPLE HOLDS STAFF CLIENT --))
3. Observe the error notification "Cannot place hold on some items"
((-- MULTIPLE HOLDS OPAC --))
1. Make a search with many results, of which atleast one is age restricted to the current borrower.
2. Select few results and "Place hold" from to result summary header element.
(Not individual results "Place hold")
3. Observe individual Biblios getting the "age restricted"-notification, where others can be
reserved just fine.
Updated the unit tests to match the new method return values.
t/db_dependent/Holds.t & Reserves.t
Followed test plan. Works as expected and displays meaningful messages for the reason why placing a hold is not possible.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
We should use datatables for the courses and course items tables. This
will make the tables sortable and searchable from the client side.
Test Plan:
1) Apply this patch
2) View the courses in the OPAC, try sorting and searching
3) View the course details for a course, try sorting and searching the items.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signing off, but have a follow-up to address some missing stuff.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds 2 new sysprefs: OpacAdvSearchOptions and
OpacAdvSearchMoreOptions.
These sysprefs are multivalued and you can add or remove some elements on
the adv search page.
This patch allows to display/hide some entries in the advanced search
page at the OPAC.
On this way, it is possible to configure the search options to display.
Test plan:
1/
Fill OpacAdvSearchOptions with Item types and Languages.
Fill OpacAdvSearchMoreOptions with Item types, Languages and Location.
On the advanced search page, verify the Location is only displayed for
the "More options" view.
2/ Try different settings for these prefs
3/ Remove all entries for the OpacAdvSearchMoreOptions and verify that
the "More options" does not displayed additional options.
4/ Remove all entries for the OpacAdvSearchOptions and verify that the
"normal view" does not displayed any options.
Note that this patch only affects the bootstrap theme.
Signed-off-by: Koha Team Lyon 3 <koha@univ-lyon3.fr>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
C4::Dates->today returns a string formatted depending on the dateformat
syspref.
Before the original patch, SQLHelper managed both format (string
formatted and DateTime.
Now DBIX::Class only manages DateTime, so the call to NewSuggestion and
ModSuggestion should pass a DateTime object
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
With this patch, the subroutines NewSuggestion and ModSuggestion use DBIx::Class instead of C4::SQLHelper.
Moreover, the tests and the .pl have been adapted.
Test plan:
1) Apply the patch.
2) Execute the unit tests by launching :
prove t/db_dependent/Suggestions.t
3) The result has to be a success without error or warning :
t/db_dependent/Suggestions.t .. ok
All tests successful.
Files=1, Tests=91, 2 wallclock secs ( 0.05 usr 0.01 sys + 1.65 cusr 0.09 csys = 1.80 CPU)
Result: PASS
4) Log in the intranet, create a suggestion and verify the created suggestion.
5) Edit a suggestion from the intranet and verify the suggestion is correctly modified.
6) Log in the OPAC and verify you can add a suggestion.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test pass, suggestion created on staff and opac,
suggestion edited without problems, no koha-qa errors.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script:
Also tested:
- adding suggestion from staff and OPAC
- edit suggestion from staff
- deleting suggestion from OPAC
- changing to a normal status (email got created)
- changing to a custom status (SUGGEST_STATUS)
- display of custom status in OPAC
No problems found.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch makes opac/maintenance.pl run smoothly when the DB hasn't
been populated yet. It does so, by using C4::Templates::gettemplate
instead of C4::Auth::get_user_and_template as the maintenance page doesn't
need authentication checks at all, it should happen *before* any attempt
to check credentials.
To test:
- Backup and DROP your database
- Point your browser to the OPAC page
=> FAIL: An error is shown: "Cant's use an undefined value as an ARRAY..."
- Apply the patch
- Relad the page
=> SUCCESS: The maintenance page correctly shows.
We should now check the rest of the script's behaviour remains untouched:
- Reload your backed up DB
- Change your DB version number by hand to one version lower, like in:
> UPDATE systempreferences SET value="3.1700042" WHERE variable LIKE '%version%';
- Go to the OPAC
=> SUCCESS: Maintenance page shows as expected
- Recover the right version number, like in:
> UPDATE systempreferences SET value="3.1700043" WHERE variable LIKE '%version%';
- Set OpacMaintenance to Show on the staff client
- Reload the OPAC
=> SUCCESS: Maintenance page shows as expected
- Set OpacMaintenance to 'Don't show' on the staff client
- Reload the OPAC
=> SUCCESS: Normal OPAC shows
- Sign off :-D
Regards
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, fixes long existing bug.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In the OPAC if you view the MARC details for a title (and have
OPACXSLTDetailsDisplay enabled) there is a "view plain" link which displays the
output of opac-showmarc.pl. This is broken in master: fixed by this patch.
Test plan:
(1) Set OPACXSLTDetailsDisplay to default
(2) Do a search on OPAC, then display a specific biblio record
(3) Click on MARC view tab. Then click on 'view plain' link. Nothing is
displayed.
(4) Apply the patch. And refresh the MARC detail page.
(5) Click on 'view plain' link. Check that a plain text MARC record is
displayed.
Signed-off-by: Chris <chris@bigballofwax.co.nz>
Note: This makes a small change to C4::Templates::themelanguage so that
it works with .xsl files too (They live in the xslt dir)
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since the bootstrap OPAC's place hold interface doesn't use tables
there is no use for the colspan calculation being done in the script.
This patch removes it.
To test, place one or more holds in the OPAC and confirm that there are
no display problems. The OPAC error logs should show no associated
error.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No display problems, no related errors on log, no koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script, no regressions found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The OPAC's list of a logged-in user's tagged titles displays title and
author, which for some reason are combined in the script into one
variable. I can't see any reason to do it this way.
This patch modifies the script so that title and author are passed as
separate variables. In addition, subtitle is now passed as well.
To test you must log into the OPAC as a user who has tagged multiple
titles, at least one of which should have an author and at least one
with a subtitle. View the list of tagged titles and confirm that this
information is being displayed correctly.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To Test
1/ Edit the new systempreferences (ReplytoDefault and ReturnpathDefault)
2/ Optionally edit the branch the mail will be sent from, adding email addresses
3/ Send a list from the public (OPAC) interface
4/ Check that the mails have the correct From, Replyto and ReturnPath set
The rules are
If the values are set in the branch use that, else use the syspref
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>