To Test:
Check if "fullfilled" has been changed to "fulfilled" in line 137
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
sucessfully ==> successfully
Test - Check that the word has been changed in file
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Typo fixed correctly
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@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>
Test- search for writen, if not found patch successful
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>
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Gus: You should try git grep writen one more time :)
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Test - due to noone being in a comparison name it was not changed
1. search for choosen, see that it was removed
2. search for agregate, see that it was removed
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Typos fixed
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
opac/ilsdi.pl: Stricture disabled at line 217, column 17. See page 429 of PBP. (Severity: 5)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Expression form of "eval" at line 71, column 9. See page 161 of PBP. (Severity: 5)
Expression form of "eval" at line 85, column 13. See page 161 of PBP. (Severity: 5)
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
- Subroutine prototypes used at line 86, column 1. See page 194 of PBP. (Severity: 5)
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Argument "" isn't numeric in numeric lt (<)
TEST PLAN
---------
1) Go to any patron in staff client
2) Click 'Edit'
3) Check error logs
-- warnings should exist.
4) Apply patch
5) Reload page
-- warnings should not be triggered.
6) Add restriction and save
7) Go back to edit screen
-- restriction should be shown
8) Remove restriction and save
9) Go back to edit screen
-- Should say "Patron is currently unrestricted"
10) Run koha qa test tools.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Avoid use of uninitialized value in split
== Test plan ==
1. Go to opac advanced search
2. Click "Search" without any search query
3. Log file will show "Use of uninitialized value in split at ..."
4. Apply this patch
5. Repeat step 1 and 2
6. Log file should no longer show "Use of uninitialized value in split at ..."
Sponsored-by: Regionbibliotek Halland / County library of Halland
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
At step 2 you have to check a criteria
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To Test Check perldoc for misc/cronjobs/advance_noitces.pl
and see that the documentation matches.
Ran:
$ perldoc misc/cronjobs/advance_noitces.pl
Saw expected changes.
Koha QA test tools pass too.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Switched due date for the name of the database column
date_due as the parameter expects a list of database
column names.
Removes warn using Jonathan's suggestion!
To test:
1) Reproduce warns by clicking New Subscription
2) Apply patch
3) Click New Subscription again
4) Confirm warns are gone
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Patch removes the warn that come when clicking "New subscription"
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test:
Create circulation records
Go to 'http://localhost:8081/cgi-bin/koha/tools/cleanborrowers.pl'
Anonymize patron checkout history
Message should read 'All checkouts older than [date] have been
anonymized
When patch is not applied, message reads 'All patrons with checkouts
older than [date] have been anonymized"
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
With the changes for RDA now more subfields for the fields
100, 110, 111, and 700, 710, 711 are displayed.
One of them is $d - Dates associated with a name
This patch adds separate treatment of the $d subfield and
wraps it in a span with the class "authordates".
This makes it possible to hide the information with CSS.
To test:
- Make sure you have several records with $d catalogued
- Check the display in result list and detail page
with and without the page.
- Check, if there is a difference in display
- Check if the dates are correctly wrapped in a span
- Try to hide the information, using the following
entry in your *UserCSS preferences:
.authordates { display: none; }
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Deleted View record link and made patron details open in a new tab.
To Test: Edit personal details for a user on opac and submit update
request.
In staff client go to patrons requesting modifications.
Confirm view record link is gone and patron details opens in new tab.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I don't think it's a good idea to open a new tab (let the user decide)
but the behavior already existed before this patch.
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch fixes translatability issues on checkin page, due to sentence splitting by html tags at
several places and ambiguous word 'to'.
Additionally, fix message related to syspref AllowReturnToBranch set to 'only the library where the
item is checked out from' (it wrongly displays the home library instead of the holding library),
and streamline the display of similar messages to look more consistent.
To test:
- Apply patch
- Go to Home > Circulation > Check in
- Do check ins with different expected results / messages
- Verify that the messages are meaningful and display nicely
- Play with items checked out / checked in at different branches (home branch, holding branch, other
branch) and different settings for syspref 'AllowREturnToBranch' and verify that the messages display
properly (with correct home rsp. holding branch)
- Carfully review code changes.
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch adds a separator for multiple 508 fields to the XSLT display in the staff and OPAC detail view.
Separator is wrapped in span with class=‘separator’ for easy manipulation via css.
To test:
* Search the OPAC
* Click the title with multiple 508 fields
* Make sure the fields display properly
* Repeat for a few more titles
* Repeat in the Staff Client
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To Test:
1-before plugin search in opac for a call number with either a "(" or a ")" in it
2-it should come back with no results
3-use plugin
4-re-search the call number with "(" or ")"
5-the search should come back with results
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
It seems this only works with OPAC XSLT for results page turned off
and OPACItemsResultsDisplay turned on. - Then the callnumbers
in the result list will be linked for searching.
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To reproduce:
- In staff client, go to List and click on the name of an
existing list.
- At the bottom of the screen, you see a title "Add an item to "
but no list name.
To test:
- Apply patch
- Verify that listname appears after "Add an item to "
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Label/legend for listname displayed Ok
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
If you use multiple instances on one server, you could have the situation
that instance A creates the cgisess subfolder and instance B could have a
permission problem. This patch resolves that by allowing each instance to
have its own cgisess subfolder.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
When some users want to improve performance, one suggestion is to switch the syspref "sessionstorage" to 'tmp',
which store the session info in the /tmp directory instead of the database.
Depending on the frequency of the cleaning process (or lack thereof),
this can be heavy pollution into the /tmp directory, making it unusable.
"rm cgi*" would not even work since cgi* extends to over 8000 items...
A simple fix is to modify the target directory in C4/Auth.pm to /tmp/cgisess.
Testing scenario:
1) change the syspref SessionStorage to 'tmp'
2) Log into the OPAC, validate that a file named /tmp/cgisess_(something) got created
3) Apply the patch
4) Log into the OPAC, validate that a file /tmp/cgisess/cgisess_(something) got created
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Works as advertised. Session files are created in /tmp/cgisess/ instead
of directly in /tmp. I usually store sessions in memcached, but a
couple of times memcached has died on me, and before I knew it, /tmp
was so full of sessions files, I could not easily delete them with
"rm /tmp/cgisess*". Being able to delete /tmp/cgisess/ should be a
bit easier.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test:
1) Add a restriction to a user
2) Log in as that user in the OPAC
3) Click 'your account page' link in the yellow mesage
4) Confirm you are taken to opac-account.pl
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To Test:
checkthat "extention" has been changed to "extension" on line 27
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test:
Check that "writen" has been changed to "written" on line 692
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
On creating new dictionary for report, the choice between "All dates"
and "Date range" should be a real radio button, not 2 radio buttons with
different names (which means they could be selected altogether...)
Note that I don't understand what means 'All dates', there is no
condition generated for the dictionary. We should not have to select a
field if we don't want to add a condition on it :)
Test plan:
Create a new dictionary for the Patron module, then a date field
(dateenrolled or birthdate, etc.)
Confirm that the radio buttons now behave as radio buttons...
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Looks so much nicer too!
Radio buttons display as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
There are 2 places where a list can be edited/deleted: on the list view
and the list content view. After the edition, the user expect to be
redirect to the previous page.
This patch implements that.
Test plan:
At the OPAC, delete and edit a list from the 2 differents places.
Confirm that you are redirect to the page you come from.
With patch, redirects work 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 A Gallagher <brendan@bywatersolutions.com>
If the user knows the URL for OPAC lists they can access them even with
the virtualshelves preference turned off. This patch copies the solution
added to opac-topissues.pl by Bug 10595 and applies it to OPAC lists
pages.
To test, apply the patch and set the virtualshelves system preference to
"don't allow."
- Navigate to /cgi-bin/koha/opac-shelves.pl. You should be redirected to
an Error 404 page.
- Also check:
- /cgi-bin/koha/opac-shareshelf.pl.
- /cgi-bin/koha/opac-downloadshelf.pl
- /cgi-bin/koha/opac-sendshelf.pl
- /cgi-bin/koha/opac-addbybiblionumber.pl
- Turn virtualshelves back on. Access to lists and list sharing should
be restored.
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Currently, the files in the folder /var/lib/koha/[instance] and also
in /var/spool/koha/[instance] are not removed.
This patch adds the option -p|--purge-all to include those two
directories when removing files.
Note: There was a small bug in the for loop. On the -k line the extra
shift statement is one too much.
NOTE: Verify that you use the adjusted koha-remove in the test plan
and not accidentally an older version of this script.
Test plan:
[1] Create an instance test.
[2] Run koha-remove and verify that /var/lib/koha/test still exists.
[3] Create an instance test2.
[4] Run koha-remove -k -p and verify that the sql database still exists
but the two instance folders in var/lib/koha and var/spool/koha are
gone.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Confirm it now says Rotating Collections instead of Patron Import in the last line, and the link is correct.
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test:
Go to Tools -> Rotating Collections and click Help in the top-right. Confirm the Help page shows and gives correct accurate instructions with no typos or grammatical errors.
Help displays as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To reproduce the bug:
- Go to Home > Circulation > Checkouts > [a patron]
- Enter 0 (zero) in barcode field and hit Enter
Result:
Software error
Can't use string ("1") as a HASH ref while "strict refs" in use
at /usr/share/kohaclone/circ/circulation.pl line 473
To test:
- Apply patch
- Repeat steps above
- Verify that the sofware error is gone and that you get a
message as with other invalid barcodes.
- Test with other values: '00', '000', existing barcode,
and a barcode that does not exist
- Test with empty barcode (for printing slip)
- Search for regressions
This patch implements Jonathan's solution (see comment #15)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If the overdue notice to send is an email or a SMS and the patron does
not provided such information, a print notice is generated.
But it will be generated with the email or sms template, which is not
useful, especially in the SMS case.
The template to use should be the print one.
Test plan:
0/ Does not apply this patch and Correctly define the overdue rules to generate
an overdue notice to the message_queue table.
Check email + SMS
1/ Define an email address and a SMS number for a patron
2/ Generate the overdue notices (misc/cronjobs/overdue_notices.pl [-t])
3/ 2 notices should have been generated:
mtt=email with the email template used
mtt=sms with the sms template used
4/ Truncate the message_queue table
5/ Remove the email address and repeat 2
6/ Only 1 notice should have been generated:
mtt=print with the email template used
7/ Truncate the message_queue table
8/ Remove the sms alert number and repeat 2
9/ 2 notices should have been generated:
mtt=print with the email template used (or sms I suppose)
10/ Apply this patch and repeat previous steps.
The print notices should be generated with the print template.
IMPORTANT NOTE: This test plan does not take into account the notices
generated for the staff ("These messages were not sent directly to the
patrons."). However the behavior will also change, the print template
will be used in all cases. Is it what we want?
Signed-off-by: Chris <chris@bigballofwax.co.nz>
Seems fine by me
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
In staff client, while displying patron related pages (e.g. moremember.pl) you get a warning like:
moremember.pl: Subroutine HasOverdues redefined at /usr/share/kohaclone/Koha/Template/Plugin/Borrowers.pm line 52.
This occurs with all pages that have [% USE Borrowers %] in their templates (directly or via members-toolbar.inc)
To test:
- Go to Home > Patrons > Patron details for....
- Search for warning above in log
- Apply patch
- Verify that no more warnings appear
- Verify that patron pages behave as before
(Solution as of comment #18)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Verified that warning disappears with this patch.
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
It seems better to check if parameters exist at the beginning of a
subroutine.
It makes the code easier to read and there is 1 indentation level less.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Ensure that a passed MARC::Record is defined before calling
its methods. Otherwise you are open to occurences of the
error 'Can't call method "field" on an undefined value'
In a CGI environment you can live with such sloppiness but
in a persistent environment the error can cause the instance
to abort.
Made all routines passed a MARC::Record validate it before calling
its methods. Changed the parameter name from the meaningless
record to marcrecord to indicate its content. Added an explicit return
for all cases where no valid data returned. Cleaned up some logic for
clarity. I think we can assume that GetNormalizedOCLCNumber meant to
look at all 035s till it found an OCLC number not just the first.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Some link are hidden when loading the page, by DataTables, we need to
use the delegate jQuery method to attach a handler to the click event
for all delete links (the ones existing when loading the page, and the
ones displayed in the future).
Test plan:
Have more than 20 reports defined
Go on the report list view, then change the number of elements
displayed, click "action>delete". You should get a warn.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Confirm that there is now a confirmation on delete from the list -> action menu
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
If all the items have been deleted for a record and holds exist, the
holds are not displayed.
You are not able to delete the items from the record detail page, but
you can from the items page.
Test plan:
1 - Place 1 or more title level holds on a record.
2 - Delete each item individually.
3 - Note that you see the number of holds on the record details page
With this patch, that holds are accessible via the holds tab.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Prior to this patch, in HoldsQueue.t:
63 my @item_types = C4::ItemType->all;
64 my $itemtype = grep { $_->{notforloan} == 1 } @item_types
65 or BAIL_OUT("No adequate itemtype");
Then we use the $itemtype variable (which contains the number of item types not for loan):
92 $dbh->do("INSERT INTO biblioitems (biblionumber, marcxml, itemtype)
93 VALUES ($biblionumber, '', '$itemtype')");
There is obviously something wrong here.
The code should be
64 my @not_for_loan = grep { $_->{notforloan} == 1 } @item_types
65 or BAIL_OUT("No adequate itemtype");
66 my $itemtype = $not_for_loan[0]->{itemtype};
But then some tests don't pass:
Actually the problem comes from:
commit bfbc646fdd
Bug 10336: HoldsQueue.t needs to create its own data
-my $itemtype = $dbh->selectrow_array("SELECT min(itemtype) FROM itemtypes WHERE notforloan = 0")
+my @item_types = C4::ItemType->all;
+my $itemtype = grep { $_->{notforloan} == 1 } @item_types
The line should have been:
my $itemtype = grep { $_->{notforloan} == 0 } @item_types
Test plan:
Confirm that the tests still pass after this patch applied.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
All tests pass pre and post patch
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
On bug 9076 (commit 568a4c1230), the plan
was to hide the Staff members from the tool.
But the test was wrong, it was done on the category_code instead of the
category_type value.
Test plan:
1/ Create a category 'Student' which is not part of the Staff
(category_code=S, category_type!=S)
2/ Create a staff category (category_type=S)
3/ Go on the deletion/anonymization tool (tools/cleanborrowers.pl) and
confirm that the category Student category is displayed in the dropdown
list.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, no errors.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
http://bugs.koha-community.org/show_bug.cgi?id=15308
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
if you create a koha install using koha-create, and remove it with
koha-remove, the /etc/koha/sites/$SITE/ directory won't be removed,
because the /etc/koha/sites/$SITE/log4perl.conf has not been removed by
this script.
Test plan:
Use this koha-remove script to remove a koha install
Without this patch, the /etc/koha/sites/$SITE directory won't be
removed.
With this patch applied, the directory will be correctly removed.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
have changed the code which strips the white space to only remove the leading and trailing white space instead
To Test-
1- go to circulation -> transfer
2- attempt to tranfer an item where the barcode has a space in the middle of it
3- it should fail
4- apply patch
5- try again
6- it should work
NOTE: I purposefully added: die "($barcode)";
Before, all spaces were removed.
' white space ' became '(whitespace)'
After, only external spaces were remove
' white space ' became '(white space)'
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Other conn errors should be checked (wrong user/pwd, etc.)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Test plan:
1) Shut down zebra: koha-zebra-ctl.sh stop
2) Execute the script: remove_unused_authorities.pl (with -t if you don't want to really delete from your database).
3) Check that the script would have deleted all the authorities (eg: 31449 authorities parsed, 31449 deleted and 0 unchanged because used).
4) Apply patch
5) Run, notice that the script dies because zebra is unavailable
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
It appears that if the course item is edited by clicking the edit link
from an active course, the course item will be set to enabled and the
fields will be swapped, if the same course item is edited from a course
that is *not* active, the course item will be set to *not* enabled, and
the original fields will be swapped back in!
The short term work-around is to only edit course items from an enabled
course if the item has a course that is enabled. If all the courses it
is on are disabled, it doesn't matter what course the item is edited
from.
Test Plan:
1) Create two courses, 1 enabled and 1 disabled
2) Add an item as a course reserve to both courses
3) Edit the course reserve data for the item via the enabled course
4) Note the course item is enabled ( easy way is to check the database )
5) Edit the same course reserve data, but via the disabled course
6) Note the course item is now disabled even though it is part of
an enabled course!
7) Apply this patch
8) Repeat steps 1 through 5
9) Note the course item is still enabled
Signed-off-by: Margaret Holt <mholt@bastyr.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Margaret Holt <mholt@bastyr.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This rewrites the while loop into a for loop, so $i still gets
incremented when we call next
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Make sense. Add readability. Infinite loop no more possible.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Patches previously applied in reverse order.
