While PayPal is fairly universal, there is a plethora of online
payment system that are far more localized, servicing a single
country ( e.g. Bug 18968 ) or even a single city! Instead of
adding support for each and every one of these payment options
directly into Koha, it makes more sense to add the ability to
create online payment plugins.
Test Plan:
1) Apply this patch
2) Download and install the Kitchen Sink plugin version 2.1.1 or later
https://github.com/bywatersolutions/koha-plugin-kitchen-sink/releases
3) In the plugin options, enable the opac payments option
4) Create a patron with one or more fines
5) Log into the opac as that patron, note you now have the option
to pay online via KitchenSink ImaginaryPay
6) Make an online payment
7) Note the payment was processed correctly
Sponsored-by: Washoe County Library System
Signed-off-by: Kyle M Hall <kyle@gmail.com>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Awesome enhancement! I know we want to add at least one Norwegian
payment service at some point.
I followed the test plan and everything works as advertised. Turning
off the "opac payments option" makes the option dissappear cleanly
from the OPAC. I have *not* looked at the code or done any
considerations about security.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This enhancement just exposes the quantity field to the OPAC suggestions
form to permit the end user to enter this if they wish. The librarians
can of course override this quantity when they process the suggestion.
Test Plan (assuming using kohadevbox VM):
1) apply patch and turn on purchase suggestions
2) Go to http://localhost:8080/cgi-bin/koha/opac-suggestions.pl?op=add
and notice that there is now a quantity field available.
3) Make a purchasing suggestion using this form, including a quantity.
4) Log in as a member of library staff and go to Home › Acquisitions ›
Suggestions
5) Confirm that the previously entered suggestion is there, and that the
correct quantity appears in the "Acquisition information" section.
6) Edit the purchasing suggestion, change the quantity, save it and
check that the new quantity appears in the suggestion.
I've popped an ID attribute of "opac-suggestion-quantity" to the
surrounding <li> so that CSS can easily make this optional field
disappear (as suggested by cait on IRC).
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The HTML code was "text" instead of "password".
TEST PLAN
----------
1) 'Allow' PatronSelfRegistration system preference
2) Define the PatronSelfRegistrationDefaultCategory system preference (e.g. PT)
3) Open OPAC
4) Click 'Register here' on the right. (/cgi-bin/koha/opac-memberentry.pl)
5) Scroll to bottom
6) enter some passwords
-- visible
7) apply this patch
8) refresh page
9) repeat 5-6 as needed
-- passwords should not be visible while entering
10) run koha qa test tools
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
For calls to SCOUserJS, SCOUserCSS, OPACUserCSS, AllowSelfCheckReturns,
OpacFavicon, ShowPatronImageInWebBasedSelfCheck, SelfCheckoutByLogin
Sponsored-by: Catalyst IT
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 12691: [FOLLOW-UP] Follow-up patch
This patch fixes merge conflicts and fixes the problems in Comment 7
QA tools complain about missing bracket, will be fixed in next followup
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 12691: [FOLLOW-UP] Missing bracket
Patch adds bracket to template file (Comment 16)
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 12691: [FOLLOW-UP] Fixing some logic
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Patches have been squashed for readability and 1 removal occurrence of
display_patron_image has been reintroduced.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Log into OPAC, go to home page
2) Confirm that the text shows as 'RSS feed for (branchname) library
news' if single-branch library
3) Confirm text shows as normal for libraries with more than one branch
Sponsored-by: Catalyst IT
Signed-off-by: maricris <mlabancia@gmail.com>
Signed-off-by: anafe <anafeazuela@yahoo.com>
Signed-off-by: iflora <iflora@unimas.my>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Fixes misplaced columns introduced by previous patch and adds the "-" for phone
transport type.
To test:
1. Set SMSSendDriver system preference on
2. Go to intra and OPAC messaging preferences
3. By default you should see checkboxes for all messages for SMS
4. Ensure columns are not misplaced (pushing one column too much to the right)
5. Delete sms method from one of the messages in message_transports table
6. Observe that "-" is displayed instead of checkbox for that message for SMS
7. Repeat same for TalkingTechItivaPhoneNotification system preference.
By default it may not have transports in message_transports, so make sure
to assign some in order to have the checkboxes visible.
https://bugs.koha-community.org/show_bug.cgi?id=8692
Signed-off-by: Michael Andrew Cabus <michael@bywatersolutons.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 6726 had corrected the fact that when SMS is enabled the messaging table is missing a column.
Bug 6458 has broken this.
The SMS column is missing an else case with cell containing only "-" like other columns.
Test plan :
- set SMSSendDriver preference empty
- go to OPAC patron messaging
- column SMS should not be visible
- set SMSSendDriver preference not empty
- go to OPAC patron messaging
- column SMS appears with checkboxes
Signed-off-by: Michael Andrew Cabus <michael@bywatersolutons.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
Enable Coce and disable other image services
Load a list and not there are no covers
Apply patch
Load a list and note there are covers
https://bugs.koha-community.org/show_bug.cgi?id=15924
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
So that it can be styled alongside other tables in the OPAC.
To test:
1) Log into staff side
2) Find OPACUserCSS syspref and add the following CSS:
thead {
color: red;
}
3) Log into the OPAC
4) Go to your fines, your search history, your reading history etc -
notice all of these table's headings are styled with red text
5) Go to your messaging. Notice this table's headings are not styled
with red text
6) Apply patch and refresh page
7) Your messaging table should now have red headings.
(You can delete the CSS from OPACUserCSS if you'd like.)
Sponsored-by: Catalyst IT
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The file koha-tmpl/opac-tmpl/bootstrap/en/includes/openlibrary-readapi.inc
exposes template directives to translation. The only string that should
appear in .po from this file is "Open Library: "
To test:
- Apply patch
- Verify that code changes make sense
- Bonus test: create a new language 'aa-AA', verify in aa-AA-opac-bootstrap.po
that there is only the following string for openlibrary-readapi.inc:
msgid "Open Library: "
msgstr ""
NOTE: Followed a test plan similar to bug 18776 comment 3
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The file opac-tmpl/bootstrap/en/includes/masthead-langmenu.inc exposes following tt directive to translators:
"[%% IF ( ( opaclanguagesdisplay ) && ( ! one_language_enabled ) && "
"( languages_loop ) && ( OpacLangSelectorMode == 'both' || "
"OpacLangSelectorMode == 'top') ) %%] "
This patch fixes it.
To test:
- Apply patch
- Verify that language selector in OPAC (top of the page) works as expected
- Bonus test: create a new language 'aa-AA', verify that line above does not
show up in aa-AA-opac-bootstrap.po
NOTE: Followed a test plan similar to bug 18776 comment 3
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The file opac-tmpl/bootstrap/en/includes/authorities-search-results.inc
exposes template directives to translation where translators should not
be confronted with.
Example:
"[%% PROCESS showreference heading=seeals.heading linkType='seealso' "
"type=seeals.type authid=seeals.authid %%] "
To test:
- Apply patch
- Verify that Authority search in OPAC works as before
- Bonus test: create a new language 'aa-AA', verify that line above
does not show up in aa-AA-opac-bootstrap.po
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The file opac-tmpl/bootstrap/en/includes/item-status.inc exposes a template directive where translators should not be confronted with.
"%s %s [%%#- This include takes two parameters: an item structure and an "
"optional loan (issue) structure. The issue structure is used by course "
"reserves pages, which do not use an API to fetch items that populates item."
"datedue. -%%] %s %s %s %s "
This patch fixes new lines inside a tt directive (comment).
It is merely a string patch.
To test:
Verify that the code changes make sense.
(Bonus test: create a new language 'aa-AA', verify that line above does not
show up in aa-AA-opac-bootstrap.po)
NOTE: Followed test plan similar to bug 18776 comment 3.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The file opac-memberentry.tt exposes template directives to translation where
translators should not be confronted with.
Example from po file:
"%s [%% UNLESS hidden.defined('B_address') && hidden.defined('B_address2') && "
"hidden.defined('B_city') && hidden.defined('B_state') && hidden."
"defined('B_zipcode') && hidden.defined('B_country') && hidden."
"defined('B_phone') && hidden.defined('B_email') && hidden."
"defined('contactnote') %%] "
To test:
- Apply patch
- Verify that advanced search in OPAC the page 'your personal details'
behaves as before
- Verify that you can change values and submit an update request
- Create a new translation for a 'language' aa-AA (perl translate create aa-AA)
- Verify that template directives ar no longer exposed in aa-AA-opac-bootstrap.p
NOTE: Followed test plan similar to bug 18776 comment 3.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The file opac-advsearch.tt exposes template directives to translation where translators should not be confronted with.
Example in po file:
"[%% IF ( ( OpacAdvSearchOptions and OpacAdvSearchOptions.grep('itemtype')."
"size > 0 and not expanded_options ) or ( OpacAdvSearchMoreOptions and "
"OpacAdvSearchMoreOptions.grep('itemtype').size > 0 and expanded_options ) ) "
"%%] "
To test:
- Apply patch
- Verify that advanced search in OPAC behaves as before
- Create a new translation for a 'language' aa-AA (perl translate create aa-AA)
- Verify that template directives ar no longer exposed in aa-AA-opac-bootstrap.po
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Converted one INCLUDE directive to PROCESS; we are not changing variables here. (The PROCESS directive is slightly faster than INCLUDE because it avoids the need to localise (i.e. copy) the variable stash before processing the template.)
Removed one vim inserted letter i.
Error in [% IF ( XISBN.publicationyear ) _ ', ' _ XISBN.publicationyear %][% END %] The concatenation became part of the condition.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The file opac-detail.tt exposes a lot of template directives to translation where translators should not be confronted with.
Some examples from po file are:
$[% SUBFIELD.code %] [% SUBFIELD.value %]
%s [%% INCLUDE \"openlibrary-readapi.inc\" bib = { normalized_isbn => "
"normalized_isbn, lccn => lccn, normalized_oclc => normalized_oclc } %%]
See: [% IF ( nextTitle ) %][% nextTitle |html %][% ELSE %]next biblio[% END "
"%]
To test:
- Apply patch
- Do a search in OPAC that has more than 1 results
- Go to the detail page of one of the items found
- Verify that the details display as before and that you can
browse the results with Previous and Next
- In staff client, change OPACXSLTDetailsDisplay from 'default' to
empty for "no xslt" and repeat steps above
- In staff client, set HTML5MediaEnabled to 'OPAC' or 'OPAC and staff client'
- Verify that media catalogued in field 856 still work
- Create a new translation for a 'language' aa-AA (perl translate create aa-AA)
- Verify that template directives ar no longer exposed in aa-AA-opac-bootstrap.po
Followed test plan which works as intended
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The biblionumber parameter is sent by the user, we must escape all of
them to avoid XSS.
Fixes: Cross-site scripting OPAC pages
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This adds item type so we can do things with javascript.
To Test:
1.) Do a search on OPAC
2.) Inspect element to confirm item type is not present
3.) Apply patch
4.) Do a search on OPAC to confirm item type is present as a class
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This function only serves to check if the shelf name is not empty. It
does not even work since it incorrectly refers to f.addshelf (while it
should test #shelfname).
We can solve this and improve consistency by doing the same as in the
staff template with html5 required.
Test plan:
[1] Without this patch it was possible to add a list without a name in
OPAC (with js error: TypeError: f.addshelf is undefined).
[2] With this patch, verify that you cannot do this anymore.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If we we move from Private to Public or vice versa, this should reflect
on the Anyone remark from the first patch.
If we go back to a private list without shares, we should show it.
Handled in a js sub AdjustRemark, triggered by onchange of the category
combo or the permission combo.
Test plan:
[1] Edit a private list without shares in OPAC. Toggle category and/or
permissions. Is the remark shown or hidden accordingly?
Note: Include a test with OpacAllowPublicListCreation enabled.
[2] Edit a shared list or public list in staff. Toggle category/permissions.
You should never see the remark.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is a follow-up of report 18228 that simplifies the permissions for
lists. It reapplies the idea behind bug 10865 by adding a remark next to
the Anyone permission if it is not actually effective. A next patch will
make it behave dynamically.
Note: The Anyone permission is not relevant if it is a private list that
has no shares. Note that looking at the prefs OpacAllowPublicListCreation
and/or OpacAllowSharingPrivateLists is not decisive. You should look at
list permissions and shares in the database; turning off the Sharing pref
does not automatically remove all shares in the system. It only blocks
creating new shares.
We only need changes in opac-shelves.tt and virtualshelves/shelves.tt.
Test plan:
[1] Verify that you see the remark now in OPAC and staff.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Zebra doesn't care about cases, but ES does and default mapping is
'control-number'
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
See MARC specification.
Note that we have a preceding text before all 776s too.
Test plan:
[1] Set field 776 ind2 to 8. And add text in $i.
[2] Look for this text on OPAC detail and staff detail.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Felix Hemme <felix.hemme@thulb.uni-jena.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Adds code to opac and staff detail XSLT in order to show 776$t (or $a) and
a link based on 776$w (record control number). $w should be in the form:
(MARCOrgCode)Record-number
For instance: (NL-AmRIJ)12345
Note: You should have enabled default opac/intranet XSLT view.
Test plan:
[1] Add two 776s (one with $t and $w and one with $t only)
[2] Verify that you see "Additional physical formats" on opac-detail. Does
the link for $w work?
[3] Check intranet detail too.
[4] Empty 776$t and put text in $a. Check detail page again.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Felix Hemme <felix.hemme@thulb.uni-jena.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes a few corrections:
- Use 'e.preventDefault()' instead of 'return false' in changed
sections.
- Modify the event handler on checkboxes to successfully handle the
un-check action as well as the check action. (QA comment 5).
To test, follow the original test plan.
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
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>
To test:
1) Apply patch and add one or more items to your cart
2) Confirm that clicking the following things still works as expected:
- more details
- brief display
- send
- download
- print
- select all
- clear all
- selecting by clicking checkbox
- remove title
- add title to list
- place hold
- add tag
- empty and close
Sponsored-by: Catalyst IT
Followed test plan, works as expected. Resolves issue with two
print dialogues from Bug 18544.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In OPAC password recovery form autocomplete is not disabled.
So when login or email is entered, it is saved in browser input history for autocomplete.
This is a major issue for OPAC on computers with public access.
This patch adds autocomplete off on forms.
Test :
- Enable system preferences OpacPasswordChange and OpacResetPassword
- Go to OPAC
- Be sure to not be logged in
- Click on "Forgot your password?"
- Enter a loggin and email and Submit
=> Without patch there is an autocompletion with values you entered
=> With patch there is no autocompletion
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This include file is terribly wrong, it's called from different places
that do not set the same flag.
The status from detail and result page might be different from the one
display on the course reserve table.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Values from the items, biblio and biblioitems tables are used in the template,
so we need to pass all of them to the template, but separately.
That way we easily see which field from which table we are displaying.
Test plan:
Create a course reserve and add items.
Correct information must be displayed on the detail page of the course
reserve, on staff and OPAC interface.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To reproduce:
- Create 3 Accounts, login names are test01, test02, test03, Email is the same
for all.
- Go to OPAC -> Password recovery and indicate E-Mail only
- You will get an email for only one of the accounts above.
To test:
- Apply patch, restart memcached and plack
- Go to db, delete from borrower_password_recovery;
- Try steps above to reproduce. You will get an error message:
Account identification with this email address only is ambiguous.
Please use the field 'Login' as well.
- Verify that other cases work as before (provide valid / invalid login only,
provide valid email for an existing account, provide unknown email, provide
both login and email with all combinations of valid / invalid)
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 16711: (QA-followup) Use count directly
See comment # 13
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The two new columns as mentioned in the commit message of the table
revision must be used in the codebase now.
Highlighting some changes in Koha::VirtualShel[f|ves]:
[1] Additional methods is_public and is_private.
[2] Method add_biblio did not check permissions. Does now. No impact on the
interface, but one call in the unit test was affected.
[3] Method remove_biblios is signficantly simplified. Removed a FIXME.
[4] Method can_biblios_be_removed now redirects to can_biblios_be_added.
A followup report may deal with unifying those routines.
[5] Condition in get_some_shelves changed.
[6] The reference to allow_add in get_shelves_containing_record can simply
be removed.
opac-shelves.pl and shelves.pl now pass the default setting of Owner only
to the template.
Templates shelves.tt and opac-shelves.tt now include the new permission
field with three choices as mentioned in the table revision patch.
opac-addbybiblionumber.pl and addbybiblionumber now need a check on
allow_change_from_owner; search conditions slightly adjusted to the new
permission scheme.
Test plan:
When we refer to visibility in the test plan, please check the Add to-combo
on opac search results and staff results. And check opac-addbybiblionumber
by clicking Save to Lists from opac results.
The step 'Check delete' means: open the list in opac and check if you see
the Delete button below the entries (only check, do not delete).
[ 1] Create private list I01 (perm=Owner)
[ 2] Check visibility: Seen.
[ 3] Add a book. (Change by owner should be allowed.)
[ 4] Check delete: Yes.
[ 5] Edit list I01, set perm=Nobody
[ 6] Check visibility: Not seen.
[ 7] Check delete: No.
[ 8] Share list I01 with another patron.
[ 9] Check visibility for the other patron: Not seen.
[10] Check delete for the other patron: No.
[11] Change permission of list I01 to Anyone (by owner).
[12] Check visibility for the other patron: Seen.
[13] Let other patron add a book (change is allowed).
[14] Let owner delete the same book again (change allowed).
[15] Create public list U01 (perm=Owner)
[16] Check visibility: Seen.
[17] Add a book. (Change by owner should be allowed.)
[18] Login as other user. Check visibility: Not seen. Check delete: No.
[19] Change permission of U01 to Nobody (by owner)
[20] As owner: Check visibility: Not seen. Check delete: No.
[21] As other user: Check visibility: Not seen. Check delete: No.
[22] Create public list U02 (perm=Anyone)
[23] Add a book by owner.
[24] Delete the same book by other user. Add another book.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Following the idea behind bug 10865, we are only showing the permissions
when the list is shared or public.
Adding a simple test in opac-shelves here.
Note 1: Since the owner can always add or delete entries, the permissions
will not be relevant anymore for a strictly private list.
Note 2: Staff view always shows the permissions. This could have been
changed here too, but that change is far less urgent (bug 10865 did not
touch staff view and bug 18228 will rearrange permissions anyway).
Test plan:
[1] Verify on OPAC that you see the permissions for a private list with
shares or a public list. And you do not see them for a private list
without shares.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
If you have disabled the pref OpacAllowPublicListCreation, your users are
not able to edit the list permissions for private/shared lists.
For a private list they may only be theoretically relevant, but for a shared
list they are relevant.
Since we do not always know the history of a list (has it been public or
shared, does it contains entries from other users) and therefore permissions
are even relevant for a currently private list, we should just allow editing
these permissions.
Test plan:
[1] Do not yet apply this patch.
[2] Disable OpacAllowPublicListCreation.
[3] Create a private list in OPAC. Edit the list. Verify that you do not
see the permission combo boxes.
[4] Apply this patch. Edit the list again. Do they appear now?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Works as advertised.
The button to cancel a club enrollement is labelled with 'Cancel'. That is ambiguous and translates e.g. in German to 'Abbrechen' which can lead to
mistakes.
To test:
- Apply patch
- Enroll a patron to a club
- Enable public enrollment in OPAC
- Verify that the button to cancel enrollment in both OPAC and staff client
reads 'Cancel enrollement' (instead of 'Cancel' without patch)
(The button appears on the patron's detail pages in OPAC and staff client)
Amended for comment #4 / mv
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
Read the changes and make sure they make sense
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Two files av-build-dropbox.inc has linebreaks inside template directives,
exposing internals (comments and tt code) to translations as mentioned
in initial comment.
Translators should not be confronted with such interal code.
This patch fixes it.
To test
- Verify, that code changes make sense and have no more line breaks insied
tt directives.
- Run QA tools in newest version (checking for line breaks inside tt
directives)
- Bonus test: Create a "language" aa-AA (perl translate create aa-AA
from folder misc/translator, verify that lines mentioned above do
no longer appear in aa-AA-staff-prog.po and in aa-AA-opac-bootstrap.po
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
OPAC password recovery allows to find out which email address belongs to an account. An attacker could systematically guess login names. If they hit an existing one, OPAC displays a message like:
An email has been sent to "xxx@yyy.zz".
Having a combination of login name and email, attackers could use the information e.g. for phishing or other personalized actions.
To reproduce:
- Enable OPAC password recovery (syspref OpacResetPassword)
- 'Guess' a login name e.g. by using a common pattern like ptester for Peter Tester
- If such account exists, you get to know the related email address
This patch removes the email address from the success message. Additionaly, it changes
wording to address Bug 18570 ('will be sent' instead of 'has been sent')
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Simplified the wording. "Will be sent shortly" is used elsewhere too.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds some formatting to the error message a patron receives
when there are renewal failures in the OPAC.
This is pretty much the least which could be done to address this
problem. However, I don't think the issue can be fixed without
re-thinking how renewals are processed. Sending error messages back to
opac-user.pl via URL parameter isn't flexible enough.
To test, apply the patch and attempt to renew multiple items in the OPAC
which cannot be renewed for some reason, for instance because they have
been renewed too many times. The error messages should appear in a list
rather than strung together in one long block of text.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patches moves the call number up to be under the library name, so
it is equivalent to the staff client
To test:
1) Go to the detail page of a biblio with subscriptions in the staff
client
2) Notice callnumber sits under the library name
3) Go to the detail page of the same biblio in OPAC
4) Notice callnumber is not in the same order
5) Apply patch, refresh page
6) Notice callnumber is now in same order
Sponsored-by: Catalyst IT
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To prevent brute force attacks on Koha accounts, staff and opac, we need to
implement an account lockout process to Koha.
After a number of failed login attempts a users account would become locked.
The user would then need to use the reset password functionality to send a reset
token to their email account. After a successful password reset the lockout flag
would be removed.
The number of failed login attempts before lockout is configurable using a new
system preference 'FailedLoginAttempts'.
How does it work?
When a patron enter an invalid password, the borrowers.login_attempts value
for this patron is incremented. When this value reach the value of the
pref FailedLoginAttempts, the password comparison is not done and the
authentication is rejected.
This login_attempts field is reset when a patron correctly logs in. When
the account is locked the patron has to reset his/her password using
the OpacResetPassword feature or ask a staff member to generate a new
password.
If the pref is not set (0, or '') the feature is considered as disabled,
but the failed login attempts are stored anyway.
Test plan:
0/ Apply patch and execute the update DB entry
1/ Switch on the feature by setting FailedLoginAttempts to 3
2/ Use an invalid password to login at the staff or OPAC interface
3/ After the third consecutive failures, you will be asked to reset your
password if OpacResetPassword is set, or contact a staff member
4/ Switch on OpacResetPassword and reset your password
5/ Confirm that you are able to login
6/ Play with the different combinations
QA details: The trick happens in C4::Auth::checkpw, to make things clear
I had to create a return value (note the awesome name: @return) and
replace the 3 successives if statements with elsif. Indeed if one of
the condition is reached, it will return inside the given block.
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Janet McGowan <janet.mcgowan@ptfs-europe.com>
Signed-off-by: Jonathan Field <jonathan.field@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
