.. by blanking cardnumber in the code and showing it in the template,
instead of just not showing it in the template
Autobarcode now correctly fills in on a duplicated patron.
Signed-off-by: Melia Meggs <melia@test.bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Currently, error message reports an age range in English. For example '0 to
17'. With this patch, the 'to' is not in the .pl file anymore.
Ruth could you sign-off this fix?
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch works around the redefinition of an array that was causing the
enforcement of age ranges to not-happen.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
I can confirm the bug and the solution.
Implements support for Talking Tech I-tiva phone notification for OVERDUE, PREDUE and HOLD notifications.
Overdues respect triggers as configured for the patron's branch.
Predue and Holds notifications respect patron's messaging preference choices.
A new column for phone notification is added if the TalkingTechItivaPhoneNotification system preference is turned on
Record of phone messages being sent to patrons is added to the patron's Notices
tab; notice of success or failure can be retrieved from I-tiva.
See the TalkingTech.README for installation and set-up instructions.
Aside from the control system preference, and the necessary changes to Messaging Preferences
forms to make use of phone notifications, the bulk of the code resides in external
cronjobs.
TalkingTech_itiva_outbound.pl generates the Spec C file to send to I-tiva. Actual transmission
of the file must be handled by the system administrator.
TalkingTech_itiva_inbound.pl processes the received Results file from I-tiva. Getting the
file from I-tiva to Koha is the job of the system administrator, as well.
Both scripts have a --help option with full documentation.
The only necessary change to core Koha behavior is in C4::Letters::EnqueueLetter. The return
value was changed from 0 or 1 (successful addition of letter to message_queue or not), to the actual
insert ID of the letter. This was required by the outbound script to present a unique Transaction ID
for the notice added to the patron's record (so a 'sent' or 'failed' status could be updated). Since
the dbh and sth are not shared, and the last_insert_id() command is table-specific, this should be thread-safe.
No changes are necessary to any parts of Koha, as all usage of EnqueueLetter currently ignores the return value.
To Test:
1. Turn on TalkingTechItivaPhoneNotification system preference
2. Verify that 'phone' is now a valid notification option for patrons on both staff and OPAC side
3. Attempt to set a 'phone' preference for PREDUE or HOLD messaging; attempt should succeed
4. Set up the patron for notices to triggers:
a. include checked out items due in a range of days, including the value set up in their messaging preferences.
b. place several holds, some in position, others waiting for pickup, others in transit.
c. set the patron up to have overdues, overdue by a range of days that includes the delay values for
the patrons branch and categorycode
5. Run TalkingTech_itiva_outbound.pl --type=RESERVE --type=PREOVERDUE --type=OVERDUE --outfile=/tmp/talkingtechtest.csv
The resulting talkingtechtest.csv file should include all the items due on X days (where X is the patrons' preference),
and none of the ones due in other increments. Similarly, overdues messages should be added for each item due by a delay
value as configured; overdues of other numbers of days should be ignore. Holds that are waiting pick up or in transit should
have messages, those still pending should not.
Messages should be added to the patron's notices tab for each issue sent. Verify these messages exist, and all Notices
tokens are replaced with appropriate information.
Repeat, this time with 4c making use of the default branch overdue triggers, instead of branch-specific triggers.
To test the inbound script, create a CSV with rows in the format "<<Message_id>>","<<SUCCESS or FAIL>>"
Message ID should correspond to the final column of the talkingtechtest.csv file (the transaction id) for the message.
Primary Authorship: Ian Walls
Additional modifications: Kyle M Hall
http://bugs.koha-community.org/show_bug.cgi?id=4246
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Tested and in use in production by two public libraries : Middletown
and Washoe. Both have given their sign off, but don't have git to
actually sign off.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Caused by code assuming a the variable $err is a hashref
when it is only a hashref if there is an error.
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
* group some attributes for a more friendly display
* allow a link between a borrower category and an attribute to display
it only for the specified category
* Attr classes filled with AV 'PA_CLASS' category (you have to create AV
with a new category 'PA_CLASS' to fill class list)
this patch add 2 fields in borrower_attribute_types :
category_code
class
Signed-off-by: Julien Sicot <julien.sicot@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
- Fix sql syntax error
- Fix Encoding
- SendAlerts must return an error if no email is defined
- Get error if no email in memberentry
http://bugs.koha-community.org/show_bug.cgi?id=7001
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Branches can have their own version of notices - added branchcode to
letter table.
Support html notices - added is_html to letter table.
Support for borrower attributes in templates.
GetPreparedletter() is the interface for compiling letters (notices).
Sysprefs for notice and slips stylesheets
Added TRANSFERSLIP to the letters
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch changes the password field to a password type input on
member-password.pl and adds a confirmation field to both member-password.pl
and memberentry.pl requiring that the password be re-entered to
confirm.
Client-side and server-side validation for the two password fields has been added
to both pages. Multiple error messages can now be displayed together on
member-password.pl.
If the user wishes for Koha to suggest a random password on member-password.pl
they can click a link which will remove the password-type input fields, replace
them with text-type fields, and automatically fill them with the random
password suggestion.
Follow-up fix lets the members.js correctly handling errors when there are
no mandatory fields
LR followup: fixing slight error that corrects previously reported template error.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Tested password setting/changing utilities - all work as expected and described.
Passes prove t xt t/db_dependent tests congruent with current master failures (adds no new fails).
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested with example from bug and by deleting parts of it:
cardnumber|surname|firstname|title|othernames|initials|streetnumber|streettype|address|address2|city|state|zipcode|country|email|phone|mobile|fax|emailpro|phonepro|B_streetnumber|B_streettype|B_address|B_address2|B_city|B_state|B_zipcode|B_country|B_email|B_phone|dateofbirth|branchcode|categorycode|dateenrolled|dateexpiry|gonenoaddress|lost|debarred|contactname|contactfirstname|contacttitle|borrowernotes|relationship|sex|password|userid|opacnote|contactnote|sort1|sort2|altcontactfirstname|altcontactsurname|altcontactaddress1|altcontactaddress2|altcontactaddress3|altcontactstate|altcontactzipcode|altcontactcountry|altcontactphone
Note: This only affects the edit screen, not the patron detail tab.
A nice enhancement would be to make this page follow the system preference too.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
QA comments on Bugzilla. Passing QA.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
* DBrev defined
* small improvement suggested by Marcel added = there is now a link to the schema page on the systempreference
Some code coming from BibLibre has been lost in the process of inclusion in
3.4. The result is that fine in days does not work at all (you can setup rules,
but it does nothing)
Step to reproduce:
- Koha > Admin > circ rules > set 1 day fine every day of overdue for default
rule
- Issue a book return date last week
- check-in the book => no debarment is set
The following patch will fix all of those problems by :
* updating borrowers.debarred to a date field (instead of tinyint). It contains
the limit of the debarment
* changing API of DebarMember and UpdateBorrowerDebarred to pass a date
* display debarrdate where applicable. Note that a debarrdate of 31/12/9999 is
considered as unlimited and not displayed
* added a debarrcomment, usefull to explain why a patron is debarred (this is
independant from debarrdate changes and can be used when placing an unlimited
debarment too)
[2011-05-12] F. Demians. It works as described. And I can confirm this
functionality is impatiently awaited by French libraries since one year. Thanks
BibLibre for the good work and for contributing this code.
Bug 6328 Followup--update DB structure
Thanks Katrin.
Bug 6328: make comment a textbox / fix debar by notice trigger
Debarring by notice triggers was broken, because the new function
expects a date as second parameter.
The comment field in patron account details was a very long text field.
Patch changes it to be a textbox instead.
Bug 6328: Lift debarment leaves patron account
'Lift debarment' redirects to an empty circulation page.
BZ6328 follow-up 3
Fixes comment 23 from Fernando L. Canizo : when the patron was debarred and debar removed
he still could not check-out.
The changes in the IsMemberBlocked (that were on biblibre/master) were lost somewhere
The sub was still checking for old_issues instead of calling CheckBorrowerDebarred
to get a debardate if applicable
Note : this bug was appearing only is you had issuing rules defined for itemtype/categorycode/branch.
Seemed to work if you had only default rules. That's probably why it hadn't been spotted before
BZ6328 follow-up 4
Comments fron Zeno Tajoli: The patch is OK and I sign-off it. Two little changes done on
installer/data/mysql/kohastructure.sql and installer/data/mysql/updatedatabase.pl
Signed-off-by: koha <koha@kohabase.localdomain>
When adding a patron who is a child, the default library is not set when defining a guarantor, this patch corrects the problem.
More, for children with no guarantors, the default branch is the editing branch.
BibLibre MT5795
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Now a blank cardnumber will get stored as a null in the database, which
is a value that allows duplicates. As such, if cardnumbers aren't
mandatory, then you can actually save a user with it being blank.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
If a guarantor search is not being performed, the creation of any Child category_type patron will
not default to the currently logged in branch, but rather the first branch alphabetically.
Adding a test for the existence of any guarantor branch data before assigning it clears up this problem
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This patch enables the ACCTDETAIL notices (and any branch-specific derivatives) to use
<<branches.*>> and <<borrowers.*>> tokens
This patch also attempts to send the email from the branch email first, falling back to
KohaAdminEmailAddress if no branch email exists.
To test:
1. Enable AutoEmailOpacUser system preference
2. Add <<branches.*>> tokens to the ACCTDETAIL notice
3. Create a new patron, including:
a. test email address in the field matching your AutoEmailPrimaryAddress syspref value
b. username and password (required to send a notice)
c. any other required fields to save the record
4. Check you inbox. Notice should send instantly (no need to run process_message_queue.pl)
Signed-off-by: Jared Camins-Esakov <jcamins@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
- Hiding patron add toolbar when branches or categories are undefined
- Blocking patron entry form if branches or categories are undefined
- Removing nonfunctional template logic for displaying missing category
error message.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Incorrect checking of guarantorid was causing moremember.pl to
try and construct addresses using data from non-existent guarantors
ensure that test is consistently checking that value is defined and not
'', '0' or 0 [ i.e. what perl does for you anyway!!]
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Rebased to current HEAD, small error fixed.
Should also apply to 3.2
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This add a verification, to allow automatic modification of expiry date, only if we are on a page that allow modification of expiry date.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
When editing patron attributes or messaging preferences on the
patron editor, Koha would crash with the following error:
Software error:
Can't use an undefined value as an ARRAY reference at
/home/koha/kohaclone/C4/SQLHelper.pm line 186.
This would occur only when editing the specific attribute
or message preferences section, not when editing the entire
patron record.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Garry Collum's patch correctly identified the core flaw in operation
looking closer revealed some other flaws (2 "blank" options, some vars
and documentation belonging to a superceded version, etc.
Changed GetCities to return a structure rather than the messy two returns
Let the template do the concatenation and removed the CGI::Popup
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Members modification when not in Library information mode would wipe out dateexpiry information
Signed-off-by: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
This update the way Member is added and editing so that import and Edition
could be best automatized
GetMember evolves and allow ppl to serach on a hash of data
Adding SQLHelper A new package to deal with INSERT UPDATE and SELECT
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
- added altcontactcountry and B_address2 to tables borrowers and deletedborrowers so that all addresses offer the same fields
- changed B_country and country to work with syspref BorrowerMandatoryField
- changed display of Alternate Address on borrower detail page, added labels, lines and edit button to match the other sections
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Before this patch, we used to test for flags == 1, which was wrong when patron had all privileges.
This patch just adds a %2 to check that patron has superlibrarian privilege, and maybe something else we don't care.
I think I fixed it everywhere except in acquisition, that will be addressed by BibLibre new acquisition module.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
The display and editing of messaging preferences
for a patron have been moved as follows:
* the prefs for a patron are now displayed on the
patron details tab, not the messaging tab.
* the prefs are now modified by editing the patron
record, not on the messaging tab.
The messaging tab now contains only the list of
messages that have been or will be sent to the patron.
When creating a new patron record, changing the patron
category via the category dropdown now also changes
the default messaging preferences for that patron. If
you start editing a new patron, change one of the messaging
preferences, then change the patron category, the form will
ask you if you want to keep the preferences or get
the defaults belonging to the new patron category.
Note that when you edit an existing patron record, changing
the patron category will *not* cause the messaging preferences
to be automatically changed.
Programmer's note: this commit introduces a new web service,
members/default_messagingprefs.pl, that uses Jesse Weaver's
C4::Service module.
Signed-off-by: Daniel Sweeney <daniel.sweeney@liblime.com>
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
$intflags was never used or returned if hashref instead of userid was passed.
Also cleaned up needless passing of $dbh.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
If a patron with a child patron category is not linked
to a guarantor (or a valid one), it was not possible to edit
the child patron's record. When attempt, no changes were saved
and the following error is recorded in the Apache error log:
memberentry.pl: DBD::mysql::st execute failed: Cannot add or
update a child row: a foreign key constraint
fails (`gmc_koha/borrowers`, CONSTRAINT `borrowers_ibfk_2`
FOREIGN KEY (`branchcode`) REFERENCES `branches` (`branchcode`)) ...
This patch fixes this bug, allowing a child patron record to be
edited even if it has no guarantor.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
The messaging tab already provided a way to configure these
notifications, so this isn't needed.
Signed-off-by: Daniel Sweeney <daniel.sweeney@liblime.com>
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Upon further testing, original patch for 2856 had effect
of displaying form with blank values when modifying
an existing patron record.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This patch activate the check of unique member, it was checked but not shown, and the member was added even if a duplicate was
detected.
It improve the duplicate detection, to check the birthdate only if it was specified in the form.
And fix an url of "Yes" link(if the borrower added IS the duplicate detected).
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
This patch change the method used to generate a new login for a user when his informations are modified(memberentry.pl).
Before the login are generated with the first letter of lastname and the 9 first letter of the surname, and do not verify the
login already exist).
Now the login will be lastname.surnameX, where X is an incremented digit if the login already exists.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>