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:
th,
.table-bordered>thead>tr:first-child>th {
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 the detail page of an item, then the MARC view.
Notice this table's headings are now styled with red text
6) Apply patch and refresh page
7) Your holdings table should now have red headings.
(You can delete the CSS from OPACUserCSS if you'd like.)
Sponsored-by: Catalyst IT
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Now that we have a check client-side, nothing prevents us from a smart guy to
bypass it and force an invalid password.
This patch adds two new subroutines to Koha::AuthUtils to check the
validity of passwords and generate a password server-side. It is used
only once (self-registration) but could be useful later.
Moreover the 3 different cases of password rejection (too leak, too
short, contains leading or trailing whitespaces) were not tested
everywhere. Now they are!
This patch makes things consistent everywhere and clean up some code.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Indeed if RequireStrongPassword is set we need at least 3 characters to
match 1 upper, 1 lower and 1 digit.
We could make things more complicated to allow minPasswordLength < 3
but, really, 3 is already too low...
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To validate password fields we need to use the validate jQuery plugin.
To make things reusable this patch adds a new include file
'password_check.inc' at the intranet and opac sides, it creates 3 new
validation methods:
- password_strong => make sure the passwords are strong enough according
to the values of the RequireStrongPassword and minPasswordLength prefs
- password_no_spaces => prevent passwords to be entered with leading or
trailing spaces
- password_match => make sure both password fields match
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1. Create a template club and disable public enrollment
2. Create a club and add it a patron
3. login at the opac with this patron
4. Note the borked clubs table
5. Apply this patch
6. Refresh the page
7. Table is fixed!
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>
This adds a new basket attribute (create_items) that can optionally be
set to override AcqCreateItem.
The following have been modified to reflect this (with the value of
create_items that causes them to behave differently in parentheses):
* Cancelling receipt of an order (receiving)
* Creating an order by hand or from MARC (ordering)
* Receiving an order (receiving)
* Showing orders with uncertain price (ordering)
* Showing orders (receiving)
* Showing acquisition details in the OPAC (ordering)
Test plan:
1) Create baskets with "Create items when:" set to ordering,
receiving, cataloging and unset.
2) Test each of the above for each of these baskets, verifying that
the basket-specific attribute overrides AcqCreateItem if set and
falls back to the syspref otherwise.
NOTE: A check of AcqCreateItem in opac-detail.tt was removed because it
was redundant; the code path in question cannot be triggered unless
create_items/AcqCreateItems is set to the correct value anyway.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Barbara Fondren <bfondren@roundrocktexas.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1) Ensure the useDischarge syspref is enabled
2) Check out an item to a borrower
3) Log in to the OPAC as this borrower
4) Click the 'ask for a discharge' link in the nav
5) Click the 'Ask for a discharge' link
6) Notice you cannot be discharged because you have checkouts
7) Apply the patch, click the 'ask for a discharge' link in the nav
8) Notice the link has been replaced with an appropriate error message
9) Attempt to force the discharge URL:
/cgi-bin/koha/opac-discharge?op=request
10) Notice the message and you cannot be discharged.
11) Confirm that when you check in your item, the discharge link shows
again and works as expected.
Sponsored-by: Catalyst IT
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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 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>
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>
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>
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>
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>
To test:
1 - Give a patron a fine of 1
2 - View opac fines tab, it shows as '1'
3 - Give patron a credit of '1'
4 - View opac fines tab, it shows as '1'
5 - Apply patch
6 - Both now show as '1.00'
Signed-off-by: Lisa Gugliotti <lisa@hchlibrary.org>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch tweaks some CSS in the OPAC to give the "Did you mean" block
better layout on smaller screens.
To test, apply the patch and process LESS files. Enable "Did you mean"
plugins for the OPAC in Administration.
Perform a search in the OPAC and confirm that the "Did you mean" block
looks correct. Resize your browser to various widths and confirm that
the block handles all sizes well.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch addresses template issues with the newly-added patron clubs
pages.
- Move Clubs tab out of second position in Circulation page tabs.
- Link patron name in enrollments list to the patron record
- Make page titles on some pages more specific
- Correct label "for" attributes so that it matches input id
- Correst style of buttons: Buttons in tables must be "btn-xs," all
Bootstrap buttons must have "btn-default."
- Correct "Edit" icons: Should be "fa-pencil"
This patch also revises the club template editing form to make it more
consistent with similar interfaces in Koha and (hopefully) make it more
clear.
To test, apply the patch and test adding clubs and club templates and
enrolling patrons in clubs via the staff client and OPAC. Confirm that
everything looks and work okay.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
