In this patch I have fixed the 'Remove selected items' button.
I have also added a 'Delete batch' button like there is in the Patron Card Creator.
To test:
1) Go to Tools -> Label creator -> New label batch
2) Add 2 items
3) Select the checkbox next to an item you just added and click 'Remove selected items'
4) A pop-up will say that you are yet to select an item. (Please ignore the mistake in the pop-up message, this is being fixed in Bug 15662)
5) Apply patch and refresh. Confirm there is now a 'Delete batch' button in the toolbar
6) Select one item and click 'Remove selected items'
7) Confirm the item is deleted from the batch
8) Select the final item and click 'Remove selected items'
9) Pop-up message will tell you that deleting this item will delete the batch. Click 'Okay'
10) Click 'Delete batch' then 'Okay'
11) Confirm you are redirected to the Labels page and the batch has been deleted.
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: Brendan Gallagher brendan@bywatersolutions.com
When checking in an on-hold item which is waiting, the "Cancel" button
cancels the hold, so it should say so. This patch changes the text.
This patch also moves the 'cancel hold' button to the middle, on the
theory that buttons on the left should default to 'confirm' and buttons
on the right should generally imply 'cancel'--as in 'do nothing.' Moving
it to the middle seems like a good place to put it where users will have
to think about clicking it.
To test:
1. Find an hold which has been made 'waiting,' or check in an confirm a
pending hold at your library.
2. Check in that item again and verify that the 'Hold found' dialog
contains a 'Cancel hold' button which works to cancel the waiting
hold.
3. Repeat the process and confirm that the functionality of the other
buttons is unchanged.
Followed test plan, works as expected.
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
The CardnumberLength system preference defines card number minimum and
maximum allowed values when adding a patron. This information is
currently hidden in a title attribute on the card number input field.
This patch moves the information into a <div class="hint">, matching
other fields in the entry form which offer details about entry
guidelines.
To test, apply the patch and open the new patron entry form. Test for
various values of CardnumberLength, and with 'cardnumber' mandatory or
not mandatory as defined in BorrowerMandatoryField.
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 Gallagher brendan@bywatersolutions.com
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
I have only changed this in the includes for the tabs at the top.
Dependent on Bug 12051 as that patch adds extra tabs to the top which would need to be changed later
To test:
1) Apply Bug 12051 first, then this patch
2) Ensure that Check Out/Check In/Renew tabs still work as they should
3) Check patch for errors or pages I've missed
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
2 links are wrong on the renew page, because item.biblioitemnumber does
not return the biblioitemnumber as expect the template.
Test plan:
Renew an item and check the item link.
It should contain a valid biblioitemnumber for the 'bi' parameter.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Link repaired. At first glance, I am wondering if biblioitemnumber is
of actual use here; is it only passed back and forth between script and
template?
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If set to Yes, OPAC search results and details will include buton from
Open Library Raed API.
In addition, Number of titles held in Open Library and the results link
will be reported on the search results screen.
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
UPDATE: Added to checkin-search.inc to show up on returns.pl
To test:
1) Apply patch
2) Confirm that there is now a Renew tab on the pages where there is also a Check-in tab only
3) Attempt to renew a book using this, confirm it works as expected
4) Check if I have missed any pages
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If a librarian enters a barcode that does not match an item in the
database, a 500 error will be displayed instead of the "No item with
barcode" message.
Test Plan:
1) Enter an invalid barcode on returns.pl
2) Note the 500 error
3) Apply this patch
4) Repeat setp 1
5) Note the "No item with barcode" message
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
Script does not appear to have any other modifying patches at this
time based on bz splitter. This is a perfect time to clean up this
script!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If no branchcode is given, all the libraries are retrieved and the same
query (so without using the libraries loop) is executed for each
library.
Test plan:
Use the j2a.pl cronjob to change the category of a child patron
If a branchcode is passed to the script, only the children from this
branchcode should be updated.
But if it is not passed, all children of the DB should be updated.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Same fix as before for the "Write off" button next to the "Pay" button.
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
When a payment is made individualy, the library used to record this
payment is randomly picked from the library list.
This is because C4::Branch::GetBranch looks at 1. the $branch variable
sent by the template, wich does not exist, then 2. the branchname
cookie, which does not exist neither, then 3. get the first branchcode
from a list of keys (non ordered).
To reproduce:
- Create a manual invoice for a patron
(members/maninvoice.pl?borrowernumber=XXXX)
- Pay this fine using the "Pay" button of the corresponding line from
the members/pay.pl?borrowernumber=XXXX page
Look at the statistics table:
select * from statistics order by datetime desc limit 10;
The branch value of the first line might not correspond to the library
you were using to pay the payment.
Test plan:
Apply this patch, repeat the steps above and confirm that the library
picked is now the one used to pay.
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 Gallagher brendan@bywatersolutions.com
Test plan:
Run this new test.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
All tests successful. koha-qa.pl run OK.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
KOCT plugin send UTC timestamp, it should be converted to local timezone
Test plan:
1. Install latest version of KOCT and configure it
https://addons.mozilla.org/fr/firefox/addon/koct/https://wiki.koha-community.org/wiki/Offline_circulation_firefox_plugin
2. Use it to do a checkout and a checkin. See that timestamps are UTC.
3. Click on "Commit to Koha" under "Log" tab
4. Wait for all operations to be processed
5. In Koha, go to Circulation > Offline circulation and check the
timestamps were correctly converted to the Koha server's timezone
6. Process the pending operations and see that timestamps are still
correct
7. Repeat step 2
8. Now click on "Apply directly"
9. Check the timestamps are correct in Koha
NOTE: I could not get "Commit to Koha" to work for me, but I did
confirm this corrected behaviour with "Apply directly".
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Using the "commit to Koha" option works fine for me.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch only affects service.pl, which is not used in any way by the
uploader for desktop client files. No changes to the desktop offline
circ will be needed.
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
If a MARC framework is in use by any records it should not be possible
to delete it. Deleting a framework which is in use will leave the
deleted framework code in those records.
This patch modifies the deletion confirmation dialog so that it will not
let the user confirm the deletion if there are records using it.
Depends on Bug 15785 - Use Font Awesome icons in confirmation dialogs
To test, apply the patch and go to Administration -> MARC frameworks
1. Try to delete a framework which is in use by 1 or more records. The
resulting confirmation dialog should prevent you from proceeding.
2. Try to delete a framework which is not in use. Test both canceling
and confirming that deletion to make both function correctly.
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
We can simplify the staff client's CSS and reduce some image file usage
if we modify confirmation dialogs to use Font Awesome icons. This patch
makes this change for Administration templates.
This patch includes some whitespace changes, so please consider that
when looking at diffs.
To test, apply the patch and test deletion in the following cases. Test
both confirmation and cancel actions.
Administration -> Budgets -> Delete budget
Administration -> Funds -> Delete fund
Administration -> Authority types -> Delete authority type
Administration -> Authority types -> MARC Structure -> Delete tag
Administration -> Authority types -> MARC Structure -> Subfields -> Delete
Administration -> MARC bibliographic framework -> Delete framework
Administration -> MARC bibliographic framework -> MARC structure -> Delete
Administration -> Cities and Towns -> Delete city
Administration -> Classification sources -> Delete classification source
Administration -> Classification sources -> Delete classification filing rule
Administration -> Item types -> Delete
Administration -> Record matching rules -> Delete
Administration -> Patron attribute types -> Delete
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. Icons changed
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
On deleting a patron, all the tags approved by this user will be
deleted.
This can cause data lost.
Test plan:
0/ Do not execute the update DB entry
1/ Create 2 patrons A, B
2/ Create some tags with patron A logged in
3/ Approve them with patron B logged in
4/ Delete the 2 patrons
=> The tags have been deleted
5/ Execute the DB entry
6/ Repeat 1,2,3,4
=> The tags have not been deleted and are still shown on the interface
(result, detail, tags module)
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
delete 'expected' and 'supexpected' ids that don't seem useful anymore.
Same thing for changeDate2 function
Test plan :
1) Search a serial subscription from the Serials Home page
2)Go to serial collection page and make sure it has a mimimal bunch of
already received or missing issues
3)Check some received issues to be sure to get extra issues (not only
the extected one) in the serial edition page
4) Click on Edit serials button
5) Try to modify whatever date in 'Expected on' column (excepted first
one) using datepicker :
You can see that the top date of the column is updated instead of the
choosen one.
6) Apply patch and redo 1 to 5 steps :
now the right date is updated.
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
A hold in transit will simply appear as an unfilled hold!
Test Plan:
1) Place a hold for pickup at a different location
2) Capture that hold for a patron
3) Note you do not see the in transit status on request.pl
4) Apply this patch
5) Refresh the page
6) The hold should now show as in transit!
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
Bug 14821 removed the items which were not checked out, but some
libraries considered it as a bug.
So let's add a new pref to control this behavior.
Test plan:
0/ Execute the updatedb entry and set ShowAllCheckins to "Do not show"
(default)
1/ Check an item in.
If the item was not checked out, it won't be listed
2/ Turn the pref to "Show"
3/ Check an item in
If the item was not checked out, it should be listed
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch fixes the following bug:
If OpacAllowPublicListCreation is set to "not allow", the creation of a
private list raises an error at the OPAC.
CGI->param is called in a list context and some parameters are not
filled from the template if the pref is set to "not allow".
To make sure we don't have a "Odd number of elements in anonymous hash",
we force the context to scalar.
Test plan:
1/ Set OpacAllowPublicListCreation to "not allow"
2/ Create private and public lists at the OPAC and the intranet
=> Everything should work fine with this patch applied
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
When searching for something in OPAC which doesn't result in any results but have utf-8
characters in search string we get following encoding error:
Cannot decode string with wide characters at /usr/lib/i386-linux-gnu/perl5/5.20/Encode.pm line 215.
This is because we are trying to decode string which is allready correctly
marked as utf-8.
Test scenario:
1) enter search string with utf-8 characters in opac which doesn't
return any results
2) verify that you get application error
3) apply this patch
4) re-run query and verify that errror is gone
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Step 0: Define "OPACNoResultsFound" with '{QUERY_KW}'
Note that I don't get the error (Encode 2.60) but the search terms are
not display correctly.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
The variable to be decoded comes from already decoded vars (via
the -utf8 flag from CGI), following the trail in Search.pm.
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>
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>
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>
* Change links to buttons
* Add warning class to delete button if provider is being used
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>
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>
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>
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>
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>
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>
Check in and check out were failing for me.
Specificly, the $borrower->{flags}->{...} was not accessible as
a hash, so I put a hash ref check around the code that would fail.
TEST PLAN
---------
1) Attempt a checkout
-- blows up with "1" not being allowed as a hash ref.
2) Apply patch
3) Attempt same checkout again
-- success
4) prove -v t/db_dependent/Circulation_dateexpiry.t
-- this triggers CanBookBeIssued
-- this should succeed
5) prove -v t/db_dependent/rollingloans.t
-- mine skipped the tests, but if configured, it
should also trigger and succeed.
6) run koha qa test tools
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@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>
This ensures that the DBIx structure matches the SQL structure changes.
See comment #48 as to how this was generated.
Also, I had to modify misc/devel/update_dbix_class_files.pl
to have an "overwrite_modifications => 1" option to get it to generate.
This should correct issues raised in comment #45.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@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>