Bug 15380 introduced a regression on the authority types admin page: the
default authority type (authtypecode="") is no longer editable.
Test plan:
Edit the authority type to update the summary
=> Without this patch you will get the "add a new authority type" form
=> With this patch applied, the correct behavior will be restored
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Because of a wrong variable scope, the classification sources are not
deletable.
Test plan:
Create a classification sources (admin/classsources.pl)
Try to delete it
Without this patch, the classification source won't be deleted
With this patch, it will work!
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Test plan:
Go on a page of the tools module
You should see a "Automatic item modifications by age" link
Click on it
The list should not be styled to highlight the fact that you are on this
page.
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
From commit b574b61591
Bug 15084: Make sure the previous active currency is marked as inactive
When a currency is stored, all the active flags of all currencies are unset.
Only the active ones and different than the one we are editing should be updated.
Test plan:
Edit the active currency
=> Without this patch the active flag was removed
=> With this patch, the active flag is kept
Edit another currency and set it the active flag
=> The active flag must have been removed from the previously active
currency.
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 a new patron is submitted which is suspected to be a duplicate, the
entry form is redisplayed with a new name attribute, "form_nodouble."
Other scripts on the page still look for a form named "form," so there
is an error.
This patch removes the use of "form_nodouble" on the assumption that it
is unnecessary to name the form something different when a duplicate is
suspected. All the same validation scripts should be run on the form
either way.
To test, apply the patch and clear your cache if necessary.
- Go to Patrons -> New patron and add a patron which matches an existing
one in order to trigger the duplicate warning.
- Confirm that Firebug (or similar) is not reporting a JavaScript error.
- Confirm that the 'Edit existing' and 'Save as new' buttons work
correctly.
Reproduced JavaScript error and verified that it no longer appears with
this patch.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
When a staff client catalog search returns no results, a Z39.50/SRU
search button is shown. This patch adds a Font Awesome icon to that
button.
Also changed: A stray extra double quote has been removed. The onclick
attribute has been removed from the search button in favor of an event
already defined.
To test, apply the patch and perform a search in the staff client
catalog which will return no results.
- Confirm that the Z39.50/SRU button looks correct and works correctly.
- Validate the HTML of the page and confirm that no unexpected errors
are returned.
NOTE: Pretty!
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
In Reports -> Saved reports, when the filter form returns no results a
dialog is shown. This patch updates the dialog to use Font Awesome
icons.
Also changed: The dialog now includes a button for creating a new SQL
report, not just one to create a new guided report. The "clear" link in
the sidebar has been modified to pass HTML validation.
To test, apply the patch and go to Reports -> Saved reports.
- In the left-hand sidebar filter, submit terms which will return no
results.
- Verify that the resulting dialog is correctly styled.
- Confirm that all three buttons in the dialog work correctly: New
guided report, new SQL report, and Cancel.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
I'm passing this one, while I don't like it is hardcoding a URL path,
because it will make is easier to spot it when time comes and we
make Koha delpoyable in any endpoint.
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch updates the tags moderation template to use text labels to
mark tag moderation status, eliminating the use of an image file to
signify approval.
To test you should have some tags in each approval state: pending,
approved, and rejected.
- Apply the patch and go to Tools -> Tags.
- Confirm that the status of each tag is clearly shown with a text
label.
Works as expected (Do not forget to set filter at the left to 'all' for testing)
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch updates the new patron template to use Font Awesome icons in
the dialog which is shown when a duplicate patron is suspected.
The patch modifies the CSS rules for a dialog button with "white-space:
pre-line" so that line breaks in button text markup are treated as line
breaks on display. Allowing the text to wrap prevents the buttons from
being too wide and stacking one below the other.
To test, apply the patch and go to Patrons -> New patron.
- Attempt to save a new patron with details matching an existing patron
in order to trigger the duplicate patron warning.
- Confirm that the resulting dialog is styled correctly.
- Confirm the behavior of both the 'Edit existing' and 'Save as new'
buttons.
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Import borrowers tool explodes if userid already exists. This error
should be caught to avoid the script to explodes.
TEST PLAN
---------
1) back up DB
2) drop DB, create empty DB
3) Apply patch 15842
4) web install all the sample data
5) login as system user and import patron data
-- sample provided to trigger error.
-- you will get a DBIx::class exception
"Duplicate entry ' for key 'userid'"
6) Apply this patch
7) Repeat steps 2-5
-- patrons won't be inserted but an error
will be nicely displayed in the error list.
8) run koha qa test tools
Note that it would be easy to insert the patrons anyway and generate a
userid based on the surname and firstname.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If you click on a link that opens a new tab/window to another site, that tab
has access to the original window through JavaScript. The browsing context is
related, even if the domains are totally different.
The tab retains access to the original window's object via window.opener, even
if you navigate to another page or domain, in the new or original window.
Access to the Window object means the new window can use Window.location to
open a different URL in the original window, perfect for phishing attacks.
Depending on the site's Same-Origin Policy settings, the new window may have
access to other parts of the original window's DOM as well.
Any 'A HREF' that contains a target of of '_blank' or '_new' or a fixed name
is vulnerable. Previous security best practice often suggested creating a random
fixed name for an unpredictable namespace - that won't help with this problem!
Targets of '_self' and '_parent' are safe.
We do not use _new (at first glance) but several _blank. Some are used
to refer internal url, we do not need to update or remove them. Others
are used to satisfy OPACURLOpenInNewWindow, in these case, we should add
the rel="noreferrer" attribute to the a tags.
In other cases, we can simply remove them and let the users discover
that a mouse has more than one button (we are in 2016, they can do it!)
Signed-off-by: Chris <chrisc@catalyst.net.nz>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Caused by commit 7e70202d34
Bug 15381: Remove GetAuthType and GetAuthTypeCode
If you execute perl misc/migration_tools/merge_authority.pl -f 1 -t 2
you will get:
Can't locate object method "authtypecode" via package "1" (perhaps you forgot to load "1"?)
at misc/migration_tools/merge_authority.pl line 58.
GetAuthority does not return a Koha::Authority but a MARC::Record:
there is no authtype code method!
Test plan:
perl misc/migration_tools/merge_authority.pl -f X -t Y
Should not return any error.
Note that if the authid X or Y does not exist, the script will die.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If a group of libraries is linked to at least 1 library, the group
cannot be delete and the librarian should get a warning message.
But if no libraries are linked, the deletion should be allowed.
Since bug 15294 this behavior is broken: The deletion is always blocked:
"This library category cannot be deleted. 0 libraries are still using
it", hum...
Test plan:
Create a group of libraries, delete it
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The major part of pages you can access from a patron detail page (menu)
does not take into consideration the 'patron does not exist' case.
If the borrowernumber is linked to a deleted patron, a friendly message
should be displayed instead of an empty patron detail page.
Test plan:
Go on circ/circulation.pl?borrowernumber=424242
and circ/circulation.pl?borrowernumber=424242&batch=1
Notice the difference before and after this patch
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 patron attributes displayed on editing a patron are not displayed if
limited to another library.
C4::Members::Attributes::SetBorrowerAttributes will now only delete attributes
the librarian is editing.
SetBorrowerAttributes takes a new $no_branch_limit parameter. If set,
the branch limitations have not effect and all attributes are deleted
(same behavior as before this patch).
Test plan:
1/ Create 2 patron attributes, without branch limitations.
2/ Edit a patron and set a value for these attributes
3/ Limit a patron attributes to a library (one you are not logged in
with).
4/ Edit again the patron.
=> You should not see the limited attributes
5/ Edit the patron attributes and remove the branch limitation
=> Without this patch, it has been removed from the database and is not
displayed anymore.
=> With this patch, you should see it.
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Do not crash if the patron does not exist.
Test plan:
Access circ/circulation.pl?borrowernumber=42424242
you should get an error without this patch
With this patch, you will get an empty patron detail page (should be
fixed in another patch, but this behavior exists for a while)
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Can't call method "guarantor" on an undefined value at
/home/koha/src/circ/circulation.pl line 588.
at /home/koha/src/circ/circulation.pl line 673
Introduced by bug 15656
Test plan:
Just trigger circ/circulation.pl
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Triggered circ/circulation.pl - nothing exploded, and error is gone
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch fixes the display of the currency symbol on invoice.tt
See comment #5
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To test:
- Reproduce error described in first comment.
- Apply patch
- Try to reproduce error. Page will display as expected.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Adds the actions class to the td elt to keep the buttons next to each
other.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To test:
1) Go to Administration -> Record matching rules
2) Confirm that the actions 'Edit' and 'Delete' are not buttons and behave as expected.
Sponsored-by: Catalyst IT
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This trivial follow-up adds an "actions" class to the table cell
containing the new buttons. In conjunction with the style update in Bug
16048, this will prevent the buttons from wrapping at narrow browser
window widths.
To test, apply the patch for Bug 16048 and go to Administration ->
Currencies and exchange rates.
In the table of currencies, confirm that the "Edit" and "Delete" buttons
are not stacked one on top of the other even at narrow browser window
widths.
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To test:
1) Go to Administration -> Currencies and exchange rates
2) Confirm that the actions 'Edit' and 'Delete' are now buttons and behave as expected.
Sponsored-by: Catalyst IT
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This trivial follow-up adds an "actions" class to the table cell
containing the new buttons. In conjunction with the style update in Bug
16048, this will prevent the buttons from wrapping at narrow browser
window widths.
To test, apply the patch for Bug 16048 and go to Administration ->
Libraries and Groups.
Confirm that the "Edit" and "Delete" buttons do not wrap even at narrow
browser window widths.
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
You forgot to add the class to one of the tables, but I have added it
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To test:
1) Go to Administration -> Libraries and Groups
2) Confirm that the actions 'Edit' and 'Delete' are now buttons for BOTH
tables under one column 'Actions' and buttons behave as expected.
Sponsored-by: Catalyst IT
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This trivial follow-up adds an "actions" class to the table cell
containing the new buttons. In conjunction with the style update in Bug
16048, this will prevent the buttons from wrapping at narrow browser
window widths.
To test, apply the patch for Bug 16048 and search for a vendor in
Acquisitions which has at least one open basket.
Confirm that the "View" and "Add to basket" buttons look correct and do
not wrap when you make your browser window narrower.
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
To test:
1) Go to Acqui -> do a vendor search
2) Confirm actions 'View' and 'Add to basket' are now buttons and behave as
expected
Sponsored-by: Catalyst IT
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
$borrower, $borrowernumber and $template and not visible in the
subroutine.
Using $b_ref and passing $template fixes the issue.
Test plan:
Under plack, use the pay selected button.
On the paycollect page, you should see the image of the patron
It certainly fixes some other bugs.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Accessing to the cache for each call to C4::Context->preference might
have an impact on performances.
To avoid that this patch introduces a L1 cache (simple hashref). It will
be populated by accessing the L2 cache (Koha::Cache).
If a pref is retrieved 10x, the first one will get the value from the L2
cache, then the L1 cache will be check.
To do so we will need to clear the L1 cache every time a page is loaded.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This reverts commit ca00f0ddae.
Bug 13805 fixes an installer bug by disabling the syspref cache.
It was not a good idea, it introduced performance issues (see bug 13805
comment 14).
Test plan:
Test plan:
0/ Create a new database and fill the database entry in the koha conf
with its name
1/ Go on the mainpage, you should be redirected to the installer
2/ Try to log in
You should not get the login form again.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Test plan not followed by me for this patch, due to lack of working
plack setup, but I don't expect it to cause any problems, and performace
gain for plack will be tremendous
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This in only in koha.psgi, it has been introduced by bug 13815 but
should not have been added by this patch.
Removing it should not introduce any changes.
Not that it won't impact debian packages.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch should not be the way to make these tests pass.
The prefs should not be updated using set_preference, it will modify the
values in the cache.
I have no idea how to make them pass using the correct way, please help
:)
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Otherwise some tests won't pass
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Unless in t/db_dependent/Context.t where we want to test the cache
behaviors.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
At the moment, the sysprefs are only cache in the thread memory
executing the processus
When using Plack, that means we need to clear the syspref cache on each
page.
To avoid that, we can use Koha::Cache to cache the sysprefs correctly.
A big part of the authorship of this patch goes to Robin Sheat.
Test plan:
1/ Add/Update/Delete local use prefs
2/ Update pref values and confirm that the changes are correctly taken
into account
Signed-off-by: Chris <chrisc@catalyst.net.nz>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Tested with plack with syspref cache enabled, there is some time between setting the syspref and applying it, but it takes just one reload of page, it shouldn't be problem, should it?
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Tested with CGI and CGI + memcache; some small issues still remain,
but it would be better to deal with them in separate bug reports
if necessary
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Most of the scripts called via greybox (which uses iframe) don't include
doc-head-close. But some do.
This patch adds a popup parameter for these templates, not to include
the legacy browser trick and avoid the replacement of the location.
Test plan:
1/ Export patroncard and label
2/ translate itemtypes
3/ click on a idref link at the OPAC
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
There are some places where frames are used, the greybox JS plugin for
instance.
We need either to allow them from Koha or replace this plugin.
The easier for now is to switch the value from DENY with SAMEORIGIN.
Test plan:
- modify a record in a batch (tools/batch_record_modification.pl)
- click on preview marc
=> With only the previous patch you will get a blank page.
=> With this patch apply, it will work as expected.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Web pages that can be embedded in frames are vulnerable to cross-frame
scripting attacks. Cross-frame scripting is a type of phishing attack
that involves instructions to an unsuspecting user to follow a specific
link to update confidential information in an online application.
Because the link leads to a legitimate page from the online application
that is embedded in a frame hosted by the attackers' server, the
attackers can capture all the information that the user enters.
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
There are links on the OAI sets administration page which can use Font
Awesome icons instead of being styled with background images. This patch
makes that change.
Another minor change: Added the "fa-fw" class to items in the "Actions"
menu which didn't have it. This helps the items line up correctly:
http://fortawesome.github.io/Font-Awesome/examples/#fixed-width
To test, apply the patches for Bugs 16014 and 15991 if necessary. Apply
this patch and:
- Go to Administration -> OAI sets configuration.
- Click the "New set" button and verify that the "Add description" link
uses a Font Awesome icon.
- Confirm that the "Add description" link works correctly.
- After adding a description, verify that the "Remove" link looks
correct and works correctly.
- From the list of OAI sets choose "Define mappings" from the "Actions"
menu.
- Confirm that the "Delete" button is styled correctly and works
correctly.
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Test plan:
Create or edit a patron (members/memberentry.pl), enter a date of birth
(for a new patron), patron'a age should be shown under
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Note:
QA question: Does the Koha::Patron->siblings method should return undef
if there is no guarantor?
It would avoid the weird != undef, = $borrowernumber conditions.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
2 subroutines of C4::Members deal with guarantor/guarantees:
GetGuarantees and GetMemberRelatives.
Since we already have a Koha::Patron->guarantor method, it makes sense
to move these 2 subroutines to this module.
This first patch deals with GetGuarantees.
Test plan for the entire patch set:
1/ Create 5 patrons A (adult), B (child), C (child), D (child), E
(child), F (adult)
2/ Add relation between them: A is father of B, C and D.
E does not have a guarantor
F does not have guarantees
3/ Check some items out for all of these patrons
4/ On the "Check out" and "Details" tabs, you should not see any
differences with these patch applied : The "Relatives' checkouts" tabs
should list all of the guarantor/guarantee/siblings checkouts
Note:
$template->param('C' => 1);
I have not found any reference of this 'C' in the template.
It seems it's an old c/p from members/memberentrygen.tt
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Looking at the code, there is some broken with the guarantees code.
It seems that the expected behavior would be to update address, fax,
B_city, mobile, city and phone info of the guarantees when a guarantor
is modified.
But the code in C4::Members::ModMember is broken:
668 my $borrowercategory= GetBorrowercategory(
$data{'category_type'} );
669 if ( exists $borrowercategory->{'category_type'} &&
$borrowercategory->{'category_type'} eq ('A' || 'S') ) {
670 # is adult check guarantees;
671 UpdateGuarantees(%data);
672 }
First, GetBorrowerCategory expects a categorycode, not a category_type.
Then UpdateGuarantees retrieves the param like:
989 sub UpdateGuarantees {
990 my %data = shift;
Which means that %data will always be something like ( a_key => undef )
And nothing more.
The updateguarantees subroutine (It has been renamed) has been introduced by
commit 56825e415f
Date: Mon Aug 30 13:48:58 2004 +0000
modularizing (with Members.pm) members management
(beginning of...)
And the `%data = shift` already existed...
This code has never worked and could be removed.
See http://lists.koha-community.org/pipermail/koha-devel/2016-January/042241.html
Test plan:
Confirm the previous assertions.
Note that I have found this bug working on bug 15631, see patch "Bug
15631: Koha::Cities - remove getidcity and GetCities"
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch changes the behavior of the audio alerts management page so
that sections of the page are shown or hidden based on what the current
task is. Other changes include:
- Moving JavaScript to a separate file
- Adding a toolbar with a "New alert" button.
- Enabling or disabling the "play sound" button based on the value of
the sound file field.
- Enabling or disabling the "delete" button based on whether there are
checkboxes checked.
- Switching the patron category administration header search form for
the "generic" catalog search one.
- Adding "Required" classes to required fields so that the staff
client's built-in JS validation library can be used.
- Styling the add/edit form in a way which is consistent with other
interfaces in Koha.
- Removing the invalid "border" attribute from images.
- Adding better alt attributes to images.
To test, the AudioAlerts system preference must be enabled. Apply the
patch and go to Administration -> Audio alerts.
- Confirm that the add/edit form is hidden initially. A toolbar with a
"New" button should appear with existing audio alerts in a table
below.
- Confirm that the "New alert" button works:
- The table should be hidden and an empty "add" form displayed.
- Confirm that an empty form cannot be submitted.
- Confirm that typing or selecting a sound enables the "Play sound"
button and that it works to play the sound.
- Confirm that adding valid data works.
- Confirm that clicking the "Cancel" button hides the form and
redisplays the table.
- Test the "edit" button for an existing sound:
- Confirm that the edit form is displayed and populated with the
correct data.
- Confirm that edits are saved correctly.
- When viewing the table of existing alerts, confirm that checking one
of the checkboxes "enables" the delete button.
- With one or more checkboxes checked, test that clicking the delete
button triggers a deletion confirmation. Test both confirm and cancel
operations.
- With no checkboxes checked, test that clicking the delete button
triggers an alert that checkboxes must be checked.
- Ponder whether all this is an improvement or not.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
