We are using Koha::Logger when it makes sense to keep the info,
otherwise we simply remove it
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 28572: Replace missing occurrence in misc/admin/koha-preferences
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch is a follow-up of bug 16154.
It removes the warning "CGI::param called in list context" in the
following scripts:
admin/branches.pl
admin/categories.pl
admin/patron-attr-types.pl
admin/preferences.pl
catalogue/image.pl
circ/circulation.pl
patroncards/add_user_search.pl
serials/add_user_search.pl
tools/marc_modification_templates.pl
virtualshelves/shelves.pl
Note that the warning from catalogue/itemsearch.pl still exists (the
call to CGI->param is done from the template).
Test plan:
- Add/modify a library, patron category, patron attr type
- Update a syspref
- Set localcoverimage and call catalogue/image.pl?biblionumber=XXX
- Search for patrons in the patron cards or serials module
- Add a marc modification templates
- Add a list (shelves)
You should not get the warning in the log after all these actions.
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>
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>
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>
If you have enhanced messaging preference, the Days in Advance combo
value (in Patron Messaging Preferences) is saved in the database but
not retrieved when you have not enabled the Email checkbox (or checkbox
for any other transport) next to it.
This patch does the following:
[1] It replaces a JOIN by a LEFT JOIN that is the actual reason of the
problem described.
[2] Removes a FIXME by saving a hardcoded 30 into a constant.
[3] Fixes a typo in the neighborhood.
[4] Removes a superfluous comma in the map statement.
[5] Simplifies code for the selected field of the days combo. It should
just be a boolean. The text selected="selected" is in the template.
Test plan:
[1] Enable enhanced messaging preferences.
[2] Fill in Days in advance for Advance notice but uncheck Email.
[3] Save the preferences.
[4] The member home screen does not display the number of days (until you
decide to apply this patch :)
Followed test plan. Works as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
There is a flaw in C4::Members::Messaging::GetMessagingPreferences where
the system assumes that every transport will use the same letter. This
is not necessarily true. Even with the default preferences of just
'email' and 'sms', we should be able to have different letters
for each, as one has a maximum character length ( sms ) and one
does not. GetMessagingPreferences currently uses the letter code
of the last result of its query as the letter code for every transport type.
The returned data is a hashref with a key 'transport_types' that is
an array of transport_types this borrower has selected for the given
alert.
This commit modifies GetMessagingPreferences such that the the
'transport_types' array is now a hash where the name of the transport
type is now a key to the value of the letter code set for that transport
type.
It also modifies code calling GetMessagingPreferences where necessary,
and as a side benefit will correctly get the letter codes for email
and sms correctly, if they are defined differently.
http://bugs.koha-community.org/show_bug.cgi?id=4246
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
In use in production by two libraries: Middletown and Washoe
who give their sign off but don't have git to do so.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Correction for opac-messaging.tt tops tag attribute markup from
being passed to the template directly in favor of using template
logic.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Modification of template to allow multilanguage support. Alsa fixing columns
overflow.
BibLibre bug #5939
Tests: It works. Messages strings can now be extracted and placed in .po file
for translation.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
The messaging prefs form was hardcoded to use 'transport-$transport_type', rather than
'transport_$transport_type'. The result was an uneditable messaging preferences form.
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This was due to poorly constructed SQL which returned duplicate values for
certain fields. This patch corrects that SQL.
NOTE: There is also a formatting problem with the message prefs display table
when it is displayed in moremember.pl. This is due to there being no logic to
tell the table in that context to display checkboxes as appropriate. This patch
does not fix that. Bug 5328 has been opened for this problem.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
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>
Define and use a new module, C4::Form::MessagingPreferences,
to handle displaying and processing the messaging preferences
form. This change reduces code duplication between OPAC
and staff.
Signed-off-by: Daniel Sweeney <daniel.sweeney@liblime.com>
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Jonathan Druart
Jonathan Druart
Marcel de Rooy
Kyle Hall
Owen Leonard
Chris Cormack
Sophie Meynieux
Ian Walls
ByWater Solutions
Galen Charlton
Lars Wirzenius
Galen Charlton