This patch updates the existing occurrences of ->find called in a list
context.
There are certainly others that are not easy to catch with git grep.
Test plan:
Confirm that the 4 modified scripts still works as expected.
We need this one ASAP in master to make sure we will not get other
side-effects of this kind and to catch possible uncaught occurrences
before the release.
Tested scripts changed by this patch, they work as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
This patch updates the existing occurrences of ->find called in a list
context.
There are certainly others that are not easy to catch with git grep.
Test plan:
Confirm that the 4 modified scripts still works as expected.
We need this one ASAP in master to make sure we will not get other
side-effects of this kind and to catch possible uncaught occurrences
before the release.
Tested scripts changed by this patch, they work as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The parameter change in Koha::Token should be applied to the calling
scripts.
Test plan:
Confirm that the different forms of the scripts modified by this patch
still work correctly.
Test the problematic behavior:
Open 2 tabs with in same user's session, go on the edit patron page
(memberentry.pl).
Log out and log in from the other tab.
Submit the form
=> Wrong CSRF token should be raised
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Julian Maurice <julian.maurice@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>
If the userid of the logged in user contains unicode characters, the token
will not be generated correctly and Koha will crash with:
Wide character in subroutine entry at /usr/share/perl5/Digest/HMAC.pm line 63.
Test plan:
- Edit a superlibrarian user and set his/her userid to '❤' or any other strings
with unicode characters.
- Login using this patron
- Search for patrons and click on a result.
=> Without this patch, you will get a software error (with "Wide
character in subroutine entry" in the logs).
=> With this patch, everything will go fine
You can also test the other files modified by this patch.
Signed-off-by: Karam Qubsi <karamqubsi@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
As said in the previous commit, I considered SetAge as unnecessary and
removed it.
Test plan:
1/ Edit a patron using the different 'Edit' links
2/ Play with the patron category limited to age ranges, and date of
birth
3/ You should get the expected warning if the date of birth is inside
the patron category date range.
To finish:
prove t/Circulation/AgeRestrictionMarkers.t t/db_dependent/Reserves.t \
t/db_dependent/Koha/Patrons.t t/db_dependent/Members.t
should return green
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
From the pod of Digest::MD5:
"""
Since the MD5 algorithm is only defined for strings of bytes, it can not
be used on strings that contains chars with ordinal number above 255
(Unicode strings). The MD5 functions and methods will croak if you try
to feed them such input data.
What you can do is calculate the MD5 checksum of the UTF-8
representation of such strings.
"""
Test plan:
- Set a MySQL/MariaDB password with unicode characters:
UPDATE user SET password=PASSWORD('❤') WHERE USER='koha_kohadev';
FLUSH PRIVILEGES
- Update your $KOHA_CONF file
- Restart Memcached
- Hit the files modified by this patch
=> Without this patch, you will get a software error (with "Wide
character in subroutine entry" in the logs).
=> With this patch, everything will go fine
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit: removed debugging leftover
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Following patron modification partial editor had no age constraint
checking:
/cgi-bin/koha/members/memberentry.pl?op=modify&borrowernumber=3&step=3
Test plan:
1) Apply the patch
2) Open profile of a patron
3) Click Edit under "Library use": http://prntscr.com/d1ghim
4) Change category to an invalid one (eg. Adult instead of Kid)
5) Error saying "Patron's age is incorrect for their category." should
be displayed.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lucio Moraes <lmoraes@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This bug has been highlighted by bug 15407.
The date limit check on the category code did not work on step 1. But
after bug 15407 the script crashes with
Can't call method "dateofbirthrequired" on an undefined value at
/home/vagrant/kohaclone/members/memberentry.pl line 311.
Test plan:
- Edit "step 1" information of a patron (first 'Edit' on a patron detail
page).
- Save
=> Without this patch it BOOMs
=> With this patch, the info should be correctly saved
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The subroutine C4::Koha::GetAuthorisedValueByCode returned the
description (staff or opac) for a given authorised value.
Note that we may need a unique key to ->find instead of ->search.
Test plan:
- Checkin an item that cannot be checked in because it's lost, the
message should display the AV description
- Generate a letter with borrowers.streettype equals an ROADTYPE AV, the
description should be displayed.
- Edit a patron attribute type, the AV dropdown list should be
displayed
- Create the PA_CLASS AV category (see bug 7154) and make sure it
behaves as before when editing a patron
- The checkout list should display descriptions for LOC, LOST and
DAMAGED
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To reproduce:
- Go to Home > Administration > Patron categories
- Make sure that you have only one category for a category type.
Examples: Only one category "Staff" for category type "Staff" or
Only one category "Library" for category type "Org."
- Edit a patron or create a new patron
- Verify that categories of examples above do not show up in category drop down
- Go back to Home > Administration > Patron categories and add categories to
both category types
- Edit or create a new patron. Veryfy that categories show up in dropdown.
To test:
- Apply patch
- Make sure you have a category type with only one category assigned
(e.g. category taype Staff with category Staff)
- Edit a patron or create a new patron. Verify that the category
shows up in categroy drop down.
- Additional test: Verify that template param 'catcode' from removed line
is not used in template memberentrygen.tt
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Given that the issue is trying to call a method on something that isn't
an object, because the category code doesn't exist, then why is it
even trying to change the expiry date? A simple postfix if fixes it.
Applied counter-patch by M. Tompsett. All three patron 'Edit' links
mentioned in previous patch's test plan work fine.
Signed-off-by: Andreas Roussos <arouss1980@gmail.com>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch moves the code from C4::Members::GetExpiryDate to
Koha::Patron::Categories.
Nothing much exiting, please follow test plan in next patches.
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This unnecessary complicated subroutine returned an arrayref and an
hashref of the patron categories available for the logged in user, for a given
category_type, ordered by categorycode.
This can now be done with the search_limited method.
Test plan:
- Same prerequisite as before
For the following pages, you should not see patron categories limited to other
libraries. They should be ordered as before this patch, by categorycode.
- Add/edit a patron, change his/her patron category value.
- On the 3 following reports:
reports/bor_issues_top.pl
reports/borrowers_out.pl
reports/cat_issues_top.pl
The display for these 3 reports are different than the 2 from the first
patch (borrowers_stats.pl issues_avg_stats.pl): they are ordered by
categorycode and the ones limited to other libraries are not displayed
(should certainly be fixed).
Note that the big part of this patch has already been tested before
(update child related: CATCODE_MULTI).
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The purpose of C4::Members::GetBorrowercategory was to return the patron
category for a given categorycode. This can be done easily with the
Koha::Patron::Categories->find method.
Test plan:
- Same prerequisite as before
- Edit a guarantor and confirm the information will be updated for his/her
guarantee(s).
- Update a child to adult patron (Note: Should not we hide the patron
categories limited to others libraries? If yes, it must be done on another
bug report).
There is a special behavior if there is only 1 adult category, the
user does not need to select a category. So the same as before with
only 1 adult patron category.
- Import a patron with a category_code which does not exist. You should
be warned.
- Modify some patron using the batch patron modification tool. The
patron category descriptions should correctly be displayed.
Note that the overduerules page has already been tested in a previous
patch.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
To reproduce:
- Go to staff client Home > Patron
- New patron
- Choose a category and fill form, submit
Result: Form reloads, patron data are not saved.
To test:
- Apply patch
- Repeat steps above
- Verify that patron data are saved and the new patron's
detail page displays
- Try to enter a duplicate patron (e.g. same surname, firstname
and birthday as above)
- Verify that a duplicate message appears
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::Members::checkuniquemember was not really nicely written, was only
used once and was not covered by tests.
I think it does not make sense to keep such complexity and have this
code in the subroutine/method.
Looking at this patch it seems that what this subroutine did can be done
easily in the pl script in few lines.
Test plan:
1/ Create 2 organisations with the same "surname": you should get a
warning.
2/ Create 2 patrons (non-organisation) with the same
surname/firstname/date of birth, you should get a warning
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>
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 patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@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>
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
The 'borrower' should not be used anymore, especially for new code.
This patch move files and rename variables newly pushed (i.e. in the Koha
namespace).
Test plan:
1/
git grep Koha::Borrower
should not return code in use.
2/
Prove the different modified test files
3/ Do some clicks in the member^Wpatron module to be sure there is not
an obvious error.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described. Tested with Circulation, Members/Patrons, Discharge,
Restrictions modules and the must common functionalities
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
C4::Members::getidcity and C4::Members::GetCities simply retrieved
cities info from the cities table.
The job done in members/memberentry.pl looked really weird and complicated.
Either I have missed something, or this patch can simplify it.
The expected behavior is:
1. Create a new patron => No city selected
2. Edit an existing patron => The borrowers.city value is selected
3. Add a guarantee => The borrowers.city of the guarantor is selected
4. Edit a guarantee => The borrowers.city of the guarantee is selected
Test plan:
Confirm that the expected behaviors are the ones before and after this patch.
Signed-off-by: Natasha <tasham_8@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.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>
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>
Test - Check file for 'konw', notice no instance
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Typo fixed
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
When userid is not provided when creating a new patron, it is generated
using surname and firstname. The bug is when userid is defined in
syspref BorrowerUnwantedField, the input text is missing in patron
creation form. When saving you always get an alert message :
"Username/password already exists". No patron can be created.
This patch corrects by adding this case to userid generation conditions.
Test plan :
- add 'userid' in syspref BorrowerUnwantedField
- try to create a new patron : /cgi-bin/koha/members/memberentry.pl
- there is not input text for userid
- choose non-existing surname and firstname
- click on save
=> Without patch : patron is not created, you see the alert message
"Username/password already exists"
=> With patch : patron is created, userid is generated with surname
and firstname
- remove 'userid' in syspref BorrowerUnwantedField and check it can be
defined in patron creation form
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
The issue is there, and this patch fixes it.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes C4::Dates from members/memberentry.pl
To test:
- Apply patch
- Add and edit patrons with and without birthdate as
mandatory field (syspref BorrowerMandatoryField)
- Verify that dates (birtdate, registration, expiration)
display and are stored correctly
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Tested with syspref BorrowerMandatoryField and
table borrowers.dateofbirth
Bug 14924 - (follow-up) Add date validation using eval
This patch adds a date validation (see comment #3).
To test:
- Apply patch
- Create a new user or edit an existing user
- Try valid dates for date of birth
- Try invalid dates as 0000-00-00 or 32/01/1970. You can can
copy/paste such strings to the date field, ignore the warning
message and submit. Verify that after submit you get a message
"Date of birth is invalid"
- Try the same with enrollement /expiry dates
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Tested with invalid dates.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended patch: I have splitted them to make them much more readable
(some lines were removed then added).
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is a(nother) vestige of Koha (2.2?).
This patch removes unused code related to the 'ethnicity'.
In detail:
There is no way to fill the ethnicity table.
There is no way to fill the borrowers.ethnicity and borrowers.ethnotes.
BUT if borrowers.ethnicity exists, the value is displayed on
members/moremember.pl (and only here).
Test plan:
Apply this patch and confirm there is no regression on
adding/updating/deleting patrons.
Note that you don't see the ethnicity value on the moremember.pl page even if a patron has it.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Script memberentry.pl contained a similar line.
Solution is simpler here.
Test plan:
[1] Add, change or clear the sms number at staff side.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 13970 removed some useful code to automatically set the guarantor
when creating a child.
But finally there is a better way to do the job, we just need to assume
that only children or professional can have a guarantor.
Test plan:
1/ Create an adult patron and add a child.
2/ The guarantor info should be retrieved and set on the child creation
page.
3/ Create an organization and add a child
4/ The guarantor info should be retrieved and set on the adult creation
page.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
This patch catches both cases, thanks Jonathan!
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
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>
Jonathan Druart agreed that C4::Input is vestigial code that should be removed.
Here is how I checked. First I found where C4::Input was used. Then, I checked
what functions are in the package: just checkdigit. Then, I confirmed that
checkdigit is not used at all in any acquisition, administration, or member
related perl scripts. Lastly, I took a look at our supposed test file for the
package. It was painfully sparse.
As such, this patch removes the test file and the package file, and removes
C4::Input references from these six files:
- acqui/addorderiso2709.pl
- acqui/basketgroup.pl
- acqui/neworderempty.pl
- acqui/uncertainprice.pl
- admin/aqplan.pl
- members/memberentry.pl
NOTE: neworderempty had 3 lines of it?! Didn't anyone see that?!
Here is the output of what I did to confirm this correction:
mtompset@debian:~/kohaclone$ git reset --hard origin/master
HEAD is now at 6e9086f Bug 3206: (QA followup) missing comma on sysprefs.sql
mtompset@debian:~/kohaclone$ git grep C4::Input
C4/Input.pm:package C4::Input; #assumes C4/Input
C4/Input.pm:C4::Input - Miscellaneous sanity checks
C4/Input.pm: use C4::Input;
acqui/addorderiso2709.pl:use C4::Input;
acqui/basketgroup.pl:use C4::Input;
acqui/neworderempty.pl:use C4::Input;
acqui/neworderempty.pl:use C4::Input;
acqui/neworderempty.pl:use C4::Input;
acqui/uncertainprice.pl:use C4::Input;
admin/aqplan.pl:use C4::Input;
members/memberentry.pl:use C4::Input;
t/Input.t: use_ok('C4::Input');
mtompset@debian:~/kohaclone$ grep sub C4/Input.pm
sub checkdigit ($;$) {
my $temp2 = substr($infl,$i,1);
if ($rem eq substr($infl,8,1)) {
} # sub checkdigit
mtompset@debian:~/kohaclone$ grep checkdigit `find acqui -type f`
mtompset@debian:~/kohaclone$ grep checkdigit `find admin -type f`
mtompset@debian:~/kohaclone$ grep checkdigit `find members -type f`
mtompset@debian:~/kohaclone$ cat t/Input.t
use strict;
use warnings;
use Test::More tests => 1;
BEGIN {
use_ok('C4::Input');
}
Apply this patch, and the output of git grep C4::Input will be empty.
Run koha qa test tools (kind of overkill)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
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>
The check on the ages limits is only done when the dateofbirth field is
mandatory, which does not make any sense.
This check should be done when the field is filled.
Test plan:
1/ Remove the dateofbirth field from the BorrowerMandatoryField pref
2/ Create a patron category for teenager (say between 12-17y)
3/ Try to create a patron in this category outside the range of the ages
limits.
You should not be able to do it.
Signed-off-by: Christopher Brannon <cbrannon@cdalibary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When editing a Patron's messaging preferences or borrower attributes, one cannot
save changes because 'userid' is not given as a parameter.
It shouldn't, but the
Check_Userid($newdata{'userid'},$borrowernumber) -check must have it.
REPLICATE THE ISSUE:
1. Find a Borrower.
2. Go to the details-tab.
3. Under "Patron messaging preferences" click edit to edit just the messaging
preferences.
4. Just save, no need to make any modifications.
5. Observe the error "Username/password already exists"
This happens to all/most of the sub-forms in the Borrower's Details-view.
AFTER THIS PATCH:
Check_Userid() get the $userid from the new parameters, or if not present, from
the koha.borrowers-table.
TEST FOR REGRESSION:
1. Edit a borrower normally. Notice no errors.
2. Edit a sub-form (Alternate address/Patron messaging preferences). Notice no
errors.
DISCLAIMER: You are free to steal/rip/modify/hack this patch to your soul's
extent without my permission. As long as it makes to Koha I am happy.
Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
