Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the ability to set an unlimited number of guarantors
for a given patron. As before, each guarantor may be linked to another
Koha patron, and all the behavior that applies to a given guarantor
remains the same.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Find some patrons with guarantors, verify the still have their guarantor
4) Test adding and removing guarantors on a patron record, both Koha users and not
5) Verify the "Add child" button works
6) Verify NoIssuesChargeGuarantees still works
7) Verify tools/cleanborrowers.pl will not delete a guarantor
8) Verify the guarantors are displayed on moremember.pl
9) Verify the guarantor is removed by members/update-child.pl
10) Verify the guarantor is removed by misc/cronjobs/j2a.pl
11) Verify import patrons converts guarantor_id, relationship, contactfirstname,
and contactsurname into a guarantor
12) prove t/Patron.t
13) prove t/db_dependent/Circulation.t
14) prove t/db_dependent/Circulation/NoIssuesChargeGuarantees.t
15) prove t/db_dependent/Items.t
16) prove t/db_dependent/Koha/Patrons.t
17) prove t/db_dependent/Members.t
18) prove t/db_dependent/Patron/Relationships.t
Signed-off-by: Kim Peine <kmpeine@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch ties the alternate address and alternate contact address
fields in the patron entry form to the cities and towns data. This
provides a dropdown of predefined city data to these address fields.
To test, apply the patch and edit a patron record.
Test city selection for all three address fields: Main address,
alternate address, and alternate contact. Confirm that city selection
works correctly and that your changes are saved correctly.
Perform these tests with all AddressFormat options: French, German, and
US.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Many SMS messaging services reject numbers that do not conform to the E.164 international public telecommunication
numbering plan.
We already tell patrons on the OPAC "Please enter numbers only. (123) 456-7890 would be entered as 1234567890."
but we do not enforce this. We should be validating the patron's SMS number on both the staff side and the patron
self-service for updating the SMS number.
Test plan:
1) Apply this patch
2) Enable SMS message ( you can set to Email to enable )
3) Test entering and updating SMS numbers on the OPAC and staff
interfaces.
4) Note you can only enter a 1 to 14 digit number with an optional + sign
at the beginning ( used to indicate the number includes a country calling code )
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Changes:
- Replace getting preference ExtendedPatronAttributes by Koha.Preference
in templates
- Add Koha::Patron->attributes for getting patrons extended attributes
- Use this method in circ-menu.inc
- Remove getting attributes from members perl scripts
Test plan:
0) Apply the patch
1) Add some patron attributes type - with free text, authorised value,
limited by libraries...
2) Add some values to this attributes for some patrons
3) Go through as many patron pages as you can and confirm that
attributes are shown at side panel when they shoul and are not shown
when they should not be shown
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT] Removed Koha/Schema/Result/BorrowerAttribute.pm
[EDIT] Added missing semicolon on L114 in Koha/Patron/Attribute.pm
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes a number of changes in order to improve the way the
staff client's header menu adjusts at narrower browser widths:
- Updated version of Bootstrap 3.3.7 which includes the "collapse"
JavaScript plugin.
- Modified default Bootstrap CSS using Bootstrap's customization tool.
These changes facilitate the removal of some custom CSS (overriding
Bootstrap) from staff-global.scss.
- Added Bootstrap config file for loading customizations at
https://getbootstrap.com/docs/3.3/customize/
- Revised button classes for buttons in Bootstrap-styled toolbars.
The modified default CSS resets the base font size in Bootstrap to
better match our global CSS. A side-effect of this is that toolbar
buttons ended up looking smaller than they should. Changing the
button class solves this.
- Restructure the header menu in order to allow different rules to
govern the appearance of the navigational part of the menu
(Circulation, Search, etc) and the user menu (Set library, My
account, Log out).
- Modify the cart JS to so that the popup works well at narrow widths.
To test, apply the patch, regenerate the staff client CSS, and clear
your browser cache.
- Log in to the staff client and observe the layout of the header menu
as you adjust the browser to various widths.
- Confirm that sections of the menu "collapse" as the window gets
narrower.
- Confirm that dropdown menus behave correctly and that links work.
- Confirm that the Cart link works as expected when the cart empty
and when it has items.
- Install and enable multiple translations, including at least one
set of sub-languages (e.g. fr-FR and fr-CA).
- Test the appearance of the language menus in the footer at
various browser widths.
- View pages with button toolbars and confirm that they appear unchanged
(e.g. biblio detail page, patron detail page).
NOTE: While this patch is intended to make improvements to staff client
responsiveness, it does so within a limited scope. There are still many
pages which do not work well at narrower browser widths.
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes a couple of corrections to the selectors used by
hcsticky in targeting the position of the floating toolbar. These
changes were made necessary by changes made in recently-pushed patches.
To test, confirm that these two pages work correctly:
- Acquisitions -> Vendor -> View basket
- Patrons -> New patron
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch replaces the fixFloat jQuery plugin with a new one: HC-sticky
(https://github.com/somewebmedia/hc-sticky). This plugin provides the
same functionality without the page-reflow problems fixFloat suffers
from.
To test, apply the patch and regenerate the staff client CSS. Test the
behavior of the floating toolbar on these pages:
- Acquisitions -> Vendor -> Vendor details
- Acquisitions -> Vendor -> View basket
- On both these pages, test toolbar behavior before and after
expanding the "Orders search" options at the top of the page.
- Administration -> System preferences
- Authorities -> Create or edit an authority
- Catalog -> Advanced search
- Search results
- Catalog -> Item search
- Cataloging -> Add or edit a record
- Open the plugin window for the 008 field
- Tools -> Label creator -> New label batch -> Add items -> Search ->
Results
- Patrons -> New patron
- Test before and after expanding the patron search options at the
top of the page
- Test editing a patron too
- Tools -> Automatic item modifications by age -> Edit
- Tools -> Notices & slips -> Edit
- Lists -> View list
Check that the About page has been updated with information about the
plugin.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch modifies several patron templates to use the Bootstrap grid
instead of YUI.
This patch also removes obsolete "text/javascript" attributes from
<script> tags in the modified templates.
To test, apply the patch and view the following pages, confirming that
they look correct at various browser widths:
- Patrons home page
- New patron
- Patron -> Fines -> Create manual invoice
- Patron -> Set permissions
- Patron -> Change password
- Patron -> Edit
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch removes a block of JavaScript from memberentrygen.tt which
was being included in the page before jQuery is loaded. This causes a
JavaScript error.
To test, apply the patch, regenerate CSS, and clear your browser cache
if necessary.
- In Administration -> Patron categories, confirm that you have two
patron categories with different default messaging preferences
defined.
- Go to Patrons -> New patron
- Create a new patron using one of the categories with messaging
preferences.
- Confirm that when you switch the category selection to the other
patron category, the patron messaging preference checkboxes are
changed to the default for that category.
- A "Loading" indicator should appear above the checkboxes to show
that an operation is in process. It should disappear when new
default prefs are loaded.
- Manually change one or more patron messaging preference checkboxes.
- Switch the patron category again and confirm that you are prompted
to confirm resetting the preferences to the default for that
category.
- Perform the same set of tests when editing a patron.
- Defaults should not be loaded during the edit process.
- Confirm that there are no other JavaScript errors in the console.
- Test again with EnhancedMessagingPreferences disabled.
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The CSS for <div class="error"> is obsolete and should not be used. This
patch removes the definition from the main CSS file and corrects
instances of its use in the templates to the standard <div class="dialog
alert">.
To test:
- In Acquisitions -> Late orders, locate an order from a vendor which
doesn't have an email address. Selecting that order and clicking
"Claim" should trigger an error dialog, "This vendor has no email." It
should be styled correctly.
- With AcqCreateItem set to "when placing an order," add to an existing
order using the "From a new (empty) record" option. Add two items with
identical barcodes and submit the form. A error should show at
the top of the page.
- With AcqCreateItem set to "when receiving an order," receive an order
and add two items with identical barcodes. Submitting the form should
trigger an error message at the top of the page.
With the remaining cases I don't know how to trigger the errors in
question, so a visual check of the changes may be required:
- Administration -> Funds -> "You are not authorized to modify this
fund"
- Administration -> Search engine configuration
(/admin/searchengine/elasticsearch/mappgings.pl) -> Various
modification errors.
- With the AutoEmailOpacUser preference set to "send," adding a patron
without an email address can trigger an error, "This member has no
email."
- With plugins enabled, and installed, there are error messages
displayed under various circumstances.
Signed-off-by: Andrew Isherwood <andrew.isherwood@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
When a patron attribute class (AV PA_CLASS) is created, the patron's
edit view is broken:
https://screenshots.firefox.com/62uNhoUtH6rPXm9l/pro.kohadev.org
To recreate:
1. Create 1+ authorised values PA_CLASS
2. Create patron's attributes using it
3. Edit a patron
it depends on the order of the fieldset and the ol elements
This is certainly not the best fix but the display does not look broken!
Signed-off-by: Andrew Isherwood <andrew.isherwood@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch has been generated with the script provided on bug 21576.
It only affects variable used in the href attribute of a link *when*
href it the first attribute of the node (grep "a href")
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Why? Because we must filter the variables when we display them.
If we escape them on assignement, they will be double escaped:
[% XXX = "<span>pouet</span>" | html %]
[% XXX | html %]
=> <span>pouet</span>
Also it will bring trouble if we are assigning a structure (see bug
21663 for instance).
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch removes members-menu.inc and replaces the last functional use
of it with a call to circ-menu.inc.
An invalid use of members-menu.inc has been removed from member.tt.
To test, apply the patch and open a patron record for editing. The
sidebar menu should look correct and all sidebar links should work
correctly.
View the patrons home page and confirm that nothing has broken.
Search the Koha codebase for references to members-menu.inc. There
should be none.
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 11401 introduced code to support Norwegian national library card.
This code is too specific to be part of Koha as it, it should be a
plugin instead.
Moreover nobody uses it, but a modified version (see comment 3).
Test plan:
Add/edit/delete patron and make sure there are no regressions introduced
by these patches
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@deichman.no>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Here we go, next step then.
As we did not fix the performance issue when autofiltering
the variables (see bug 20975), the only solution we have is to add the
filters explicitely.
This patch has been autogenerated (using add_html_filters.pl, see next
pathces) and add the html filter to all the variables displayed in the
template.
Exceptions are made (using the new 'raw' TT filter) to the variable we
already listed in the previous versions of this patch.
To test:
- Use t/db_dependent/Koha/Patrons.t to populate your DB with autogenerated
data which contain <script> tags
- Remove them from borrower_debarments.comments (there are allowed here)
update borrower_debarments set comment="html tags possible here";
- From the interface hit page and try to catch alert box.
If you find one it means you find a possible XSS.
To know where it comes from:
* note the exact URL where you found it
* note the alert box content
* Dump your DB and search for the string in the dump to identify its
location (for instance table.field)
Next:
* Ideally we would like to use the raw filter when it is not necessary
to HTML escape the variables (in big loop for instance)
* Provide a QA script to catch missing filters (we want html, uri, url
or raw, certainly others that I am forgetting now)
* Replace the html filters with uri when needed (!)
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Since bug 20226 you cannot longer creation a patron, memberentry.pl will
explode with
Template process failed: undef error - DBIC result _type isn't of the
_type Category at /home/vagrant/kohaclone/koha-tmpl/intranet-tmpl/prog/en/includes/str/members-menu.inc
line 22.
The problem is that "patron" is actually defined and the test in
str/members-menu.inc does not work as expected.
It comes from
commit 7b1d08df0f
Bug 19936: Replace Generate_Userid - Update the occurrences
where I needed $patron to be defined in order to use Koha::Patron->generate_userid
on an blessed object.
But this was actually wrong, as it could have side-effects.
Test plan:
Create a new patron
Edit it
Retest bug 19936 and make sure the userid is generated correctly in the
different situations
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
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>
