Code and variables to deal with the update child feature are not
centralized but copied/pasted in several scripts. Which leads to issues
obsviously (bug 20805 for instance).
Moreover the strings used by the templates are also in several template
files (or .inc)
To deal with that this patch introduces the idea to create 1 .inc file
per .js file
Here we have members-menu.inc for members-menu.js
Test plan:
- Remove all your adult categories (categories.category_type='A')
- Create a patron with a child category
- Try to update to adult category
=> The entry does no longer appears! (This is a change in the behaviour)
- Create one adult category
- Update to adult category
=> There is a JS confirmation message, if you accept the patron will
be updated to the adult category
- Create (at least) another adult category
- Create another child
- Update to adult category
=> No more confirmation message but a popup to select the adult category
- Pick one
=> The patron has been updated to the adult category
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch modifies the patron edit process so that "Housebound roles"
can be edited as a separate step.
To test, apply the patch and open an existing patron's detail page
(moremember.tt). Test the "edit" links for 'Housebound roles' and
'Additional attributes and identifiers' and confirm that each opens its
own edit page, and saving changes works correctly.
Signed-off-by: Cab Vinton <bibliwho@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch modifies the patron edit page so that the label for an
organization name is "Name" instead of "Surname."
To test, apply the patch and edit both an institutional patron and a
regular patron. Confirm that the name/surname label is correct in each
case.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Having to write [% KOHA_VERSION %] for each url is bad because:
- It's easily forgettable when adding new <script> or <link>
- It prevents grep'ing for the full filename
- It violates the DRY principle
- If at some point we want to change the "force js and css reload"
mechanism, it will be tedious
This patch:
- adds a Template::Toolkit plugin that generates <script> and
<link> tags for JS and CSS files, and inserts automatically the Koha
version in the filename
- use the new plugin to remove all occurences of [% KOHA_VERSION %]
- remove the code that was adding KOHA_VERSION as a template variable
Test plan:
1. Apply patch
2. Go to several different pages in Koha (opac and intranet) while
checking your browser's dev tools (there should be no 404 for JS and
CSS files, and the Koha version should appear in filenames) and the
server logs (there should be no "File not found")
3. `git grep KOHA_VERSION` should return nothing
4. prove t/db_dependent/Koha/Template/Plugin/Asset.t
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
0) Confirm that email validation is not working in add/edit patron form
1) Apply the patch
2) Edit/add patron, the e-mail validation should be working now
3) Ensure the password validation is still working (use test plan from
bug 19908)
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>
My patch moving patron-related templates' javascript to the footer left
out a script from the patron entry template which is required if the
patron header search menu is going to work.
To test, apply the patch and go to Patrons -> New patron.
Clicking the [+] link in the "Search patrons" header search form should
expand the advanced search options.
Test that the page's toolbar still "floats" correctly when you scroll
the page.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
0) Do not apply the patch, note the password field is always required
1) Apply the patch
2) Try to add and edit patron with and without "password" in BorrowerMandatoryField, it should always respect this setting
3) Use "Change password" button in patron toolbar, the password field
should be never required here - when leaved blank, the password is
unchanged
4) Play with minPasswordLength and RequireStrongPassword preferences,
to ensure they work as expected
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This has been caught by selenium test, the category name must be
displayed when we are creating a new patron, and so does not depends on
the "patron" variable
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In order to simplify and make uniform the code, the controller scripts send
a Koha::Patron object to the templates instead of all attributes of a patron.
That will make the code much more easier to maintain and will be less
error-prone.
The variable "patron" sent to the templates is supposed to represent the
patron the librarian is editing the detail.
In the members module and some scripts of the circulation module, the
patron's detail are sent one by one to the template. That leads to
frustration from developpers (making sure everything is passed from all
scripts) and to regression (we got tone of bugs in the last year because
of this way to do).
With this patch set it will be easy access patron's detail, passing only
1 variable from the controllers.
Test plan:
Play with the patron and circulation module and make sur the detail of
the patron you are editing/seeing info are correctly displayed.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch modifies the staff client patron module templates so that
JavaScript is included in the footer instead of the header.
This patch touches a lot of files because the changes are all
interdependent, affecting a couple of module-wide include files.
To test, apply the patch and test the JavaScript-driven features of the
modified templates: All button controls, DataTables functionality, tabs,
etc.
Patrons -> Patrons home, patron search results
-> Manage pending modification requests
-> Patron detail page
-> Edit patron
-> Set guarantor
-> Fines
-> Account, Pay fines, Create manual invoice, Create manual
credit
-> Print receipts for different kinds of charges
-> Routing lists
-> Circulation history
-> Holds history
-> Notices
-> Statistics
-> Files
-> Purchase suggestions
-> Discharges
-> Housebound
-> Set permissions
-> Change password
-> Print summary, slips, and overdues
-> Update child to adult patron type
Patron toolbar and patron search bar operations should work correctly on
all pages.
This patch also updates the template for searching the Norwegian
national patron database, but it has NOT been tested.
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Zoe Bennett <zoebennett1308@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Changes the appearance of the cardnumber entry field in memberentrygen.tt
The "Leave empty for autocalc" message has been moved to the hint div
under the input field. If AutoMemberNum and BorrowerMandatoryField
interfere with each other, the auto calc hint is replace by a warning
telling the user that auto calc has been disabled.
Cardnumber should now correctly appear as mandatory if marked as such
in BorrowerMandatoryField.
Test plan:
0] Apply patch
1} Disable AutoMemberNum, remove cardnumber from BorrowerMandatoryField
2) Edit or create a patron, scroll down to cardnumber input field
Hint is some form of "Cardnumber must be this long"
Cardnumber input is not marked as required
There is no mention of auto calc
3> Enable AutoMemberNum
Hint includes "Leave empty for auto calc" message
4~ Add cardnumber to BorrowerMandatoryField
Hint warns you that your sysprefs are conflicting.
Cardnumber input is marked as required
5: Disable AutoMemberNum
Hint is some form of "Cardnumber must be this long"
Cardnumber input is marked as required
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Technically a kid from your library group could have a guarantor
attached to another
group of library, let's deal with this case.
Test plan:
- Create a kid from your library group
- With a superlibrarian staff user create a guarantor that is outside of
the group of
libraries of the kid
- Login with a limited staff user and confirm that on the patron detail
page you do not
see the link to the guarantor detail page.
Note that you see the firstname and surname of the guarantor
Q. should it be hidden?
Signed-off-by: Signed-off-by: Jon McGowan <jon.mcgowan@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
From where patrons it's about patrons, we do not want to display the libraries
from all the system, but only the ones from the group.
Test plan:
- See the overdues (circ/overdue.pl) and make sure you can only see overdues from
patrons part of your group (do not forget to test the CSV export).
- Search for patrons, the 'library' filters (headers and left side) should only
display libraries from your group
- Search for article request by patron's library: only the libraries from your
group should be displayed
Signed-off-by: Signed-off-by: Jon McGowan <jon.mcgowan@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
Login with a patron that only have the 'edit_borrowers' permission.
You should be able to access patron's information of patrons inside of your group.
Technical note:
Before this patchset the borrowers permission module contains only 1 permission 'edit_borrowers'.
That meant
borrowers => 1
and
borrowers => '*'
had the same behavior.
Moreover, now that we have 2 permissions, 'CAN_user_borrowers' is set when all
permissions of 'borrowers' are set.
We need to update the different occurrences of these tests.
Signed-off-by: Signed-off-by: Jon McGowan <jon.mcgowan@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
1. Go to the "Details" vertical tab of a patron.
2. Click the "Restriction" tab in the bottom and add a manual restriction.
3. Verify a creation date is visible.
4. Edit the same patron.
5. Under "Patron restrictions" verify the creation date of the listed
restiction is visible.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Charles Farmer <charles.farmer@inLibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Optionally hide SMS provider field in patron modification screen with
BorrowerUnwantedField system preference.
To test:
1. Apply patch
2. Append BorrowerUnwantedField with sms_provider_id and save changes
3. Go to patron modification screen in staff client
4. Observe the SMS provider selection is now hidden
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It seems better to display the warning if the user tries to enter too
many characters in the input.
Test plan:
With max=16
1. Copy/paste a string with 15, 16 and 17 characters
2. Enter a cardnumber of 15, 16, 17 characters
The warning should be displayed only the input overflows
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch displays a message if the user tries to enter more than the
max number of characters for a cardnumber.
To test:
1) Apply patch and go to Patrons -> New patron
2) Scroll down to Card number
3) Put in any characters. Notice that when you have entered the max
number of characters, you are unable to type any more.
4) Click out of the text field (so it loses focus), the error message will show up.
5) if you backspace some characters and click out of the text field
again, the message should disappear
Sponsored-by: Catalyst IT
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: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The form provided on top of the page if Koha find a duplicate
patron is not closed. This cause some trouble.
Test plan:
- Edit the syspref IntranetUserJS and type the following code:
"$(document).ready(function() {
$("#memberentry_library_management").insertBefore("#memberentry_identity");
});"
- create a patron so that Koha will warn you about a duplicate one,
- click on "Not a duplicate. Save as new record",
- you should get error(s) about empty field(s).
Note that now, the library management part's fields are empty or
reset to default
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@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 patron category with the dateexpiry value of 29/9/2017
2. Create a patron user from that patron category (which I'll refer to as patron A) with the date
expiry value of 1/10/2017 and submit the form
3. Notice that the manual dateexpiry you have submitted is correctly
displayed
4. Create a duplicate patron with the same firstname and surname and
patron A, and set the date expiry value of 1/10/2017 and submit the form
5. The form displays a duplicate patron message. Notice that the dateexpiry input box is empty now
6. Select the new member (not a duplicate member) option in the
messagebox
7. The form successfully submits and notice that the date expiry value
displayed is that of the patron category (i.e. it is 29/9/2017) not the
dateexpiry value of 1/10/2017 that you manually set for this patron
8. Apply patch
9. Repeat step 4
10. The form displays a duplicate patron message. Notice the dateexpiry input box still
contains the value you entered which is 1/10/2017. Select the new member
(not a duplicate member) option in the messagebox
11. The form successfully submits and notice that the date expiry value
displayed is 1/10/2017 that you manually set for this patron
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
1. Hit /cgi-bin/koha/members/memberentry.pl?op=add&guarantorid=xx<script>alert('amit')</script>
xx - is a guarantorid
2. Notice the java script is executed.
3. Apply patch.
4. Reload page, and hit the page again /cgi-bin/koha/members/memberentry.pl?op=add&guarantorid=xx<script>alert('amit')</script>
xx - is a guarantorid.
5. Notice it is no longer executed.
NOTE: I had to test in Microsoft Edge, because Chrome was blocking XSS for me.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 18551 moves the way the filters are displayed and so the position of
the patron toolbar must be recalculated.
Test plan:
Edit patron's detail
open the filters, scrolldown
close the filters, scrolldown
=> The toolbar must be correctly placed
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Translation for memberentrygen.tt exposes a lot of template directives
like the following:
[% UNLESS opduplicate %][% othernames | html %][% END %]
Translators should not be confronted with such code internals.
To test:
- Review code changes
- Verify that creating / editing patrons works as before
- Bonus test: Create a "language" aa-AA (perl translate create aa-AA
from folder misc/translator, verify that lines like mentioned above
do no longer appear in aa-AA-staff-prog.po
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Fill out some fields in quick add
2 - Switch to full form and clear fields
3 - Switch back and fields are still populated
4 - Fill a field in long form
5 - Switch to quick add and clear it
6 - Save
7 - Value set in 4 is saved
8 - Apply patch
9 - Repeat 1-6 - values should be cleared and not saved
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1 - Add password to BorrowerMandatoryField
2 - View quick add form
3 - See confirm password twice
4 - Apply patch
5 - See confirm password once
6 - Add password to QuickAddFields
7 - Confirm one confirm field
8 - Remove password form BorrowerMandatory field
9 - Confirm there is one confirm field and password fields are not
required
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The function that switches between quick add/fulll form assumes labels
are followed by values - patron_attr don't follow this pattern. This
patch just moves the hidden input field
To test:
1 - Have some patron attributes (with/without auth values set)
2 - Add them to QuickAddFields (patron_attr2 for example)
3 - view quick add form and set some values
4 - Switch to full form, values not transferred
5 - Switch to quick add, view values, save
6 - Values are not saved :-(
7 - Apply patch
8 - Repeat 3 - 5
9 - Values are transferred and saved :-)
Signed-off-by: Peggy Thrasher <p.thrasher@dover.nh.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Not the opac because we do not want the patron to modify it, they won't
be necessary translated.
Sponsored-by: Orex Digital
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Currently the card number is generated when the user enters the patron creation form. This creates a problem of concurrency - when two or more simulataneous users are registering members, the error "card no. in use" can occur.
This change moves the card number generation to occur after the "Save" button is pressed.
Changes:
-C4/Members.pm:
Added code to fixup_cardnumber,If the cardnumber is blank and "autoMemberNum" ON.
-koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt:
Added code to display "leave blank for auto calc during registration" in cardnumber label in patron registration form only if "autoMemberNum" ON.
-members/memberentry.pl:
Added code to get weather or not "autoMemberNum" is on or off and removed fixup_cardnumber generation.
Test cases:
-If "autoMemberNum" ON:
->In blank case, must generate auto card number in simulataneous users.
->If user entered, check for unique card number.
-If "autoMemberNum" OFF:
Must work normal.
Followed test plan, works as expected.
Note: Syspref PorrowerMandatoryField must not include cardnumber, otherwise
you can not save. Maybe that should be mentioned in the comment for
syspref autoMemberNum.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch updates the guarantor form to work with the quick add form
To test:
1 - Quick add a 'Kid' patron (or other patron type that may have
guarantor)
2 - Verify form appears as expected
3 - Test that you can add a patron manually or using selector
4 - Test that deletion works as expected
5 - Test 3 and 4 from the full version of the form
6 - Save or cancel and add a new patron using the full form only
7 - Verify that adding/deleting guarantor works with no errors
8 - Sign off
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
* koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt:
Place housebound role form inside the 'step 4' section.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt:
Add 'step 4' edit button for housebound role.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
There are certainly hundred of places where they are not escaped...
Test plan:
Create a patron with "Arun <script>alert('code injection');</script>" in
some of the fields.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In order to remove accessibility issues due to the readonly attributes
on date inputs, this patch will remove them and introduce a javascript
validation on them.
This patch is not perfect for some reason:
I didn't manage to force the user to select a valid date. One solution
would be to reopen the datepicker plugin until a valid date is inserted.
But it could be annoying for users (and for me: I did not manage to
implement this solution).
You will note that input is emptied if the date is not valid. This is a
quick and efficient solution to prevent submitting invalid date and make
Koha explodes. A proper solution would be to implement the check server
side send a friendly message to the user.
Test plan:
For all inputs, try an invalid and a valid date.
1/ Debar a patron
2/ On the checkout tables (circulation and moremember), add a renewal
due date (at the bottom of the tables)
3/ On the checkout page, specify a due date
4/ On the return page, specify a return date
5/ On the invoice page (acquisition module), enter a shipment and
billing date
6/ On the invoice search page (invoices.pl) use filters shipment and
billing dates
7/ On the offline circ page, specify a due date
8/ On the edit patron page (memberentry), add a debarment
9/ On the reserve page (reserve/request.pl), use the date inputs to
suspend until a defined date
10/ Edit patrons in a batch (tools/modborrowers.pl) and use the
registration and expiry date inputs
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch fixes sentences splitting in file
koha-tmpl/intranet-tmpl/prog/en/modules/members/member.tt
Fix is done with a new .inc file because the code is the same as in
koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt
To test:
- Carefully review code changes
- Test on a fresh install without example data (or save database
and test with empty tables 'branches' and 'categories')
- Go to Home > Patrons (members-home.pl)
- Verify that a warnings appears aubout missing libraries and patron
categories
- Try to add a new patron (memberentry.pl)
- Verify that the same messages are triggered
- Verify that messages disappear as appropriate as soon as a library and
a patron category are defined.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Note: Filed Bug 17093 for JS error on patron entry form.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If an attacker can get an authenticated Koha user to visit their page
with the url below, they can change patrons' passwords or other
patrons'details
members/memberentry.pl?op=save&destination=circ&borrowernumber=3435&password=ZZZ&password2=ZZZ&nodouble=1
Test plan:
Trigger
members/memberentry.pl?op=save&destination=circ&borrowernumber=42&password=ZZZ&password2=ZZZ&nodouble=1
=> Without this patch, the password will be updated
=> With this patch applied you will get a crash "Wrong CSRF token" (no
need to stylish)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: removed the commented use Digest::MD5-line.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This subroutine just reads the content of a pref, split it, add an
empty string and returns.
It is not really useful and the code in the script (memberentry.pl) uses
the only occurrence of CGI::popup_menu
Let's remove it and build the dropdown list in the template.
Test plan:
1/ Empty BorrowersTitles, edit a patron and confirm that the "Salutation"
does not appear
2/ Fill BorrowersTitles with "Mr|Mrs|Miss|Ms", edit a patron and confirm
that the "Salutation" dropdown list is correctly filled.
The default option should be selected if you are editing a patron with a
title defined.
This should also be tested at the OPAC.
Followed test pan, works as expected in Staff and OPAC
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
New feature: provide granular means to configure warnings about items
that have been issued to a particular borrower before, according to
their checkout history.
- Global syspref ('CheckPrevCheckout'), set to 'hardno' by default,
allows users to enable this feature library wide.
- Per patron category pref allows libraries to create overrides per
category, falling back on the global setting by default.
- Per patron pref allows switching the functionality on at the level
of patron. Fall-back to category settings by default.
* Koha/Patron (wantsCheckPrevCheckout, doCheckPrevCheckout): New
methods.
* C4/Circulation.pm (CanBookBeIssued): Introduce CheckPrevCheckout
check.
* admin/categories.pl: Pass along checkprevcheckout.
* koha-tmpl/intranet-tmpl/prog/en/modules/admin/categories.tt: Expose
CheckPrevCheckout per category setting.
* koha-tmpl/intranet-tmpl/prog/en/modules/preferences/patrons.pref:
Expose CheckPrevCheckout syspref.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt:
Expose per patron CheckPrevCheckout preference.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt: Expose
per patron CheckPrevCheckout preference.
* koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tt: Add
'CHECKPREVCHECKOUT' confirmation message.
* installer/data/mysql/kohastructure.sql: Modify structure of
'categories', 'borrowers', 'oldborrowers'.
* installer/data/mysql/sysprefs.sql: Add 'CheckPrevCheckout'.
* installer/data/mysql/atomicupdate/checkPrevCheckout.sql: New file.
* t/db_dependent/Patron/CheckPrevCheckout.t: New file with unit tests.
Test plan:
- Apply patch.
- Run updatedatabase.
- Regenerate Koha Schema files.
- Run the unit tests.
- Verify 'CheckPrevCheckout' is visible in Patrons sysprefs and can be
switched to 'hardyes', 'softyes', 'softno' and 'hardno'.
+ Check out previously checked out items to a patron, checking the
message appears as expected.
- Verify no 'Check previous checkouts' setting appears on the borrower
category pages if the syspref is set to a 'hard' option.
- Verify 'Check previous checkouts' setting appears on the borrower
category pages and can be modified per borrower category.
+ Issue previously issued items to a borrower, checking the message
appears as expected (This setting should override the default
setting if that is set to a 'soft' option).
- Verify no 'Check previous checkouts' setting appears on the individual
borrower pages if the syspref is set to a 'hard' option.
- Verify 'Check previous checkouts' setting appears on individual
borrower pages and can be modified.
+ Issue previously issued items to a borrower, checking the message
appears as expected (This setting should override the category
setting and the default setting if the latter is set to a 'soft'
option).
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: Kyle M Hall <kyle@bywatersolutions.com>
Changes the value of the "comment" column in "borrower_debarments" table
from "Restriction added by overdues process yyyy-mm-dd hh:mm:ss" to
"OVERDUE_PROCESS yyyy-mm-dd hh:mm:ss" in the overdue_notices.pl. Then in
the templates "moremember.tt", "circulation.tt", "memberentrygen.tt",
"opac-reserve.tt" and "opac-user.tt" the value of "comment" is
check, if it's an automatical comment due to overdue process it'll
write "Restriction added by overdues process yyyy-mm-dd hh:mm:ss",
then if there is a customizable comment it will be written without
modification. Like this, the comment "Restriction added by overdues
process" is written in the po files and can be translated later.
To test:
1) create a patron with automatical restriction due to overdue process;
2) apply patch;
3) run misc/cronjobs/overdue_notices.pl;
4) verify if the comment "Restriction added by overdues process" is well
written and translatable on the following page :
- opac patron home page (opac-user.tt);
- opac item reservation page (opac-reserve.tt);
- pro patron page (moremember.tt);
- reservation item for a patron (circulation.tt, memberentrygen.tt);
5) try to translate the comment in po files;
6) sign off.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When quick adding a new patron, both button are in the DOM and the
second button has a margin-left (from .btn-toolbar > .btn + .btn).
This patch force the margin-left to 0 to avoid the button to move when
toggling them.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 3534 - (QA Followup) Use single toolbar for regular/quickadd forms
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Switch incorrect == to != when checking skipped fields
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
I am not sure if this is desired, it makes sense for consistency but
floats in a wierd place for a short form.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds a new system preference:
PatronQuickAddFields
When either this pref or BorrowerMandatoryField is populated this will add a new dropdown to the bew patron toolbar.
When a category is chosen from this dropdown the fields in PatronQuickAddFields and BorrowerMandatoryField will be displayed.
There will be a button allowing a user to switch from the quickadd to the full form and fields will be copied between the forms when toggling.
The Quick add will only be displayed on add of a new patron, future edits should display the full form.
Test plan:
1 - Apply patch
2 - run updatedatabase.pl
3 - Add a new patron and ensure nothing has changed
4 - Populate either PatronQuickAddFields or BorrowerMandatory fields
and note the new button for adding a patron
5 - Click the Quick add and choose a type
6 - Only required or quick add fields should be displayed
7 - Verify toggling forms copies information
8 - Ensure you cannot save patron without filling required fields
(quick add fields should be optional)
9 - Ensure you can save patron with fields filled out
10 - Ensure that a duplicate patron brings up the duplicate/add new
buttons with full form displayed
11 - Verify that subsequent edits use only full form
12 - Verify that data on form submitted is the data saved to patron
13 - Test with various values in both MandatoryBorrowerFields and PatronQuickAddFields
Sponsored by: VOKAL (Vermont Organization of Koha Automated Libraries)
Followed test plan, works as expected.
Re-tested together with followup, works as expected (2016-06-02)
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This follow-up makes some corrections to the markup of the cancel
button:
- Use <a> instead of <button> to eliminate the need for an "onclick"
attribute.
- Remove the "cancel" class which adds unwanted padding.
- Correct the destination of the cancel button when cancelling during an
edit (should redirect to the patron detail page).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
On comment bug 11088 comment 2, Owen explained the problem with the
fixFloat toolbar. Since we have a hidden div, the plugin does not manage
to place the toolbar correctly.
In order to make it work, this patch adds some changes to the plugin to
add the ability to define our own offset.
When the div is extended (+, filteraction_on), the offset should be
updated to move the toolbar. Same when the div is folded (-,
filteraction_off)
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch fixes a small translatability issue in
koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt
The sentence following sentence was splitted by HTML tags:
"Attribute value xxxxx is already in use by another patron record."
To test:
- Review code
- Apply patch
- In Admin, create a unique patron attribute type and try to give
two patrons the same value for this attribute type.
Signed-off-by: Rocio Dressler <rocio@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If you edit a patron from the Edit link of the patron information block
(step 1 of the memberentry script), the branchcode is not displayed. If
you set a guarantor to a child from this form, a JavaScript error will
be raised:
JavaScript error form.branchcode is undefined
It happens because there is the branchcode is not displayed and there is
no element with a branchcode name.
To avoid this issue, a branchcode hidden input is added to the form and
it will be updated when a guarantor is selected (same behavior as when
you edit a patron using the complete form).
Test plan:
Edit a patron using the Edit link of the patron info block (not the Edit
button in the toolbar)
Set a guarantor
=> Notice that the branchcode of the patron has been updated with the
branchcode of the guarantor
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
In the patron entry form template most <fieldset> and <legend> tags have
unique ids. This patch adds ids to fieldsets and legends which lack
them.
To test apply the patch and view the patron entry form. There should be
no visual changes. There should be no HTML validation errors triggered
by this change.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
Bug 15206 undid the changes Bug 15692 made to memberentrygen.tt. This
patch re-removes the JS from the template and moves the additions made
by Bug 15206 into members.js.
Two other minor edits: Changes to quiet JSHint errors.
To test, apply the patch and repeat the test plan for Bug 15692. Confirm
that the following interactions still work on the patron entry form:
1. clear_entry(): With ExtendedPatronAttributes enabled, the "Clear"
link next to any attribute form field should work to clear the field.
2. clone_entry(): With ExtendedPatronAttributes enabled and a repeatable
attribute defined, it should be possible to click the "New" link to
add another instance of that attribute's entry field.
3. update_category_code(): With ExtendedPatronAttributes enabled and an
attribute defined which is limited to a single patron category,
changing the patron category selection should correctly show or hide
the attribute entry form.
4. select_user(): When adding or editing a patron with a "Child"
category it should be possible to search for and select a guarantor
to add to the record by clicking the "Set to patron" button.
Selecting a new guarantor should change the text of the button from
"Set to patron" to "Change."
5. noEnterSubmit(): This function should be correctly preventing you
from hitting "ENTER" in any form field to submit the form.
6. guarantordelete(): When adding or editing a patron with a "Child"
category, it should be possible to clear existing guarantor
information by clicking the "Delete" button. Clicking the "Delete"
button should change the text of the adjacent button to "Set to
patron."
7. select_city(): With one or more cities defined it should be possible
to use the drop-down menu of cities to populate the city, state, zip,
and country fields.
8. Date of birth entry should have a maximum date limit of yesterday.
The drop-down menu of years should go back 100 years.
9. Selecting a date of birth should replace the date format hint with a
message showing the user's age in years or months. Test with values
which will show an age of 1 month, between 2 and 11 months, 1 year,
and more than one year.
10. Client-side validation rules should be in effect, requiring that a
valid email address be entered in the primary email, secondary email,
and alternate address email fields.
11.When editing a patron, the "Add manual restriction" link should
display the form for adding a manual restriction, and clicking the
"Cancel" link should hide it.
Followed test plan, everything works OK.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch moves the JavaScript files in prog/en/js to prog/js.
JavaScript files do not need to be in the directory which is processed
by the translator.
To test, apply the patch and visit various pages in the staff client to
confirm that JavaScript files are still loading correctly.
Revised: I intended for this to be built on top of Bug 15883 as well as
Bug 16242. Now it is.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
On top of 15883 and 16241
All seems to work, js files pulled from new dir.
No errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
According to https://jquery.com/upgrade-guide/1.9/#attr-versus-prop-
.attr() is no longer correct to access the checked state of a checkbox.
This patch do the following replacements:
.attr('checked') => .prop('checked')
.attr('checked, '') => .prop('checked', false)
.attr('checked, 'checked') => .prop('checked', true)
.attr('checked', boolValue) => .prop('checked', boolValue)
.removeAttr('checked') => .prop('checked', false)
.attr('checked') == 'checked' => .is(':checked')
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This uses a similar JS trick to the cataloging interface to change the
location of the toolbar if the language picker is shown.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1) Go to add a new patron
2) Confirm floating 'Save' button stays fixed at bottom right corner of
the page as you scroll the page up/down
3) Resize the browser window to s smaller size, and see the 'Save'
button stays fixed in place
3) Go to edit an existing patron
4) Repeat Step 2 and 3
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1) Go to add a new patron
2) Confirm floating save div scrolls down page with you and works as
expected
3) Go to edit an existing patron
4) Repeat Step 2
Sponsored-by: Catalyst IT
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When creating a patron attribute type, there is a "Allow password"
checkbox. If checked, the librarian will be able to enter a password for
this patron attribute when editing a patron.
The goal was to allow a patron to log in with a secondary password.
However, this feature has never been implemented.
"""
commit 6fc62bcd32
CommitDate: Mon May 12 09:03:00 2008 -0500
extended patron attributes tables & syspref (DB rev 081)
- password_allowed (if set, staff patron editor will
allow a password to be associated with a value; this
is mostly a hook for functionality to be implemented
in the future.
"""
To decrease maintainability, this patch suggest to remove the 2 DB fields
borrower_attributes.password and
borrower_attribute_types.password_allowed
If they have not used by the library.
Test plan:
- Edit a patron attribute type and select "allow password"
- Edit a patron and defined a password for this attribute
- Execute the DB entry
- Note that you get a warning
- Empty the password field
- Execute the DB entry
- You do not get the warning and the 2 DB fields have been removed
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
To test:
1 Add a patron in category Library or School
2 Note the js error in the console
3 Apply patch
4 Repeat and note the error is gone
Signed-off-by: Chris Cormack <chrisc@catalyst.net.z>
Made it an explicit if, and fixed the author of the commit
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
From C4::Koha::GetAuthorisedValues
# TODO: the "selected" feature should be replaced by a utility function
# somewhere else, it doesn't belong in here. For starters it makes
# caching much more complicated. Or just let the UI logic handle it, it's
# what it's for.
Indeed, it's not a job for a subroutine, the template should take care of that.
Note that a perf gain could be won with this patch \o/
Test plan:
- Edit an itemtype and check the value of the "Search category" dropdown list
- Edit a patron attribute type and check the value of the "Class" dropdown list
- Detail for a catalogue record, the Status column should be correctly
populated if items are damaged and/or lost
- Item details for a catalogue record, the lost, damaged and withdrawn
value should be correctly displayed
- Edit a patron, the "street type" should be correctly selected
- Create a patron attribute type linked to an authorised value list.
- Edit a patron, set a value for this attribute, edit it again. The
correct value should be selected.
- Search for subscriptions. The 'Location' dropdown list should behave
correctly (select the entry you have choosen before, etc.)
- Edit a subscription, the location dropdown list should select the
correct value.
- Edit and view a suggestion with a 'reason for suggestion' set (you
should have at least 1 OPAC_SUG AV defined)
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: Brendan Gallagher brendan@bywatersolutions.com
Caused by
commit 9c5c1bc9f1
Bug 15206: Make strings translatable
Test plan:
prove xt/single_quotes.t
should return green
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test:
Apply patch and go to pretty much every page on the Intranet - look out
for labels on forms etc where there should be colons but aren't. If you
see any that I've missed but I'm 99% sure I got all of them! Make sure
to click through some forms where creating a new thing involves
continuing the submission on multiple pages.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Rebased on current master and checked all changed pages.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch updates links in the patron edit and batch patron
modification templates to use Font Awesome icons instead of
background-images.
To test you must have ExtendedPatronAttributes enabled and at least one
repeatable attribute defined.
- Apply the patch and edit any patron record.
- In the section for editing attributes and identifiers, check the
styling and behavior of the "Clear" and "New" links.
- In Tools -> Batch patron modification, load a batch of patron records.
- In the "Edit" form, check the style and behavior of the "Clear" link
for date inputs.
- Test the "New" and "Delete" links for patron attributes.
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
When a new patron is submitted which is suspected to be a duplicate, the
entry form is redisplayed with a new name attribute, "form_nodouble."
Other scripts on the page still look for a form named "form," so there
is an error.
This patch removes the use of "form_nodouble" on the assumption that it
is unnecessary to name the form something different when a duplicate is
suspected. All the same validation scripts should be run on the form
either way.
To test, apply the patch and clear your cache if necessary.
- Go to Patrons -> New patron and add a patron which matches an existing
one in order to trigger the duplicate warning.
- Confirm that Firebug (or similar) is not reporting a JavaScript error.
- Confirm that the 'Edit existing' and 'Save as new' buttons work
correctly.
Reproduced JavaScript error and verified that it no longer appears with
this patch.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch updates the new patron template to use Font Awesome icons in
the dialog which is shown when a duplicate patron is suspected.
The patch modifies the CSS rules for a dialog button with "white-space:
pre-line" so that line breaks in button text markup are treated as line
breaks on display. Allowing the text to wrap prevents the buttons from
being too wide and stacking one below the other.
To test, apply the patch and go to Patrons -> New patron.
- Attempt to save a new patron with details matching an existing patron
in order to trigger the duplicate patron warning.
- Confirm that the resulting dialog is styled correctly.
- Confirm the behavior of both the 'Edit existing' and 'Save as new'
buttons.
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: Brendan Gallagher brendan@bywatersolutions.com
Test plan:
Create or edit a patron (members/memberentry.pl), enter a date of birth
(for a new patron), patron'a age should be shown under
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
We should strive to keep as much JavaScript as possible out of templates
in order to keep things modular and maximize the benefits of browser
caching. This patch moves JavaScript out of the patron entry template
Two other minor edits: Missing semicolons added on the advice of JSHint.
To test, apply the patch and confirm that the following interactions
still work on the patron entry form:
1. clear_entry(): With ExtendedPatronAttributes enabled, the "Clear"
link next to any attribute form field should work to clear the field.
2. clone_entry(): With ExtendedPatronAttributes enabled and a repeatable
attribute defined, it should be possible to click the "New" link to
add another instance of that attribute's entry field.
3. update_category_code(): With ExtendedPatronAttributes enabled and an
attribute defined which is limited to a single patron category,
changing the patron category selection should correctly show or hide the
attribute entry form.
4. select_user(): When adding or editing a patron with a "Child"
category it should be possible to search for and select a guarantor
to add to the record by clicking the "Set to patron" button.
Selecting a new guarantor should change the text of the button from
"Set to patron" to "Change."
5. noEnterSubmit(): This function should be correctly preventing you
from hitting "ENTER" in any form field to submit the form.
6. guarantordelete(): When adding or editing a patron with a "Child"
category, it should be possible to clear existing guarantor
information by clicking the "Delete" button. Clicking the "Delete"
button should change the text of the adjacent button to "Set to
patron."
7. select_city(): With one or more cities defined it should be possible
to use the drop-down menu of cities to populate the city, state, zip,
and country fields.
8. Date of birth entry should have a maximum date limit of yesterday.
The drop-down menu of years should go back 100 years.
9. Client-side validation rules should be in effect, requiring that a
valid email address be entered in the primary email, secondary email,
and alternate address email fields.
10.When editing a patron, the "Add manual restriction" link should
display the form for adding a manual restriction, and clicking the
"Cancel" link should hide it.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The CardnumberLength system preference defines card number minimum and
maximum allowed values when adding a patron. This information is
currently hidden in a title attribute on the card number input field.
This patch moves the information into a <div class="hint">, matching
other fields in the entry form which offer details about entry
guidelines.
To test, apply the patch and open the new patron entry form. Test for
various values of CardnumberLength, and with 'cardnumber' mandatory or
not mandatory as defined in BorrowerMandatoryField.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Nearly all cellular providers allow a person to send an text message to a cellular
phone by sending an email to phonenumber@provider. We can leverage this capability
to add the ability for Koha to send sms messages to patrons without the need to
subscribe to an sms gateway server.
Basic plan:
1. Add a table sms_providers to the db to tell Koha what service providers are available, and what domain emails should be sent to.
2. Add borrowers.sms_provider_id to tell Koha which mobile service the patron subscribes to for the number given in smsalertnumber
3. Modify Koha to send an email rather than using SMS::Send if the driver is set to 'Email'
Test plan:
0) Get a mobile phone
1) Apply the patch
2) Run updatedatabase.pl
3) Set the value of SMSSendDriver to 'Email'
4) Go to the admin page, the "Additional parameters" area should now have the link "SMS cellular providers"
5) On this page, add some providers. Make sure to add the provider for your own cellular phone service.
Here are some examples:
Sprint phonenumber@messaging.sprintpcs.com
Verizon phonenumber@vtext.com
T-Mobile phonenumber@tmomail.net
AT&T phonenumber@txt.att.net
Only add the domain part in the 'domain' field. So for Verizon, that would be 'vtext.com'
6) Create an account for yourself, add your SMS number, and select your provider from the dropdown box directly below it.
7) Enable SMS messaging for Item check-in and Item checkout
8) Check out an item to yourself
9) Run process_message_queue.pl
10) Wait! You should receive a text message shortly, when I tested it, I received my sms message within the minute.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Revert "DBRev to make notes of the XSS patches and the new important dependency."
This reverts commit e140603a59.
Revert "Bug 13618: Specific for branches.opac_info"
This reverts commit 06e4a50f00.
Revert "Bug 13618: (follow-up) Specific for other prefs"
This reverts commit d6475a111f.
Revert "Bug 13618: Fix for debarredcomment and patron messages"
This reverts commit dd98c9df92.
Revert "Bug 13618: Do not display html tags in patron's notices"
This reverts commit a065b243fe.
Revert "Bug 13618: Do not display and html tags in item fields content"
This reverts commit baeeaffbf8.
Revert "Bug 13618: Fix for system preference description"
This reverts commit a967a09261.
Revert "Bug 13618: Remove html filters for newly pushed code"
This reverts commit 0e98662b10.
Revert "Bug 13618: (follow-up) add missing lines for opac-shelves"
This reverts commit fc2fb605e5.
Revert "Bug 13618: (follow-up) Specific for ColumnsSettings"
This reverts commit bc308fdd9c.
Revert "Bug 13618: Fix for edit biblios and items"
This reverts commit 811c4e8402.
Revert "Bug 13618: followup to remove tabs"
This reverts commit ca8e8c397c.
Revert "Bug 13618: Fix last occurrences recently introduced to master"
This reverts commit bb417b256b.
Revert "Bug 13618: Fix for news"
This reverts commit ae5b98020a.
Revert "Bug 13618: Fix escape on sending baskets or shelves by email"
This reverts commit a7731ffe25.
Revert "Bug 13618: Specific for XSLTBloc"
This reverts commit 11fa38dc29.
Revert "Bug 13618: Specific for Salutation on editing a patron"
This reverts commit 36c07ad6d3.
Revert "Bug 13618: Specific for other prefs"
This reverts commit e6ea281a3b.
Revert "Bug 13618 - memberentrygen.tt errors Not a GLOB reference"
This reverts commit 7824874557.
Revert "Bug 13618: Specific for ColumnsSettings"
This reverts commit 1834da3da3.
Revert "Bug 13618: Specific for IntranetUser* and OPACUser* prefs"
This reverts commit 21ae62b253.
Revert "Bug 13618: Fix error 'Not a GLOB reference'"
This reverts commit 602bdbab4c.
Revert "Bug 13618: Specific for the ISBD view"
This reverts commit d254362435.
Revert "Bug 13618: Specific for pagination_bar"
This reverts commit 8837a8ae68.
Revert "Bug 13618: Specific places where we don't need to escape variables - intra"
This reverts commit 00eff140b3.
Revert "Bug 13618: Remove html filters at the intranet"
This reverts commit 7db851ff03.
Revert "Bug 13618: Specific places where we don't need to escape variables"
This reverts commit 49a3738b8d.
Revert "Bug 13618: Remove html filters at the OPAC"
This reverts commit cedaa0e23e.
Revert "Bug 13618: Use Template::Stash::AutoEscaping to use the html filter"
This reverts commit 01b38d3b13.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
This followup on top of remote branch
Only remove tabs and trailing spaces to make koha-qa pass
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Like Jonathan said:
The interpolation of a variable on including a file caused an unexpected
error:
Template process failed: undef error - Not a GLOB reference at
/usr/lib/i386-linux-gnu/perl5/5.20/Template/Provider.pm line 619.
Replaced it with a SWITCH, like the other patch for this similar error.
Signed-off-by: Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Argument "" isn't numeric in numeric lt (<)
TEST PLAN
---------
1) Go to any patron in staff client
2) Click 'Edit'
3) Check error logs
-- warnings should exist.
4) Apply patch
5) Reload page
-- warnings should not be triggered.
6) Add restriction and save
7) Go back to edit screen
-- restriction should be shown
8) Remove restriction and save
9) Go back to edit screen
-- Should say "Patron is currently unrestricted"
10) Run koha qa test tools.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch changes the options to the date picker, allowing easy
selection of dates up to 120 years from the current date.
To test:
- Click on 'Patrons' from the main menu, select 'New patron'
- Set input focus to the 'Date of birth' input field,
the date selection widget should show up.
- The year selection drop-down will only show current year minus 10.
- Apply the patch
- Go back to the same screen, set input focus to the 'Date of birth' field.
- The year selection drop-down should show current year minus 120.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch fixes the filename categorie.pl correcting it by categories.pl
The plurial is usually used for script names in the admin module.
Test plan:
Navigate to the patron categories page.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
No reference to categorie.pl anywhere in the code
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Fix sentences in memberentrygen.tt that are split by <strong> tags, leading to
wrong capitalization in German (because it can not be decided if a string is part
of a sentence or a standalone sentence).
Example: Es sind Keine Bibliotheken definiert.
To test:
- Apply patch
- To trigger the messages, you have to edit a patron in a system where
no libraries and no patron categories are defined
- Alternatively, carefully review the changes in
koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Sentences fixed for translation purposes
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
If one save the login and password used to authenticate in staff interface, when creating a new patron, those login and password are filled in the corresponding inputs in the form.
This behaviour is awkward from web browser.
A trick is provided by http://stackoverflow.com/questions/10738090/why-firefox-autocomplete-even-with-different-input-name
I found that the best way is to use an hidden disabled input between userid and password.
Test plan :
- Log into Koha
- Allow the browser to save the userid/password
- Be sure that you have only one userid/password for this Koha
- Loggout
- Re log to check the browser autocomplets the authentication form
- Create a new patron
=> Without patch your saved userid/password have been added to the form
=> With patch your saved userid/password have not been added to the form
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is not elegant but it works.
Note that the problem does not exist with Chromium
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
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>
To test:
Edit a patron in the intranet, note that the gender options are "Female," "Male," and "None specified"
Setting "None specified" should result in the gender not being shown on the patron detail page (unchanged functionality)
In the opac, log in and click the "your personal details" tab, and note that the gender options are "Female," "Male," and "None specified"
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@unc.edu.ar>
This patch adds server-side & client-side validation for email
form fields in the members/memberentry -view and in the
opac/memberentry-view (bootstrap).
I recently added simple validation for phone number and email address fields
for our in-house koha and saw this old bug: I'm open to any ideas on how
to do this better. Validation for phone numbers would be easy to add on
top of this but I left it out since this bug is only about the email
fields.
To test:
1) Select a member and go to any of the edit forms with email fields
(Primary info, "Library use", "Alternate address", "Alternative
contact").
2) Disable javascript in the browser in order to test server-side
validation and try to input invalid emails in each of the email form
fields.
3) Confirm that an invalid address is catched from any of the email
fields, an alert shown for each invalid address and that the member's
information was not updated with invalid data.
4) Enable javascript in the browser.
5) Confirm that the jquery validation plugin caches invalid addresses
from any of the email fields and that you cannot send the form before
correcting the problem.
6) Perform the same tests for the opac-memberentry-view.
Note: as the jQuery validation plugin doesn't exist in the bootstrap
folder, I just copied it over from the staff-client folder -how to deal
with this?
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I have undone the changes to opac.css so that they can be submitted as a
separate patch. I have some other follow-ups to make as well.
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Working on bug 13497 and bug 9314, I run into some Koha vestiges.
The category_type parameter should not be passed to memberentry.
On creating a new patron, the categorycode should be passed, and on
editing, it's useless. We can work with the borrowernumber and retrieve
these values.
Details of the changes:
- members-toolbar.inc: Remove the category_type parameter passed to
memberentry.pl
- memberentrygen.tt: Just remove the useless category_type parameter on
editing a patron. Also remove the unused one passed to
guarantor_search.pl.
- tables/members_results.tt: the borrowernumber is enough to edit a
patron.
- memberentry.pl: check_categorytype is never used in the template, all
the process to calculate/retrieve it is unnecessary.
- members/nl-search.tt: The borrowernumber is enough to edit a patron.
Test plan:
Try to create and edit patrons and verify that
- the guarantor search still work
- the form (memberentry) behave as before
Edit a patron from the nl-search.pl script (Magnus?)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
On top of 9314 (13497 already pushed)
No evident regressions found, add/edit patron works,
search/set guarantor works.
Cant test nl-patron.pl save for exec it.
prove -v t/NorwegianPatronDB.t runs
No koha-qa errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since the pref AddPatronLists has been removed in bug 13497, the code
related to type_only and category_type in memberentry.pl is useless.
Test plan:
Confirm you don't the information message.
You can also confirm that the message was wrong and nothing was saved.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Dead code removed, no errors
Think that bug description can be updated to commit message
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Test plan:
1. install and activate an additional language
2. create patron in organization category
3. create professional patron
4. try to add this patron to an organization (Guarantor information section)
5. note that the left button text changed to "Change" - untranslated english string
6. push the "Delete" button, the guarantor patron field is cleared and the left button text changed to "Set to patron" - again original english text
7. apply the patch
7.1. update translation (koha-translate -u language_code)
8. repeat 4-6, note, that button text are still translated in all sitations
9. sign off ;)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, no errors
Fixed message capitalization
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
----
Amended to resolve conflict in sysprefs.sql / mveron
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To test:
Apply patch
Do a database update (e.g. by changing version number in kohaversion.pl)
Find new system preference 'addressformat' in I18N/L10N
Choose 'German style'
Go to Patrons and edit a patron / create new patron
Verify that Zip code appears above City
Change system preference to 'US style'
Verify that Zip code appears between State and Country.
BTW: New formats can be added by editing i18n_l10n.pref (add a new code, e.g. fr for "French style") and copy / modify the includes using the same code as postfix.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Patch amended to move street number after address. /Marc
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Amended do resolve conflict with updatedatabase.pl /Marc
Rebased for current master /Marc
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch extracts the address blocks in memberentrygen.tt to include files.
To test: The overall functionality should remain the same with this patch.
In further steps, more country- or region-dependent includes could be added, along with functionality to select them using a system preference.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch is the main patch.
The "common" template is improved to allow different type of picking:
"add" or "select".
The first one appends a patron to a list, the second one selects the
patron and close the result search window.
The members/guarantor_search.pl has completly changed but is quite the
same file as acqui/add_user_search.pl. Both should exist: they don't
belong to the same module (acqui vs members), the picking type is
different (add vs select) and the columns are not the same.
The changes in the common template are very powerful, it's now possible
to list the column we want! This will be very useful for further
reusability.
Before this patch, all patrons mathing the pattern were return. Now only
the first 20 are (depends on the DataTables selected value).
For QA: This patch introduces a new template plugin "To", for now it
permits to convert a perl structure to json. In the idea, it could
permit to convert foo to bar too.
Test plan:
1/ Verify there is no regression in the guarantor search. When the
selection has been done, all data from the guarantor should fill the
form in the "main address" section.
Note that the request is done when the search input in not empty and the
user stop to write for 1 sec.
2/ Verify there is no regression on the 2 other pages where this patron
search is used: link a patron to an order and to a basket (in the
acquisition module).
Signed-off-by: Morag Hills <the.invinnysible.one@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Labeling a phone number field "mobile phone" eliminates the usefulness
of having the labels "primary" and "secondary." Generic labels let the
user populate the fields according to their importance rather than their
type.
To test I recommend editing a patron record so that the values in the
patron record contain a label matching the table column:
borrowers.phone : 555-555-1234 (primary - phone)
borrowers.phonepro : 555-555-5678 (secondary - phonepro)
borrowers.mobile : 555-555-9012 (other - mobile)
View this patron's information in the various affected templates and
verify that the labels correctly match the data:
- OPAC "your personal details" (opac-memberentry.pl)
- Submit changes to primary, secondary, and other phone via the OPAC.
In the staff client, view the confirmation for those changes.
- Patron details in the staff client (moremember.pl)
- Patron entry/edit in the staff client (memberentrygen.pl)
- Patron duplicate confirmation in the staff client
(you can navigate directly to
/members/moremember.pl?borrowernumber=XXXX&print=brief)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch moves the patron category name or category type at the end of title and breadcrumb for better translatability.
Note: It does not change anything in functionallity, it only changes display of strings.
To test:
Apply patch
Search a patron and edit it in all possible ways: 'Edit' button on top of details page, 'Edit' links in details page, 'Edit' links in search result table if multiple patrons are found)
Duplicate a patron
Create a new patron
Make sure that title and breadcrumb appear in a meaningful way with pattern similar to the following:
Modify patron Hansli Meier (Juvenile)
(Missing </div> added)
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To test:
In staff client, go to Home > Patrons
Click button "New patron" and choose a category
Change Patron messaging preferences
Now change Category
Make sure that following message box still appears: "Change messaging
preferences to default for this category?"
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When adding a duplicated patron record some fields are prepopulated from
the original patron record. Focusing your cursor on these fields
automatically clears them. This works well if you assume that the user
only focuses on fields which should be changed. This works badly if you
consider that a user might want to tab between all fields. I think the
disadvantages outweigh the minor benefit of not having to delete the
contents of a field.
This patch removes the clearing action.
TEST PLAN
---------
1) Log in to staff client
2) Patrons
3) Find an existing patron
4) Click on the link in the Name column
5) Click on the Duplicate button
6) Click on fields with data in them.
-- they will clear, which is more problematic than correcting
the entry.
7) On the line
"Home > Patrons > {patron name} > Duplicate Adult Patron"
click the patron name to go back.
8) Click on the Duplicate button
9) Tab through the fields
-- the fields should remain unchanged, but sadly they clear.
10) Apply the patch
11) On the line
"Home > Patrons > {patron name} > Duplicate Adult Patron"
click the patron name to go back.
12) Click on the Duplicate button
13) Navigate through the fields
-- tabbing nor clicking should clear any fields.
14) Run koha qa tests
NOTE: Had to rebase again. Yes, bug 7878 interfered.
However, it deals with comment #6, which Owen
appropriately noted.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Less surprises, improves accessibility by enabling to
tab through the form without losing data.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To reproduce this bug:
- Create a patron attribute type and limit it by patron category
- Create a new patron with that category
- Observe that there is no entry field for the patron attribute type you
created for that patron category. Inspecting the source should show
that the entry field has been hidden.
The patron entry form tries to hide patron attribute type input fields
based on the currently selected patron category. It does this based on
the value of $("categorycode"). However, instead of pulling the data
from the categorycode input in the body of the entry form, it pulls it
from the patron search box at the top of the page. The value of that
input is always empty because no category is preselected.
This patch corrects the problem by changing the ID of the categorycode
<select> in the body of the entry form and making corresponding changes
to the JavaScript which depends on it.
To test, apply the patch and load the patron entry form for a patron
category to which a patron attribute type has been limited. That patron
attribute entry field should appear correctly.
Choose a different patron category from the "Category" dropdown. Confirm
that the patron attribute entry field has been hidden.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Without the previous patch, when you edited a patron, the "N/A" value
was selected for sex.
With, no checkboxes were selected.
This patch also replaces the
IF opduplicate do nothing ELSE do something END
statement with
UNLESS opduplicate do something END
which is more readable.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When duplicating a patron the resulting entry form contains the data
from the original patron in the following fields: Other names, Initials,
Gender, OPAC note, Staff note, and expiration date. These should be
blank for a new duplicated patron. This patch corrects this.
To test, locate or create a patron record which contains data in the
fields listed above. Duplicate that patron and confirm that those fields
are blank in the resulting patron entry form.
Confirm also that editing an existing patron with data in those fields
works correctly.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch makes it possible to sync patron data between Koha and the
Norwegian national patron database, in both directions.
In order to use this, the following information is necessary:
- a username/password from the Norwegian national database of libraries
("Base Bibliotek"), available to all Norwegian libraries
- a special key in order to decrypt and encrypt PIN-codes/passwords,
which is only available to Norwegian library system vendors
- a norwegian library vendor username/password
See http://www.lanekortet.no/ for more information (in Norwegian).
While this is of course an implementation of a specific synchronization scheme
for borrower data, attempts have been made to prepare the ground for other sync
schemes that might be implemented later. Especially the structure of the new
borrower_sync table might be reviewed with an eye to how it might fit other
schemes.
To test:
Since the password and cryptographic key needed to use this functionality
is only available to Norwegian library system vendors, only regression testing
can be done on the submitted code. Suggested things to check:
- Apply the patch and make sure the database update is done. This should add
the new "borrower_sync" table and five new systmpreferences under the
"Patrons" > "Norwegian patron database" category:
- NorwegianPatronDBEnable
- NorwegianPatronDBEndpoint
- NorwegianPatronDBUsername
- NorwegianPatronDBPassword
- NorwegianPatronDBSearchNLAfterLocalHit
- Check that patrons can be created, edited and deleted as usual, when
NorwegianPatronDBEnable is set to "Disable"
- Check that the new tests in t/NorwegianPatronDB.pm run ok, e.g. on a
gitified setup:
$ sudo koha-shell -c "PERL5LIB=/path/to/kohaclone prove -v t/NorwegianPatronDB.t" instancename
- Check that all the other tests still run ok
- Check that the POD in the new files itroduced by this patch looks ok:
- Koha/NorwegianPatronDB.pm
- members/nl-search.pl
- misc/cronjobs/nl-sync-from-koha.pl
- misc/cronjobs/nl-sync-to-koha.pl
- t/NorwegianPatronDB.t
Sponsored-by: Oslo Public Library
Update 2014-09-18:
- Rebase on master
- Split out changes to Koha::Schema
- Incorporate new way of authenticating with NL
Update 2014-10-21:
- Rebase on master
- Use Module::Load to load Koha::NorwegianPatronDB in non-NL-specific
scripts and modules
- Fix the version number of Digest::SHA
- Fix a missing semicolon in kohastructure.sql
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes empty onclick attribute from memberentrygen.tt
To test:
Apply patch.
Use git grep 'onclick=""' to make sure that there are no more empty onlick attributes
Go to Home > patrons and click 'New patron'
Check HTML of 'Cancel' link
Make sure that 'Cancel' link still works
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Changes the link to cancel adding a manual restriction.
No regressions found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If you try to create a patron and enter an extended attribute value
which is required to be unique but exists in another record the error
you receive is not clear. It uses the attribute code instead of the
description. This patch adds description to the output.
To test you must have ExtendedPatronAttributes enabled.
- Edit or create an extended patron attribute and designate it a unique
identifier.
- Edit a patron and add a value to that attribute.
- Edit another patron and try to add the same value.
You should get an error which includes both the description of the
attribute you tried to modify and the value you submitted.
Signed-off-by: Christopher Brannon <christopher@debian.brannon.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Passes tests and Qa script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Touches three member templates.
Changes label Other into Mobile.
This is consistent with database field name and OPAC.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When duplicating a patron the form fields for setting patron account
flags and restrictions should be hidden as it is when adding a patron.
This patch adds the correct logic to the template.
To test, duplicate an existing patron:
- Confirm that the "Patron account flags" and "Patron restrictions"
sections are not visible.
- Confirm that saving a duplicated patron works correctly.
- Confirm that the edit and new patron entry forms are unaffected.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works ok, all three points confirmed
No koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, small template change.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
http://bugs.koha-community.org/show_bug.cgi?id=12150
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No bug number on description
No commit message
No test plan
No koha-qa errors
I only signed this because it's useful for translations
but we can live without it, so is up to QA now
Tested some easy messages (e.g. syspref saving), and
updated PO files to check new strings.
Inspected the code, I think that there are no errors.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
This gives a koha-qa error, but on another user/env not.
Really don't know
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I see the same error, but can't see where this is coming from,
code seems to work ok.
Works as described, no regressions found.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Now we can use the method plugin from the memberentry form.
Test plan:
1/ Create a patron and verify sort1 and sort2 dropdown list are
correctly generated.
2/ Select values.
3/ Save.
4/ Edit the patron and verify the selected values are displayed.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works as described.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan:
To test on modified pages:
- Press enter when cursor is on input or select and verify the form is not
submitted.
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When using Chrome on Mac OS X, form submits are triggered by hitting
enter when focused on a select. This is not an issue with any other
combination of browser and operating system that I am aware of.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch finishes the work started in one of the previous
follow-ups and allows CardnumberLength to be set to a value
like ',5'. In conjunction with not including cardnumber in
BorrowerMandatoryField, this allows a cardnumber to not be
required but, if present, to not exceed the specified length.
This patch also updates t/db_dependent/Members.t so that
it runs in a transaction, tests the new return value
of checkcardnumber, and manages the CardnumberLength syspref.
To test:
[1] Verify that prove -v t/db_dependent/Members.t and
prove -v t/Members/cardnumber.t pass.
[2] Set CardnumberLength to ",5" and take cardnubmer out of
the BorrowerMandatoryField list.
[3] Verify that you can save a patron record without a cardnumber,
but if you supply one, that it can be at most 5 characters long.
[4] Add cardnumber back to BorrowerMandatoryField. This time, the
minimum length is 1 even though CardnumberLength is ",5".
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch replaces use of the HTML5 pattern attribute with minlength
and maxlength, which is compatible with the jQuery validation plugin
and which, in Chrome 33.0.1750.146 at least, works better.
To test:
[1] Enter a new patron record or edit an existing one.
[2] Verify that the minimum and/or maximum length requirements
set by the CardnumberLength syspref are validated and that
form submission is prevented if the cardnumber doesn't
meet the length requirements.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch refactors the previous code and moves the logic from the pl
to a new routine.
Same test plan as previous patch.
/!\ new unit test filename.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 10861: Reintroduced the cardnumber length check (client side)
Previous patches has removed the pattern attribute of the input, it was
not needed. This patch reintroduces it. It will only work for new
browser version.
Moreover, it manages with the ',XX' format (see UT).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Squashed the last two follow-ups. The pattern test did not work fully for me
in Firefox 26 (very recent). But I see the message when I clear the field.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Some libraries would like to add a check on the cardnumber length.
This patch adds the ability to restrict the cardnumber to a specific
length (strictly equal to XX, or length > XX or min < length < max).
This restriction is checked on inserting/updating a patron or on importing
patrons.
This patch adds:
- 1 new syspref CardnumberLength. 2 formats: a number or a range
(xx,yy).
- 1 new unit test file t/Members/checkcardnumber.t for the
C4::Members::checkcardnumber routine.
Test plan:
1/ Fill the pref CardnumberLength with '5,8'
2/ Create a new patron with an invalid cardnumber (123456789)
3/ Check that you cannot save
4/ With Firebug, replace the pattern attribute value (for the cardnumber
input) with ".{5,10}"
5/ You are allowed to save but an error occurred.
6/ Try the same steps for update.
7/ Go to the import borrowers tool.
8/ Play with the import borrowers tool. We must test add/update patrons
and the "record matching" field (cardnumber or a uniq patron attribute)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested adding, updating; importing and ran unit test.
Preliminary QA comments on Bugzilla
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When editing additional attributes of a patron of a category with a
code with space (ie "CAT 3"), the Javascript is broken and Additional
attributes are not displayed.
This patch corrects by adding simple quotes around category code in JS
code.
Test plan :
- Create an patron additional attribute
- Create a new patron category with a space in code. ie "CAT 3"
- Create a new patron of this category : /cgi-bin/koha/members/memberentry.pl?op=add&categorycode=CAT 3
=> Without patch the JS is broken (Syntax error, unrecognized expression:
[data-category_code=CAT 3]) and additional attributes are not
displayed.
=> With patch the JS is not broken and additional attributes are
displayed and can be edited.
Signed-off-by: Marc Véron <veron@veron.ch>
In current Koha version it is not possible to create category codes
with blanks.
To test, I changed an existing category code directly in the database.
Then I followed the Test plan.
Without patch, attribute types were not displayed.
With patch, they were displayed as expected.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I recommend not using codes with spaces and fix existing ones.
Koha doesn't allow you to add category codes with spaces, so the only way
to do it is via SQL.
This patch fixes a problem and passes all tests.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Currently road types are stored in a specific table in DB. Moreover, an
admin page is present in order to manage them.
This patch proposes to remove this table and this page in favour of a
new authorised value category 'ROADTYPE'.
This patch:
- adds a new AV category 'ROADTYPE' (created from the roadtype table
content).
- remove the roadtype table.
- remove the .pl and .tt file admin/roadtype
- remove the 2 routines C4::Members::GetRoadTypes and
C4::Members::GetRoadTypeDetails
Test plan:
1/ Execute the updatedatabase entry and verify existing roadtypes are
now stored in the AV 'ROADTYPE'.
2/ Verify you can add/update a streettype for patrons.
3/ Verify on following pages the streettype is displayed in patron
information (top left):
circ/circulation.pl
members/memberentry.pl
members/moremember.pl
members/routing-lists.pl
Signed-off-by: Sophie Meynieux <sophie.meynieux@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds 2 circulation permissions: force_checkout and
lift_restriction.
During upgrade, these two permission are added to existing staff
users that already have the base circulate permission.
force_checkout allows a librarian to force a checkout if a limitation
occurred.
lift_restriction allows a librarian to lift a restriction for a patron.
Test plan:
1/ Find a debarred patron and go on the checkout page. The "Lift
restriction" button should be present only if the logged librarian has
the lift_restriction permission.
2/ If the force_checkout permission is set, a librarian should be
allowed to check out in several cases:
- age restriction
- the item is issued to another patron
- the item is not for loan
- the patron has overdue items
- the item is lost
- the item is a high demand item
- the item is reserved
- another case ?
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Bug 10863: The force checkout permission should not affect high holds
- typo checkout => check out.
- the force checkout permission does not affect high holds.
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Bug 10863: Follow-up: Adding missing permissions to translated files
This patch adds the 2 new permissions to all remaining sample files.
If the permissions don't get installed, the problem is bigger than
having an English description.
Also adds back the question "Check out anyway?" for high demand items (HIGHHOLDS).
Test xt/permissions.t passes now.
Bug 10863: Rename lift_restriction with manage_restrictions
The pref manage_restrictions now takes into account "Lost card" and
"Gone no address" restrictions.
Test plan:
- log in with a user with manage_restrictions permission
- verify you can set/unset restrictions when editing a patron
- log in with a user without manage_restrictions permission
- verify you cannot set/unset restrictions when editing a patron
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Note: The AgeRestrictionOverride pref has to be set to "Allow" if you
want to override the age restriction, even if the new permission is set.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, works as advertised
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Editing partron data results in unintended adding of indefinite manual
restriction to it. Reason for it is hidden field add_debarment which
is wrongly initialized to 1 instead of 0. Also JavaScript code seems
to want to toggle checkbox, and since this field is hidden correct
approach would be to change its value to 1.
Test scenario:
1. edit patron data
2. verify that debarrment is wrongly added
3. remove debarrment
3. apply this patch
4. edit patron again
5. verify that debarrment wasn't added
6. intentionally add debarrment and verify that it's saved
7. add debarment, enter something in comment but press cancel
and verify that debarment isn't added
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This fixes this blocker, however, with or without the patch, the date
is not saved correctly. I will file a new bug for that
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This follow-up to Bug 2720 makes some template changes which I think
make the interface a little more consistent and streamlined.
Instead of incorporating the manual entry form into the table it is
broken out and follows standard form structure. This lets the table be
hidden altogether if there are no existing restrictions.
The manual entry form is hidden by default and shown when you click a
link to add a manual restriction.
These changes have been applied to both the include file used for
circulation and patron detail and to the patron entry form template.
To test, add and remove manual restrictions from the circulation page,
the patron detail page, and the patron edit page. All operations should
work correctly.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a more extensible and flexible debarments system to Koha. The fields
borrowers.debarred and borrowers.debarredcomment are retained for compatibility and
speed.
This system supports having debarments for multiple reasons. There are currently
three types of debarments:
OVERDUES - Generated by overdue_notices.pl if the notice should debar a patron
SUSPENSION - A punative debarment generated on checkin via an issuing rule
MANUAL - A debarment created manually by a librarian
OVERDUE debarments are cleared automatically when all overdue items have been returned,
if the new system preference AutoRemoveOverduesRestrictions is enabled. It is disabled
by default to retain current default functionality.
Whenever a borrowers debarments are modified, the system updates the borrowers debarment
fields with the highest expiration from all the borrowers debarments, and concatenates
the comments from the debarments together.
Test plan:
1) Apply patch
2) Run updatedatabase.pl
3) Verify the borrower_debarments table has been created and
populated with the pre-existing debarments
4) Run t/db_dependent/Borrower_Debarments.t
5) Manually debar a patron, with an expiration date
6) Verify the patron cannot be issued to
7) Add another manual debarment with a different expiration date
8) Verify the 'restricted' message lists the date farthest into the future
9) Add another manual debarment with no expiration date
10) Verify the borrower is now debarred indefinitely
11) Delete the indefinite debarment
12) Verify the debarment message lists an expiration date dagain
13) Enable the new system preference AutoRemoveOverduesRestrictions
14) Set an overdue notice to debar after 1 day of being overdue
15) Check out an item to a patron and backdate the due date to yesterday
16) Run overdue_notices.pl
17) Verify the OVERDUES debarment was created
18) Return the item
19) Verify the OVERDUES debarment was removed
20) Disable AutoRemoveOverduesRestrictions
21) Repeat steps 15 though 18, verify the OVERDUES debarment was *not* removed
22) Add issuing rules so that an overdue item causes a temporary debarment
23) Check out an item to a patron and backdate the due date by a year
24) Return the item
25) Verify the SUSPENSION debarment was added to the patron
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch uses the jQuery validator plugin introduced in
bug 6209 for two reasons:
[1] To supply validation for non-HTML5-compatible web
browsers.
[2] To force use of the validator plugin rather than
built-in validation for HTML5 browsers, which means
that our translations will be used.
Note that a version of the function to prevent double form submission
is used as the submit handler invoked when the validator plugin
is satisified that the form is complete.
To test:
[1] Same as the main test plan, but note that the validation
messages now appear inline rather than as pop-ups.
[2] Verify that the double form submission prevention still
works.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When the pref BorrowerMandatoryField is set and a librarian forget to
fill fields, a js popup appears with the following message:
"The following fields are mandatory: surname, etc."
The fields are not translatable.
Test plan:
- fill the pref BorrowerMandatoryField with something like:
title|zipcode|surname|cardnumber|branchcode
- go the members/memberentry.pl?op=add page
- verify you are not allowed to add the patron without filling all
mandatory fields.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Add an ID to ease customization via jQuery; an ID is already present
on alt address but was missing from main address
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When duplicating a patron record an onclick event is added to many
fields in order to make then clear when focused. This patch updates the
template so that the logic for this can be simplified. A template
variable is set based on the 'opduplicate' variable, and a class added
to the relevant fields. All fields with that class are cleared on focus.
Also changed are several markup issues which were causing validation
errors.
To test, find or create a patron record which has all standard text
fields filled with data. Use the "duplicate" button on the detail view
of that patron to initiate the duplication process.
Focus on each field in the patron entry form in succession. Fields which
contain data should be cleared in the same way they were before the
patch.
Also test a regular edit operation to confirm that fields are not
cleared.
Signed-off-by: Campbell Reid-Tait <campbellreidtait@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, works as advertised.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If a warning about a duplicated patron attribute is returned,
the value was being passed back for display in the warning
message with the same name as the variable in errors
As the message is displayed in the context of errors
the error value 1 was being displayed not the value
duplicated as intended.
Pass the value to the template with a unique name.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I fixed another tiny typo while signing off: "is already in use" instead
of "is already is use."
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, works as advertised.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
categorycode and branchcode should show as required under all
circumstances, not just when they are included in the
BorrowerMandatoryField system preference. This patch adds the correct
classes and hints to those fields.
To test, view the patron entry form for a new or existing patron.
Category and Library should show that they are required.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Adds a course reserves system for academic libraries.
The course reserves system allows libraries to create courses
and put items on reserves for those courses.
Each item with at least one reserve can have some of its attributes
modified while it is on reserve for at least one active course.
These attributes include item type, collection code, shelving location,
and holding library. If there are no active courses with this item
on reserve, it's attributes will revert to the original attributes
it had before going on reserve.
Test Plan:
1) Create new authorised value categories DEPARTMENT and TERM
2) Create a new course, add instructors to that course.
3) Reserve items for that course, verify item attributes have changed.
4) Disable course, verify item attributes have reverted.
5) Enable course again, verify item attributes again.
6) Delete course, verify item attributes again.
7) Create two new courses, add the same item(s) to both courses.
8) Disable one course, verify item attributes have not reverted.
9) Disable both courses, verify item attributes have reverted.
10) Enable one course, verify item attributes are again set to the
new values.
11) Edit reserve item attributes, verify.
12) Disable all courses, edit reserve item attributes, verify
the item itself still has its original attributes, verify
the reserve item attributes have been updated.
13) Verify the ability to remove instructors from a course.
14) Verify new permissions, top level coursereserves, with
subpermissions add_reserves and delete_reserves.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Corinne Bulac <corinne.hayet@bulac.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
http://bugs.koha-community.org/show_bug.cgi?id=8125
- the dateformat value is send to all templates (from
C4::Auth::get_template_and_user)
- remove all assignment of dateformat in all .pl files
- Remove "all" occurrences (those I found!) of dateformat_*
From now the only way to get the date format is a string comparaison
(dateformat == "metric")
Checked with the command:
git grep "\(dateformat_us\|dateformat_metric\|dateformat_iso\)" | grep
-v translator
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Tested all the datepickers I could find, looks good.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The DB field borrowers.branchcode cannot be null (`branchcode`
varchar(10) NOT NULL default ''). However, an empty value can be selected
on creating/updating a patron.
Test plan:
- Add or edit a patron and choose the empty value for library
(branchcode).
- Save (pref BorrowerMandatoryField must not contain branchcode).
- Mysql raises an error.
- Apply the path.
- Check that you are not able to select no library.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
It is noted in Bug 5432 that during a duplicate operation one field,
'Sort1' does not automatically clear when the cursor moves into it. This
patch corrects this.
Edit a patron record to have data in the Sort1 and Sort2 fields. Perform
a duplicate operation on this patron and confirm that the Sort1 and
Sort2 fields show the information from the original patron record. When
you click on each field the contents should disappear.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Works as described.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Currently, clicking twice or more on the Save button will generate
duplicate patrons when adding patrons in the Patron module. Of course,
there is handling that detects this, so you can choose to either edit
the original record (i.e. throw away the duplicate) or create a
duplicate record.
However, it shouldn't get to that point by clicking on the Save button.
That handling seems to be there to handle cases where you go through the
whole process of trying to add a new patron only to find out that they
already exist in the system (or at least their username/password do).
--
This patch uses the "preventDoubleFormSubmit" function (which is also
used in holds and fines to prevent double form submits). It was also
necessary to edit members.js, since "check_form_borrowers" was forcing
form submits despite the "preventDoubleFormSubmit" function. I've
changed it from forcing a document.form.submit to return true, which the
browser will still submit the form if it's a unique borrower, but the
"preventDoubleFormSubmit" function will still prevent multiple submits.
I've also added a "waiting" class to staff-global.js which changes the
cursor to "wait" (i.e. loading circle graphic). I've included an
"AddClass" call in "preventDoubleFormSubmit", so that the cursor graphic
will change to show users that the page is loading so that they don't
click Save again. Of course, even if they do click save again, there
will only be one submit. However, this way - as Chris Cormack mentioned
- the user knows that "something" is happening and that the form isn't
broken.
-------
Test Plan
Before applying patch...
1) Fill out the form for a new patron in the Patron module
2) Click "Save" several times
3) Once the page loads, you'll be shown a prompt that says that this
borrower already exists. You will have the option to view the
original record, edit the original record, or create a new patron
anyway
4) Click on edit the existing record, and delete the patron
Apply the patch
5) Repeat steps 1 and 2
6) Notice that your cursor has changed into a little "loading" circle
graphic when you hover over the "body" of the page, as well as any
links or any inputs/buttons of the type "submit" within that form
7) Notice that no matter how many times you press the button, the form
is not re-submitted. Eventually you will be taken to the new patron's
record (no mention of duplication will occur)
Ta da! Multiple form submits are prevented and the loading graphic
signals to users that the form was submitted and that Koha is processing
their data
--
I understand that some people might want to change which elements are
given the "waiting" class. I'm happy to renegotiate this as necessary.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Looks good and works nicely.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch replace use of CGI::scroll_list() to show list of branches.
In two files, marc21_linking_section.pl and unimarc_field_4XX.pl,
the scrolling list is created but not used in the template file,
so the code is removed.
Also minor renaming/normalizing of variables.
To test:
1) Install with some branches, records and patrons
2.1) Select a record, click 'Place hold', select user,
there is a library pull-down next to 'Pickup at:',
list is ordered case sensitive
2.2) Go to Reports > Average loan time,
next to Library is a pull-down,
list without order
2.3) Go to Reports > Catalog by item type,
next to 'Select a library' is a pull-down,
list is ordered case sensitive
2.4) This is tricky, go to Reports home,
change last part of URL 'reports-home.pl' with
'manager.pl?report_name=issues_by_borrower_category'
(can't find a direct link), next to 'Select a library'
is a library pull-down,
list without order
2.5) Edit/Add a patron, on section 'Library management'
there is a library pull-down, case sensitive
2.6) OPAC, as logged user, make a suggestion or hold,
there is library pull-down, correct order
3) Apply the patch
4.1) Repeat 2.1), correctly ordered list
4.2) Repeat 2.2), correctly ordered list
4.3) Repeat 2.3), correctly ordered list
4.4) Repeat 2.4), correctly ordered list
4.5) This is a bit more work
There are 3 possible situations to test:
A) No branches, must show a message that are no
libraries defined
B) New patron, must show a correctly ordered
list of branches, current branch selected
C) Edit patron, must show a correctly ordered
list of branches, patron branch selected
4.6) Small changes on variable names, so retest 2.6)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Currently, if $ENV{DEBUG} is set (for example to 1), the debug level
will be printed on the Add/Edit Patron pages (memberentrygen.tt) in the
form of: "Debug is on (level 1)".
While many if not most folks might not set $ENV{DEBUG} on a production
system, there is no reason to have this information printing on the
member template(s).
No where else in Koha is there a template that prints $ENV{DEBUG}
information, with the exception of calendar.inc, although that doesn't
activate until at least debug level 2 or 5, so it might be worth holding
on to. It is certainly more complicated than simply printing the debug
level. I don't do development on the calendars, so I'm not going to
address that one.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Elliott Davis <elliott@bywatersolions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
As a result of accumulated changes to field names returned
by the members/default_messageprefs.pl service, the JavaScript
to change the patron messaging preferences to the category default
when changing a patron's category in the patron editor stopped
working.
To test:
[1] Turn on the EnhancedMessagingPreferences feature.
[2] Set message preference defaults for at least two
patron categories.
[3] Before applying the patch, create a new patron record
using one of the categories you set prefs for, then
change the category, then change it back again. You
will see that numeric settings like the number of days
for advanced notices will change, but checkboxes won't change.
[4] Apply the patch, then create a new patron record and
try changing the patron category. You will see that all of
the preferences will get updated to the category default
each time you change the category.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
A typo in my patch for Bug 9265 (HTML5 switch) left an extra quotation
mark in a <script> tag on the patron entry form, causing JavaScript
code to be output as text instead of interpreted. This patch corrects
it.
To test, apply the patch, enable EnhancedMessagingPreferences, and load
the patron entry form. You should see no JavaScript on screen around
the 'Patron messaging preferences' fieldset.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch replaces the XHTML DOCTYPE with an HTML5 one. The HTML5
validator seems to be significantly different than the XHTML one,
so I'm seeing lots of new errors. This patch includes corrections
for one: Deprecation of the "language" attribute of <script>
tags.
To test, view pages in the OPAC and staff client. They should
appear as normal. Numerous validation follow-ups will be required,
but I suggest these be handled incrementally.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
test on some intranet pages and I found no regression. (chromium and
firefox).
The w3c page about the doctype: http://www.w3.org/TR/html5-diff/#doctype
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>