EDIT: Comment 3
To test:
1) Go to Admin -> Circulation and fines rules
2) Fines rules
a) Confirm that buttons Edit, Delete, Save, and Clear all show as font awesome buttons and work as expected
2) Default checkout, hold and return policy
a) Confirm that column heading is now Actions
b) Confirm that actions Save and Unset show as font awesome buttons and work as expected
3) Checkout limit by patron category AND holds policy by item type
a) Confirm that buttons Add and Delete show as font awesome buttons and work as expected (you may need to add a rule to see the Delete button)
4) Confirm that none of the buttons wrap on a narrower browser
Sponsored-by: Catalyst IT
Signed-off-by: Arslan Farooq <arslanone@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
EDIT: Ah yes I was so sure it wasn't mini but couldn't remember what to
use! Thanks for that Owen
To test:
1) Go to advanced search
2) Confirm Save, More Options and Clear fields (notice change from New
search to Clear fields) are in toolbar and work as expected
Sponsored-by: Catalyst IT
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>
EDIT: Comment 3
Note: the wrapping only happens when all tags have been approved (or all
rejected), i.e. column has a certain width. When testing, ensure all
tags have been approved or rejected and click the opposite
action to see the effect of the bug and the patch.
To test:
1) Go to Tools -> Tags
2) Click Reject for a tag
3) Notice buttons do not wrap
Sponsored-by: Catalyst IT
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>
To test:
1) Go to Reports -> Saved reports
2) Notice how Filter covers parts of page
3) Apply patch and refresh page
4) Notice how Filter does not cover anything anymore
Sponsored-by: Catalyst IT
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I couldn't see the problem in Firefox, but it is a problem in Chrome.
The fix works fine for both.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
EDIT: Added 'validated' class to form and removed 'Required' span (became unnecessary)
To test:
1) Go to Acqui -> Do a vendor search
2) Receive a shipment
3) Attempt to click 'Next' without specifying invoice number. Notice error.
4) Go back to vendor search then apply patch. Click Receive shipment
5) Notice you cannot click 'Next' until you put something in invoice number.
Sponsored-by: Catalyst IT
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1) Go to Admin -> Item types
2) Confirm Edit and Delete show as font awesome buttons and work as expected
3) Confirm the buttons do not wrap with a narrower browser
Sponsored-by: Catalyst IT
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Storable dclone() is over 3x faster then Clone::clone() when used for
creating a deep copies of the big, complex data structures like MARC
frameworks. See also Bug 16044 comments #18 & #20.
This is a trivial version of Bug 16166. Performance test
results (see Bug 16140 comment #23 for test setup description):
master
146.29 (14.64+14.53+14.51+14.57+14.72+14.56+14.53+15.06+14.56+14.61)
master + Bug 16221
96.5 (9.77+9.63+9.77+9.77+9.68+9.05+9.68+9.83+9.63+9.69)
master + Bug 16166
90.7 (9.15+9.10+9.16+8.41+9.19+9.19+9.11+9.19+9.02+9.18)
Bug 16166 is a bit faster and more comprehensive implementation, but
also more complex and harder to test/evaluate.
Test plan:
1) apply patch
2) profile GetMarcStructure() calls before / after patch, e.g. by
running some script which calls it often (like catalogue search
w/ XSLT processing turned on, etc.)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some libraries would like to prevent patrons from placing holds on
items where there are other items available for the patron to
check out.
Test Plan:
1) Apply this patch
2) Browse to the circulation rules
3) Note the new option for "On shelf holds allowed"
4) Set the rule to "If all unavailable", set "item level holds" to allow
5) Find a patron/branch/itemtype applicable to this rule
6) Ensure at least one item on the record is available for the
patron to check out
7) Attempt to place a hold for the item
8) Note you cannot place the hold
9) Check the available item out to another patron
10) Note you can now place a hold for the first patron
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Works as intended!
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
- Makes new message in the holds tables in the patron account
translatable
- Unbolds the note in the holds table for the record
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Adding reserves.itemtype made a query to fail in CanItemBeReserved.
This patch prefixes the column names with the corresponding table names
to prevent that.
You can trigger the error by running
prove t/db_dependent/Holds.t
You should see something like this:
Column 'itemtype' in where clause is ambiguous
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some libraries would like the ability to select the itemtype to request
when placing holds. For example, if a record has 3 copies of BookA and 3
copies of BookA in large print, this feature would allow a person to
place a hold on the record, but still be able to target only the Large
Print edition so that the first Large Print copy that becomes available
is targeted, rather than forcing the patron to select a particular copy
to hold.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Create a record with items of two or more itemtypes
4) Place a record level hold on the record while choosing one particular
itemtype
5) Check in an item from the record that is not of that itemtype
6) Notee it is not trapped for the hold
7) Check in an item from the record that does match the selected itemtype
8) Note the item is trapped for the hold
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@kul.oslo.kommune.no>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Some libraries would like to be able to limit hold filling to items that
match the pickup library for a hold based on the item's home or holding
library. The patron's home library should not affect whether a patron
can place the hold, instead the hold will only be fillable when an item
matching the pickup location becomes available.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Note the new "Hold pickup library match" rules for "checkout, hold,
and return policy" and for "holds policy by item type"
4) Set the policy to "item's holding library"
5) Place a hold where the item's holding branch does not match
the pickup branch
6) Check in the item
7) Note it is not trapped for the hold
8) Update the item's holding branch to match the pickup branch
8) Check in the item
9) Note the item is trapped for the hold
10) Repeat steps 4-9 but for home branch instead
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Cache::Memory is loaded and Koha::Cache::_initialize_memory is called
even if a memcached cache has been correctly initialize, it does not
make sense.
It should only be initialize if needed.
Test plan:
Correctly configure a memcache server and confirm that the memory cache
is not initialize.
Do not configure correctly a memcache server and confirm that the cache
system default on Cache::Memory
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This patch removes the mysqlism (see comment #18)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Fixed QA tools complaints about missing lines before
and after =cut in POD.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
To reproduce issue:
See comment #1
To test:
- Apply patch
- Leave syspref StatisticsFields empty
- Display statistics for an author
=> Result: Table displays Shelving location, Collection code, Item type
(as before)
- Change syspref to any combination of location|itype|ccode
=> Result: Table displays columns as appropriate
- Change syspref to some garbage
=> Result: Same as with empty syspref (was crashing without patch)
- Change syspref to valid combination with trailing |
=> Result: Table displays columns as appropriate (was crashing
without patch)
- Change syspref to a combination of valid and invalid fields
(location|blah|ccode)
=> Result: Table displays column of valid fields only (was crashing
without patch)
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This patch adds a warning to the about page if the syspref 'StatisticsFields' is misconfigured.
Additionally, the text on Home > Administration > SystemPreferences for 'Statistics Fields'
is changed.
To test:
- Apply patch
- Edit syspref 'StatisticsFields'. Verify that the explanation makes sense.
- Leave field empty
=> verify that no message appears on About page, tab System information
- Insert valid field names, e.g. location|itype
=> verify that no message appears on the About page
- Add trailing char
=> verify that the warning message appears on the About page
- Fill in some garbage or misspell a field name
=> verify that the warning message appears on the About page
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Bug 12752 has fixed a bug for installations upgrading from 3.14, but has
not fixed the problem for new installations.
Because of some wrong data manipulations, the names for a given letter
code may diverge.
In particular OVERDUE and PREDUE names of phone notices have been
wrongly modify by bug 11867: they have been set to the name of the first HOLD
notice.
Trying to be back on our feet, this update DB entry will try to guess
and set back up the correct name.
To know if your install is affected by this bug, the following SQL query
can help you:
SELECT code, name, message_transport_type
FROM letter
WHERE code="PREDUE" OR code="OVERDUE";
If the names are different for the same code, something went wrong.
Executing this update DB entry should fix the divergence.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Fix the problem, see comment #6 for test.
No koha-qa errors
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This is a follow-up for bug 12267 fixing the test, still referring to
password fields.
Test plan:
Run the test.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test now pass
No errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
3.15.00.041 was wrong, the name of the letter should not always been the
name of the first HOLD notice.
PREDUE_PHONE should be updated with the first name of the PREDUE notice,
same for OVERDUE_PHONE and OVERDUE
Signed-off-by: Chris Cormack <chrisc@catalyst.net.z>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
To recreate:
1) Select two biblios to merge
2) Merge them
3) Sucess reported but list of bibs contains only the reference record.
4) View the 'new' record, it won't have any additional items
5) View the 'merged' record, it is still there with its items
This happens because record IDs (biblionumbers) are not correctly
set up in the template on the 2nd merge stage, since Bug 15358.
To test:
1) apply patch
2) try to recreate this issue once again, confirm that a problem
is resolved
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Overdues.pm line 588 tries to do an $accountline->set with column outstanding
instead of amountoutstanding.
This patch fixes it.
To test:
- Verify that code change is correct.
- Try to trigger a situation where an existing fine is updated
(see comment in line 574 in C4/Overdues.pm)
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
In catalogue/detail.pl and catalogue/moredetail.pl, the
GetAuthorisedValues subroutine is called once per item. It's not needed,
only 1 call is enough.
Test plan:
Edit item and view a catalogue record.
The withdrawn, lost and damaged values should be correctly
displayed/saved.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
EDIT: Comment 3
To test:
1) Go to Tools -> Staged MARC Management
2) Click on a batch to see details
3) If not already imported, then import, otherwise you should already see the button to undo import into catalog.
4) Click this button. Confirm you are asked to confirm. Confirm clicking Cancel will cancel the undo. Confirm clicking OK will continue with the undo.
Sponsored-by: Catalyst IT
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
When the "Add multiple items" button is pressed the other submit buttons
should be hidden in order to eliminate confusion about which button
submits the form at that stage in the process.
This patch alters the form so that clicking the "add multiple" button
hides the other two buttons and displays form for submitting the number
of copies to add.
This patch also makes changes to accompanying text in order to make
things (hopefully) clearer. The button text has been changed (again, see
Bug 10346) to "Add multiple copies of this item."
Explanatory text has been added "The barcode you enter will be
incremented for each additional item," because that seemed non-obvious
about the process.
Unrelated change: a section of obsolete JavaScript has been removed.
To test, go to the add/edit items page for a new or existing record.
Test adding a single item, adding & duplicating, and adding multiple.
The add multiple form should be shown upon clicking 'add multiple,' and
hidden when 'cancel' is clicked.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, tried adding one, one & dup, multiple and cancel multiple
No errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
As requested by QA, the sub should be moved.
Test plan:
See previous patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
This patch makes sure that the added granular permissions work as
advertised.
Note: The field owner was not included in the Koha::Upload->get response.
The code to verify if a user is allowed to delete an upload, is concentrated
in the template now. When get returns a Koha::Object, this check could be
relocated.
Test plan:
[1] Verify that the current user has permission for tools, or has
at least upload_general_files.
[2] Do you see Upload in the Tools menu? Follow the link.
[3] Upload a permanent file (with a category).
[4] Do you see the Delete button in the results form?
[5] Make sure that another user has no permission to upload.
[6] Login as that user and check the Tools menu.
Try the URL [yourserver]/cgi-bin/koha/tools/upload.pl
You should have no access to the upload form.
[7] Enable upload_general_files for this user. Go to upload and search for
the upload from step 3. You should not see a Delete button.
[8] Enable upload_manage for this user. Search for the upload again.
Delete the upload.
[9] Go to upload via the Cataloguing editor (856$u plugin) or add
parameter "plugin=1" to the URL. You should not see the Tools menu.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
[1] Upload_general_files
This will allow you to access the tools/upload form via the Tools menu.
And it will also allow you to add permanent uploads.
[2] Upload_manage
It will allow you to delete uploads from other users.
Note that anyone may delete his own uploads.
It is not meant to include upload_general_files.
In order to not disturb existing users that now have edit_catalogue and are
using the plugin (read: added at least one record to uploaded_files), we
will add the first permission for them. New users will need to be authorized
in the usual way thereafter.
Note: If you only have one of the other permissions checked in allows_add_by,
e.g. stage_marc_import, you can add temporary uploads, but not permanent
uploads.
Test plan:
We are only testing the dbrev here, not if the perm works as advertised.
[1] Run the dbrev and check that you see the perms with a description on
the Patron/Set permissions page.
[2] If you had records in uploaded_files and a user with edit_catalogue
*only*, verify that this user now also has upload_general_files.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
The three permissions in tools/upload-file.pl are moved to a custom
routine in DBIx's UploadedFile.pm. An additional granular permission
upload_general_files is added. (The dbrev patch will contain it too.)
At some point in time this could be moved to a Koha::Object class.
The routine is tested in Upload.t.
Test plan:
[1] Run t/db_dependent/Upload.t
[2] If you only apply this patch, you can also test uploading with a
user that has edit_catalogue but does not have tools or circulate.
Upload status should say: Denied.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
Bug 16354 introduces a syntax error on updatedatabase.pl
see comment #5 there
To test
1) Check error on update 3.23.00.051
2) Apply the patch
3) run updatedabase again (perhaps changing 051 to XXX)
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
happy again!
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
